Newsgroup: it.comp.lang.visual-basic
Titolo: importare txt in access....

sto facendo dei test per importare testo in un database access...
il codice proviene da un progetto VB6 perfettamente funzionante...
trasportato su vbnet non mi funzia...
va in errore su "EstablishConnection"
qualcuno sa aiutarmi?
grazie...
        Dim rd As RDO.rdoEngine
        Dim rdoCn As RDO.rdoConnection
        Dim rdoEn As RDO.rdoEnvironment
        Dim percorso As String = "D:\"
        Dim strCn As String = "DRIVER={Microsoft Text Driver 
(*.txt;*.csv)};DBQ=" & percorso & ";"
        rd = New RDO.rdoEngine
        rdoCn = New RDO.rdoConnection
        rdoEn = rd.rdoEnvironments(0)
        rdoEn.CursorDriver = RDO.CursorDriverConstants.rdUseOdbc
        With rdoCn
            .CursorDriver = RDO.CursorDriverConstants.rdUseOdbc
            .Connect = strCn
            .EstablishConnection(RDO.PromptConstants.rdDriverNoPrompt, 
False)
        End With
        Dim file As String = "test.txt"
        Dim percorsofile As String = "D:\test.txt"
        Dim percorsodb As String = "D:\xxx.mdb"
        Dim strSQL As String = "SELECT * INTO [test1] IN '" & percorsodb & " 
'FROM " & file
        rdoCn.Execute(strSQL)
 

 qualcuno sa aiutarmi?
Non ci siamo. Abbandona completamente il modo di programmare VB6 e
buttati a capofitto su 
ADO.NET
 2.0, altrimenti sarà un bagno di sangue...
Nicola

 ha scritto nel messaggio 
news:49116dce$0$1076$4faf...@reader2.news.tin.it...

dici? ho fatto dei test ADO vs DAO e mi sembra che quest'ultimo vada 
benissimo per access...
per quanto riguarda l'importazione di file di testo ho delle rogne sul mio 
computer...
ho provato in vari modi (tramite un programma microsoft che permette di 
sperimentare varie modalità come RDO,DAO,ADO,Access automation) e mi rileva 
errori tipo "ISAM non trovato" ed altro...ho provato a registrare qualche 
dll ma niente...
gli unici due metodi che mi funzionano sono RDO ed Access Automation...
il primo non riesco a metterlo dentro VBnet2008 perchè si ferma durante il 
debug come scritto sopra...il secondo funziona tutto...
ovviamente preferirei usare altri metodi piuttosto che Access Automation. 
l'unico che dovrebbe funzionare è l'RDO... 

 benissimo per access...
DAO non va affatto bene. Se vuoi utilizzarlo fallo, ma poi non dire che
non ti avevamo avvisato ;-)
Nicola

 l'unico che dovrebbe funzionare è l'RDO...
con dao in casi simili leggo il txt/csv con lineinput e uso split. una volta 
che hai l'array fai l'insert come ti pare, sql o addnew. ovviamente nel csv 
devi avere un separatore preciso e univoco per lo split.
ciao, a.

 ha scritto nel messaggio 
news:49117d23$0$40304$4faf...@reader5.news.tin.it...

ho iniziato che ADO ma quando ho visto i problemi che mi creava, sono 
tornato ad DAO...
per l'esattezza, ADO mi dice che non ha memoria sufficiente per gestire il 
database e si blocca...(ho tabelle con milioni di dati...)
bo!!
DAO invece mi va come una scheggia... 

un attimo Pal.
L'OP sta utilizzando .NET
Nicola

 ha scritto nel messaggio 
news:6nde18F...@mid.individual.net...

io il file txt non voglio proprio leggerlo...
praticamente gli dico di prendersi il file txt delimitato da 'tab' ed 
importarselo nel database... 

 DAO invece mi va come una scheggia...
Allora stai sbagliando qualcosa tu.
Noi in azienda con 
ADO.NET
 trattiamo milionate di record su server di
media potenza senza grossi problemi.
Nicola

 ha scritto nel messaggio 
news:4911842d$0$40309$4faf...@reader5.news.tin.it...

il codice adottato è quello che ho postato 2 giorni fa e che mi hai anche 
corretto...
sul mio computer s'impalla quando trova milioni di record... 

marcus ha detto questo mercoledì :

Non posso che concordare con Nicola.
Nel 2008, 'milioni di record' è una cosa che non fa più neppure il 
solletico, a meno che uno non abbia un 486DX33 con 64MB di Ram.
C'è sicuramente qualcosa di sbagliato.
Alberto
-- 
Noi ammazziamo solo per motivi buoni.
E quando sono buoni, sta a noi indicarlo.
[Guccini]

 ha scritto nel messaggio 
news:mn.2b007d8b5...@hotmail.com...

avrò un database bacato!!!
ho provato anche a copiare ed incollare codice di esempio perfettamente 
funzionante...come sostituisco il databse col mio s'impalla... 

Sembra che marcus abbia detto :

Non saprei.
Non vedo codice che si connetta ad un db access.
Alberto
-- 
Georges Pompidou: Un uomo di stato è un politico che dona se stesso al 
servizio della nazione. Un politico è un uomo di stato che pone la 
nazione al suo servizio.

 ha scritto nel messaggio 
news:mn.2b1f7d8b4...@hotmail.com...

il codice è questo...
 'Percorso del DataBase
        Dim PercorsoDB As String = "D:\test.mdb"
        'Stringa di Connessione
        Dim ConnString As New OleDbConnection("Provider= 
Microsoft.Jet.OLEDB.4.0; " & "Data Source =" & PercorsoDB)
        Dim sql As String = "SELECT * FROM testxyz"
        Dim da As New OleDbDataAdapter(sql, ConnString)
        Dim cb As New OleDb.OleDbCommandBuilder(da)
        Dim ds As New DataSet
        da.Fill(ds, "testxyz")   <------------------- qui s'impalla...la 
memoria occupata aumenta e poi mi dice che non la gestisce più...(ho 2 giga 
di ram...)
        ds.Tables("testxyz").Rows(0)("test") = 11
        '' Update the data source with the modified records.
        ds.AcceptChanges()
        ConnString.Close()
 


Ti suggerisco un'alternativa basata su 
ADO.NET
:
        Dim sPath As String = "d:\temp"    ' Il percorso che contiene il 
file TXT
        Dim ConnString As String = _
            "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & sPath & _
            ";Extended Properties=""text;HDR=Yes;FMT=Delimited"";"
        'NB: la prima riga del file txt contiene i nomi dei campi; formato 
delimitato
        Dim cn As OleDbConnection = New OleDbConnection(ConnString)
        Dim cm As OleDbCommand = cn.CreateCommand()
        cm.CommandText = _
            "SELECT * INTO [test1] IN 'd:\temp\test.mdb' FROM [test.txt]"
        cn.Open()
        cm.ExecuteNonQuery()
        cn.Close()
Bye
Raf 

 formato delimitato
Fonte: 
http://www.connectionstrings.com/?carrier=textfile
Raf

 giga di ram...)
Eh no... il codice te l'ho corretto ma non avevi detto che gestivi
milionate di record da Access!!!
Devi assolutamente passare a qualcosa di più performante... almeno SQL
Server 2005 Express, se vuoi qualcosa di gratuito.
Altrimenti è un suicidio, perchè i dataset lavorano in modalità
disconnessa. Con quel .Fill stai caricando gigate di roba in RAM... non
va bene, è il concetto che è sbagliato.
Io farei così:
1-Userei SQL Server 2005
2-Userei una bulk insert per caricare nelle tabelle direttamente il csv
delimitato.
3-Troverei il modo di spezzettare la query per renderla più leggera
4-Se devi solo trasformare dei dati e salvarli da un'altra parte, prendi
in considerazione l'uso degli SSIS.
Nicola

 in considerazione l'uso degli SSIS.
Aggiungo un altro punto:
5-Se lavori con SQL Server puoi usare gli oggetti Sqlclient
(SqlDBConnection, ecc...) che sono molto più performanti rispetto a OleDb
Nicola

 ha scritto nel messaggio 
news:4911a1e3$0$18160$4faf...@reader3.news.tin.it...

grazie dei consigli sempre ben accetti...
resta il fatto che cercare 600 record su 6 milioni tramite DAO-access 
impiego 8 centesimi di secondo...
non vorrei complicarmi la vita con sqlserver... 

"Rafunk" <rafun...@NOTHANKSlibero.it> ha scritto nel messaggio 
news:ges68p$197$1...@alix.livenet.it...

ottimo direi!!
grazie...
si puň anche decidere quale campo indicizzare?
io al momento uso del codice per stabilire quale campo indicizzare. mi 
piacerebbe che fosse fatto in un unico passaggio... 


Cosa intendi esattamente per "indicizzare"?
Stabilire quale dei campi nel file txt deve diventare la chiave primaria 
della tabella Access (come chiede il wizard di importazione di Access) per 
caso?


no...anche se sarebbe utile anche quella...
intendo la proprietà "Indicizzato" del campo che s'imposta nel struttura 
della tabella.(NO, Sì (Duplicati ammessi),Sì (Duplicati non ammessi))
ora la imposto da codice attraverso il "CreateIndex" ecc ecc
 

 ora la imposto da codice attraverso il "CreateIndex" ecc ecc
Temo non sia possibile, visto che la struttura della tabella viene creata 
attraverso una query SELECT ... INTO.
Ma puoi sempre creare la struttura a priori mediante un command che esegue 
una query "CREATE TABLE..." e poi popolare la tabella dal file txt usando 
una INSERT INTO.
Ciao
Raf 

 impiego 8 centesimi di secondo...
Non male per un DataBase definito da molti come 'Poco serio'...
-- 
Ciao Fede
By Chicco Production
http://bcp.freetools.it

 
beh, un dato "prestazionale" estrapolato cosě non vuol dire granchč.
che tipo di dati sono?
che filtro č stato usato?
i dati sono contigui?
su che macchina č stato fatto il test?
Chi afferma tout-court che access č un database poco serio ha capito ben 
poco. Come per tutte le cose ha il suo target-use.
ciao
stefano

 se sono 4 gb importanti, userei un db serio.


Nel suo scritto precedente, Tiscali ha sostenuto :

Beh, ad esempio Andrea potrebbe avere avuto in mente il backup.
Come fai a fare un backup a caldo di 4GB di Access?
Se lo fai con utenti connessi, il backup non è garantito che sia 
ripristinabile. Se fai disconnettere gli utenti, sei comunque appeso a 
un filo (basta un processo notturno che impiega più tempo del previsto, 
o un utente che dimentica il pc acceso, ecc...).
Per non parlare della mancanza di rollback su caduta di rete.
Se poi entriamo sull'argomento sicurezza, il fatto che i dati debbano 
essere in una cartella di rete condivisa in lettura+scrittura a tutti, 
e che la pwd di Access si cracca in due minuti di brute force...
Insomma, Access ha i suoi bei vantaggi, in primis quella di non 
richiedere nessun servizio installato, ma da un punto di vista della 
'serietà' (e con questo intendo appunto sicurezza, sia come disaster 
recovery che come riservatezza), siamo ancora ben lontani da altri 
strumenti.
Alla fine, non posso che concordare con Andrea: se sono dati 
importanti, userei un db serio.
Alberto
-- 
Il tempo e la pazienza possono più della forza o della rabbia

 Come fai a fare un backup a caldo di 4GB di Access?
infatti. mi sembra chiamarsela.
anche con db seri, comunque questo è un aspetto da non sottovalutare.
una ditta mi ha proposto un mssql con le immagini *dentro*. il problema e' 
che di immagini sto felicemente superando il tera.
come fai a fare un backup di un tera? (btw, noi dobbiamo staccare corrente 
ogni sera, e per copiare solo una parte delle immagini, 500 gb, *da d: a e: 
del mio pc* ci ho messo due giorni pieni, in cui il pc era praticamente 
inservibile, i sata stressano parecchio le macchine...)
e se frulla un solo byte, quante sono le probabilita' che gli altri 
fantastiliardi di byte di quel tera li ritrovi?
una parte importante dell'informatica continuo a pensare che non debba 
neanche vederlo, un monitor, ma mettersi a gambe incrociate a meditare...
ciao 

 il tutto su un DataBase Access da 4.8 Gb!
Ecco, forse qui andiamo oltre i limiti per cui è stato costruito.
Certo, non è  giusto dare ad Access del database poco serio sempre e 
comuque, a prescindere.
Poi alcuni affermano che non userebbero access neanche per la loro rubrica; 
bah...
greg 

 che di immagini sto felicemente superando il tera.
Beh, questo è un problema diverso.
Che tu utilizzi Access, SqlServer, Oracle, DB2, MySql, Postgres, 
FoxPro, Clipper, ecc..., il rischio che un byte vada perso durante il 
trasferimento di un teraByte da una macchina a un'altra c'è sempre.
Puoi migliorare decisamente le cose con un Raid veloce, come il 10, ma 
comunque il problema è di sistema, non di dbms.
Il punto è che un database deve essere caldo 24/24 7/7. Io se sento 
parlare di 'tutti fuori', o di 'accesso esclusivo', mi gratto. Sono 
cose d'altri tempi, che vanno bene per il db del fruttivendolo che 
accende al mattino, fa le bolle e poi spegne quando va a pranzo.
E con database basati su file, come Access o FoxPro, comunque c'è un 
file o un gruppo di file che deve essere accessibile in 
lettura+scrittura, e durante l'accesso dei client il backup non è 
garantito, quindi non si fa.
Per non parlare del pack, che richiede addirittura l'accesso esclusivo.
Da un mio cliente si sta verificando una cosa incredibile: ogni tanto, 
diciamo una volta al mese, qualche utente si ritrova con le 
autorizzazioni spippolate. Ad avere l'autorizzazione di variare le 
autorizzazioni ci sono una decina di utenti, contro i duecento utenti 
'ordinari' che queste modifiche le subiscono. Adesso, io non so quale 
sia l'utente che fa ciò (in realtà da ieri è attivo un journal su 
quella tabella, quindi a breve lo tano, e comunque ho una mia idea), ma 
così come si diverte a fare gli scherzetti, potrebbe ad esempio 
cancellare il file di Access coi dati. Tanto ha il diritto di 
lettura/scrittura...
O potrebbe copiarselo su chiavetta usb e a casa divertirsi a sputtanare 
dati contabili.
Con sql-server, invece, al massimo può fare ciò che l'applicativo gli 
consente di fare. Ma se l'applicativo non lo autorizza a guardare le 
fatture, lui non guarda le fatture.
E siccome ogni 4h c'è un backup completo, più uno giornaliero e uno 
settimanale, non sovrascritti ma conservati a rotazione, se anche fosse 
uno del ced che danneggia il db, io avrei un backup SICURAMENTE 
funzionante vecchio al massimo di un'ora o di una giornata.
Quando faccio cose con Access (e mi è capitato), non ho alcuna 
preclusione. Ma sono consapevole, e avverto il cliente, che la certezza 
di recuperare i dati in caso di crash non c'è. Se sta bene a lui, 
nessun problema.
Ah, come performance, beh, ci saranno anche casi validi, ma in rete su 
db di Access di decine di MB, figuriamoci di GB, performance 
accettabili non ne ho mai viste, se la query è appena appena 
articolata.
Alberto
-- 
Carlo Rubbia: Siamo su un treno che va a trecento chilometri all'ora, 
non sappiamo dove ci sta portando e, soprattutto, ci siamo accorti che 
non c'è il macchinista.

 tabella, quindi a breve lo tano, e comunque ho una mia idea)
mi sfugge perché lo faccia, ma spero sia almeno consapevole di potere andare 
incontro a grane davvero pese. boh...
ciao 

<cut>
Concordo pienamente con Alberto e Andrea,
e (OT) posto questo link per i *cultori* di Access:
http://odbcsock.sourceforge.net:80/
-- 
---------------------------
Mauro Gamberini
http://www.riolab.org/
 

 userei un db serio.
Giustamente ognuno di noi ha i suoi punti di vista...


 Giustamente ognuno di noi ha i suoi punti di vista...
Certo.
Alcune cose sono oggettive, altre soggettive. Basta non confonderle.
Alberto
-- 
Max Beerbohm: Tutto ciò che è degno di essere fatto è stato fatto 
ripetutamente. Dalle cose mai fatte bisognerebbe tenersi, sospetto, 
molto alla larga.

 wrote:
tanto per dire anche io la mia....
se usi SOLO access DAO va benissimo essendo una tecnologia pensata per
essere usata SOLO con jet...detto e ridetto mille volte!
Appena appena uno voglia adeguarsi allo stile di programmazione in
voga adesso : OOP....non va più bene!
Giusto ADO.net...etc etc
Ma visto che si parla di "file di testo"....e che il net 3.5 è
gratis ...e VB.net Express pure
Magic keywords da cercare su San Google
LINQ to  TEXT
Tra i tanti ne cito solo alcuni
http://msdn.microsoft.com/en-us/library/bb882644.aspx
http://www.onedotnetway.com/tutorial-reading-a-text-file-using-linq/
http://blogs.msdn.com/ericwhite/archive/2006/08/31/734383.aspx
In italiano:
http://blogs.ugidotnet.org/marcom/archive/2008/10/29/94436.aspx

 ha scritto nel messaggio 
news:7bf98e4e-a001-4948...@s9g2000prm.googlegroups.com...

questi link non fanno al caso mio...
rafunk mi ha risolto il problema...
ma grazie lo stesso... 

 Alcune cose sono oggettive, altre soggettive. Basta non confonderle.
Tranquillo nessuna confusione,
e non potrebbe essere altrimenti!


 Perchè forse in questo caso non serve...
Ma domani potrebbe servire. Se usano 4gb di dati, immagino non sia un 
fruttivendolo. Se domattina assume una segretaria, e questa ha bisogno 
di accedere agli stessi dati, e attaccano un cavettino di rete, per 
stare sereno dovresti riscrivere tutto usando altri strumenti.
Alberto
-- 
Ho spiegato a mio nipote cos'è il compromesso: se per le vacanze tua 
madre vuole andare al mare e tuo padre invece in montagna, il 
compromesso è che si va al mare, ma il papà può portarsi gli sci.

 si va al mare, ma il papà può portarsi gli sci.
?!?
