Newsgroup: it.comp.appl.access
Titolo: Caricare contenuto di file .txt in una tabella

Buona sera.
 
Avrei un quesito da porre, non so se è mai stato posto.
 
Mi trovo nella necessità di dover "acquisire" il contenuto di un file 
.txt con stringhe alfanumeriche.
Una cosa di questo genere:
 
12020222200010SPSGNR77R30A483Y00999 e via discorrendo.
 
La subroutine di caricamento la posso tranquillamente avviare con un 
pulsante che mi può permettere di scegliere, da una finestra, il file 
.txt da caricare.
 
Quello che non so come fare è fare in modo che IL CONTENUTO INTEGRALE di 
ogni singolo record sia inserito direttamente in una tabella 
predefinita, per es. tblFile, che non deve avere una chiave primaria, 
così da poter poi avviare un sub idonea a "spacchettare" (brutto, lo so) 
ogni singolo record e inserire i vari dati dove mi occorre.
 
Suggerimenti?
-- 
Carlo POTS
 
 
-- 
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

Devi armarti di codice... aprire il file con OPEN Nomefile FOR INPUT
Aprire in parallelo un recordset in scrittura sulla tabella.
Quindi leggere il contenuto riga per riga con LINE INPUT finché
 non arrivi ad EOF del file...
 
Letta la riga passi il contenuto e devi fare il PARSING della stringa.
Se hai blocchi fissi è banale con MID$... altrimenti devi capire
 come individuare il fine campo... 
Quindi fai ADDNEW sul recordset e valorizzi i campi, Update e poi
 Loop della lettura del file alla nuova riga.
 
Non dovresti trovare difficoltà particolari...
 
-- 
@Alex
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
 

 
 
Ma anche con alcune query ben impostate dovrei riuscirci.
Quello che devo approfondire è come impostare l'istruzione Open
 
Grazie


 Carlo POTS 
 
Tecnicamente non conviene usare la Query in questo caso, in quanto ad ogni EXECUTE generi una scrittura su tabella..., mentre risulta più comodo, anche come codice, e soprattutto veloce l'uso del RS, su cui puoi fare un UPDATE in transazione tutto in un colpo alla fine.
 
Tuttavia fai quello che la tua esperienza ti dice sia meglio.
 
Non ho compreso il problema che hai con l'uso di OPEN...?
@Alex

crea un query, nel SQL inserisci
 
SELECT * From [Text;HDR=NO;DATABASE=c:\cartella;].[file.txt]
 
sostituisci "cartella" e "file.txt" con il percorso e il file desiderato,
rispetta le parentesi quadre e i punti e virgola.


Sicuro...?
Il campo tutto raggruppato che fine farebbe, verrebbe suddiviso in automatico...?
 
@Alex

 
 
Gnyr Traaneb Rfcbfvgb, angb nq Ngryyn vy 30 bggboer qry 1977 ?   ;)
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

 
Se vuoi te lo codifico:
 
- 1 - Tipo Record
- 2020 - Anno di esercizio
- 2 - Gruppo prodotti
- 222 - Matricola azienda
- 0001 - Contratto di fornitura
- 0 - Contratto primario (se fosse stato integrativo sarebbe stato 1)
- SPSGNR77R30A483Y - Codice fiscale del contraente
- 00999 - Matricola del contraente
 
Il resto è inutile che te lo scrivo ...
 
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)


 
 
Che non sono pratico, vorrà dire che mi vado a spratichire.
 
Dimmi una cosa: in questi record, ogni campo è separato da un ";", però 
diciamo che tutti sono di lunghezza più o meno regolare.
Soltanto in un punto mi trovo un problema: c'è un campo in cui la 
grandezza varia al variare della ragione sociale, c'è il ";" e poi la 
partita Iva.
 
Per esempio un record, a partire dalla posizione 125 (per es.) riporta 
"CAA - FIAT BREVETTI;01828740621" e un altro record (dello stesso tipo) 
alla posizione 125, riporta "CAA - ALFA ROMEO INDUSTRIE AVIO;01828740621"
 
Ovviamente, nel primo record, la Partita IVA inizia dalla posizione 146, 
mentre nel secondo record, la Partita Iva inizia dalla posizione 177.
Come posso ovviare? Anche perché, dopo la Partita IVA, non c'è altro...
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)
 


 provi..." (cit. PMF)
 
Serve capire meglio, ed io non riesco con quello che dici, il tracciato RECORDS.
Ogni RIGA del file TXT è un Record...?
Ogni Riga ha al suo interno come CSV il [;]...?
 
Se è così, cosa che non avevo compreso inizialmente, ti basta importare il File definendo il FILESPEC ed usare:
 
Sub TransferText([TransferType As AcTextTransferType = acImportDelim], [SpecificationName], [TableName], [FileName], [HasFieldNames], [HTMLTableName], [CodePage])
    Membro di Access.DoCmd
 
Se invece i Records sono separati da ; ed i Campi sono tutti attaccati come avevo capito inizialmente... allora cambia.
 
@Alex

 
 
 
-- 
Carlo POTS


Alternative Delimiters
Alternative delimiters fall essentially into 2 categories, which I guess I will call Standard and Custom. Standard alternatives are Tab delimited and Fixed Length. Custom delimiters are any other character, such as a colon, space, pipe etc, but not a double quote. With anything other than a comma separated file, you will need to create a special text file called Schema.ini which provides the driver with information on the file format. This file needs to be placed in the same directory as the file being read.
 
Schema.ini
A Schema.ini file contains up to 5 sections of information:
 
The text file name
The file format
The field names, widths and types
The character set
Any special datatype conversions
A full discussion of these settings can be found on MSDN, but for the purposes of this article, I'll only use the first 3.
 
The first entry, the text file name appears at the top of the Scheme.ini file, and is surrounded by square brackets:
 
[test.txt]
Following that, the file format is declared. If the format is one of the two "standard" alternatives, the entry will be one of the following:
 
Format=TabDelimited
Format=FixedLength
For all Custom alternatives the entry is Format=Delimited(), and the separator is places in the parentheses. So for a space delimiter, the entry is as follows:
 
Format=Delimited( )
And for a pipe delimiter:
 
Format=Delimited(|)  
The third section contains the field names. If there are no field names in the file itself, you must specify ColNameHeader=false and provide some names. You must also ensure that these match up with the SQL:
 
ColNameHeader=False
Col1=FirstName
Col2=SecondName
[SQL]
SELECT FirstName, SecondName FROM [Text;DATABASE=" + path + ";].[test.txt]
You may also notice that HDR=No; is omitted from the above SQL. With files that are other than comma delimited, any instructions like this that are put in the connection part of the SQL are ignored, so all details must be covered in the Schema.ini file. For example, if you add HDR=No, and leave ColNameHeader=False out of the Schema.ini, the fille will be imported with a blank row to begin with, because the system default assumes a header.
 
With Fixed Length files, the field names in the Schema.ini must also be accompanied by the datatype and length. So the entry for a for such a file would look like this:
 
Format=FixedLength 
 
ColNameHeader=False
Col1=FirstName TEXT width 50
Col2=SecondName TEXT width 50

 
 
Perdonami.
Facciamo un esempio.
 
 
Nel record, dalla 50^ colonna, vi è un "12345;678910" (chiaramente è 
minore di 15 caratteri, ma tanto dopo non c'è niente).
 
In Campo1 devo inserire 12345
In Campo2 devo inserire 678910
 
Ovviamente Campo1 e Campo2 devono prepararsi a ricevere valori di max 9 
caratteri ciascuno
 
Io mi estrapolo questo dato e lo inserisco in una variabile Stringa
 
	Var=mid(Record,50,18)
 
Il contenuto di Var sarà "12345;678910", dove Campo1 dovrà contenere 
12345 e Campo2 invece 678910.
 
Chiaramente dovrò fare il Len di Var per contare i campi prima del ";" e 
poi fare lo stesso per quelli successivi.
 
Come devo impostare la riga di codice per separare i due valori?
 
Poi la questione più spinosa sarà quando dopo ci sarà qualche altro 
campo ...
 
 
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)
 


Carlo, investi 5 minuti a leggere la guida sull'utilizzo di
 TransferText...
Quello che hai definito non rappresenta un problema perché
 sfruttando la definizione della specifica di Importazione che
 rimane memorizzata nel Db, l'azione importa applicando la
 specifica predefinita e non devi preoccuparti di
 nulla.
 
Come fare ad impostare la specifica...?
 
Avvia dal menu l'importazione del file di testo e si avvia il
 Wizard guidato.
Ti fa selezionare il file e ti mostra lo spacchettamento usando il
 separatore indicato, nel tuo caso; e, per ogni campo ti consente
 di definirne il tipo.
Salvi la specifica con un Nome e la richiami quando poi userai
 Transfertext.
Devi fare una prova però dai.... segui questo link, anche se è per
 il 2003 il wizzard è uguale:
 
https://access-programmers.com/creating-an-import-specification-in
 
-access-2003
 
@Alex


 
 
Alex, a questo c'ero arrivato, e non da oggi, ma da tanto tempo.
 
Quello che a me serve è creare una maschera dove l'utente clikka su un 
pulsantino, si apre la finestra, lui sceglie il file da acquisire e il 
resto se ne occupa automaticamente il programma con una serie di query o 
di altri tipi di istruzioni come hai indicato tu dall'inizio.
 
E infatti, le prime indicazioni che mi hai dato hanno funzionato 
benissimo, il file viene scelto, si apre e viene importato 
automaticamente in una tabella provvisoria.
 
Adesso mi tocca fare la scompattazione, e fintanto sono lunghezze fisse, 
tutto mi va benone; il problema sorge al momento di dover acquisire dei 
dati di lunghezza non standard, con un ";" come separatore.
 
L'acquisizione del file come dici giustamente tu, va bene se sono io 
dietro lo schermo a interagire col sistema; ma se è un utente normale, 
che non ne sa un piffero di Access ma deve solo scegliere il file e si 
trova i dati in memoria, la cosa cambia.
 
Mi studierò la guida sull'utilizzo di TransferText, tranquillo e grazie 
della preziosa indicazione.
Purtroppo Access lo sto scoprendo poco alla volta, e quel poco che 
scopro mi dà la possibilità di perfezionare il mio lavoro, e ve ne sono 
grato sempre
 
 
-- 
Carlo POTS


 Carlo POTS
 
Saluti
@Alex

 dati di lunghezza non standard, con un ";" come separatore.
 
una banale split sembra troppo?
Ritorna un array che gestisci come vuoi
-- 
ac (y-1=x)


Non serve.
 
@Alex

 
 
Era riferito alla lettura/gestione di/in stringa unica.
"il problema sorge al momento di dover acquisire dei dati di lunghezza 
non standard, con un ";" come separatore."
Quanto sopra scriveva l'OP ed a quello riferivo.
Ed era una soluzione /adatta/ per quel caso.
Prescindeva da specifiche di importazione e altri  "trucchi" simili.
I transfertext e' potente ma limitato laddove si richieda un "lavoro di 
fino"
Esempio? Una struttura json
-- 
ac (y-1=x)

 On 26/11/2020 17:46, @Alex wrote:> Il giorno giovedě 26 novembre 2020 alle 14:32:14 UTC+1 Alessandro Cara ha scritto:>> On 26/11/2020 00:55, Carlo POTS wrote:>>> Adesso mi tocca fare la scompattazione, e fintanto sono lunghezze fisse,>>> tutto mi va benone; il problema sorge al momento di dover acquisire dei>>> dati di lunghezza non standard, con un ";" come separatore.>> una banale split sembra troppo?>> Ritorna un array che gestisci come vuoi> > Non serve.> Era riferito alla lettura/gestione di/in stringa unica."il problema sorge al momento di dover acquisire dei dati di lunghezza non standard, con un ";" come separatore."Quanto sopra scriveva l'OP ed a quello riferivo.Ed era una soluzione /adatta/ per quel caso.Prescindeva da specifiche di importazione e altri  "trucchi" simili.I transfertext e' potente ma limitato laddove si richieda un "lavoro di fino"Esempio? Una struttura json-- ac (y-1=x)
 
Si anche se dovessi caricare XML avrebbe limiti... 
Carlo, per quanto si č compreso leggendo le sue indicazioni con un
 minimo di filo sequenziale, ha un file CSV... quindi non
 serve.



Nessuna struttura Json, per fortuna.
 
 
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)
 


 
 
	Bene


 
 
[CUT]
 
Ho provveduto a fare come dicevi tu, e in definitiva mi è molto più 
comodo perché mi importa anche il maledetto "'" che invece, normalmente, 
mi causa un problema, tanto che di solito lo elimino con un 
Replace(..."'"," ")
 
Adesso la tabella ha tutto e già posso scompattare i vari tipi di record 
(selezionati sulla base del numero con cui inizia il record):
 
- Il tipo record 1 lo inserisco in tblTrec1
- Il tipo record 2 lo inserisco in tblTrec2
 
e via discorrendo
 
Arrivati a questo punto, io posso usare Mid(record,col,campi) per tutto 
il record quando ci sono delle lunghezze fisse regolarmente rispettate 
(tipo 4 colonne per l'anno, 16 per il codice fiscale, 11 per la Partita 
IVA), ma quando si vuol significare, ad es. il prezzo:
 
Se è 12 euro, mi trovo ";12;resto del record"
Se è 212 euro, mi trovo ";212;resto del record"
 
Come devo fare per leggere solo "12" oppure "212" e poi proseguire dove 
mi sono fermato e leggere il resto?
 
Mi spiego meglio:
 
Io ho questi due record di tipo "3":
 
3;2020;07169241002;03;00132250622;30110004;02600000323;GGLNGL94B10A783T;062;059;#;74;00001;###;012;1013 
 
 
3;2020;07169241002;03;00132250622;30110004;02600000323;GRRVNT72B14A783F;062;008;#;2;00036;###;012;166
 
Entrambi sono identici fino a "059" per il primo e "008" per il secondo, 
quindi io posso tranquillamente usare MID fino al primo "#", e mi 
riporterei tutto senza errori.
Quelli che cambiano sono "74" per il primo record e "2" per il secondo
Ovviamente poi, la lunghezza del campo (e quindi anche del record) si 
riduce; poi tutto ciò che viene in seguito, ha di nuovo una lunghezza 
predefinita (puoi notare che prima dei "###" c'è un numero in formato 
"00000")
 
Il mio problema è leggere solo "74", gestire come mi serve, e poi 
ripartire dal contenuto subito dopo il ";"
E' ovvio che, con la lunghezza del record modificata con una colonna in 
meno, mi ritroverei tutto sballato.
 
Suggerimenti?
 
 
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)
 


Io continuo a non capire, perchè esponi cose che a mio avviso sono frutto della mancata gestione del FILE SPECIFICA.
 
Esempio banale:
12;AABCCC78056468Y0;BB
 
Se nel mio file SPEC, ho definito che:
Colonna1
NomeCampo="Importo" 
Tipo=Valuta
 
Colonna2
NomeCampo="CF"
Tipo=Testo
 
Colonna3
NomeCampo="NomeCampo3"
Tipo=Testo
 
Se importo quel file in una NuovaTabella [T1]
Ottengo:
Importo		CF  				NomeCampo3
12,00€		AABCCC78056468Y0	BB
 
Ora nel tuo caso specifico, continuo a non capire, se genero un File.csv:
3;2020;07169241002;03;00132250622;30110004;02600000323;GGLNGL94B10A783T;062;059;#;74;00001;###;012;1013 
 
Ottengo una Nuova Tabella [T1] con 16 Campi, che posso chiamare come credo già in fase di definizione di FILE SPEC che devi strutturare e SALVARE, io per velocità non li ho rinominati e prendono il Nome di DEFAULT con il progressivo.
Io ho solo definito il Campo3 e Campo7 come Testo, in quanto non vengono riconosciuti come Numero avendo lo ZERO come primo Dato.
 
Campo1	Campo2	Campo3		Campo4	Campo5		Campo6		Campo7		Campo8				Campo9	Campo10	Campo11	Campo12	Campo13	Campo14	Campo15	Campo16
3		2020	07169241002	3		132250622	30110004	02600000323	GGLNGL94B10A783T	62		59		#		74		1		###		12		1013
 
Per chiarezza li metto in VERTICALE:
Column1	3
Column2	2020
Column3	
7169241002
 
Column4	3
Column5	132250622
Column6	30110004
Column7	2600000323
Column8	GGLNGL94B10A783T
Column9	62
Column10	59
Column11	#
Column12	74
Column13	1
Column14	###
Column15	12
Column16	1013
 
Ora prova a ricapitolare cosa devi spacchettare dal momento che il contenuto dei singoli campi è UNIVOCO e suddiviso senza accorpamenti.
Probabilmente i campi DATA e VALUTA potrebbero richiedere una rimanipolazione, ma tutte cose che puoi automatizzare con una Query UPDATE subito dopo l'inportazione.
 
Se qualche cosa ho frainteso... devi fare esempi CONCRETI di dettaglio, altrimenti non ce ne andiamo fuori.
 
@Alex
 

 
 
Forse ho capito dove sta l'inghippo.
 
Ricapitoliamo:
dopo la selezione del file con la finestra di dialogo, procedo a fare 
come dici tu:
 
	Docmd.TransferText,acImportDelim, , [Tabella], [Percorso]
 
Il sistema mi mette tutto nella tabella specificata.
Il problema è che mette proprio tutto, incluso i ";" e in un campo unico 
che lui mi nomina "F1" (manco so da dove lo prende...).
 
Forse l'inghippo sta nel fatto che nel file CSV da acquisire, ci sono 
record diversi, che, se cominciano per 1, hanno una certa 
caratteristica; se cominciano per 2 ne hanno un'altra, e via 
discorrendo, e tutti uno sotto l'altro.
 
Giusto per capire, nel file mi ritrovo questi 3 record, uno sotto l'altro:
-------------------------------------------------------------------
 
1;2020;(partita IVA);03;(partita IVA);30110004;02600000323;46021;18409
 
2;2020;(partita IVA);03;(partita IVA);30110004;02600000323;(cod. 
fiscale);14794;5918;103;(Ragione Sociale);(partita IVA)
 
3;2020;(partita IVA);03;(partita IVA);30110004;02600000323;(cod. 
fiscale);062;059;#;67;00151;###;012;3044
 
------------------------------------------------------------------
 
L'idea sarebbe, in primo luogo separare i vari tipi record (il primo 
carattere del record) al momento dell'acquisizione e metterli in varie 
tabelle diverse a seconda di quanti tipi di record, e poi acquisirle in 
toto, ovvero includendo anche il CSV (il ";").
Solo così (forse) supererei uno scoglio non indifferente.
 
Ho letto la sintassi del TransferText, ma non so come fare per 
trasferire dallo stesso file "quel tipo" di record e nessun altro in una 
tabella specificata, poi "quell'altro tipo" di record in un'altra 
tabella specificata e via discorrendo; in pratica non sono riuscito a 
capire come inserire una sub "WHERE" nella TransferText
 
Non sarebbe, forse, più fattibile farlo direttamente in tabella?
 
Mi spiego meglio: anziché utilizzare direttamente TransferText, andrei 
ad utilizzare la prima opzione che mi hai detto (cioè Open For Input), e 
metto tutto in una sola tabella, dove riesco (settando bene la query) ad 
inserire in un campo a parte, il tipo di record (1, 2, 3 etx);
 
Quindi opterei per una serie di Query di accodamento per smistare i vari 
record sulle varie tabelle con la sub "WHERE" dove indicherei il tipo di 
record.
 
A questo punto mi ritroverei N tabelle dove avrei il record completo, 
incluso il ";".
Da questo momento mi perdo.
Ho provato a seguire anche quanto mi ha consigliato Shadogps, ma c'ho 
capito ben poco...
 
-- 
Carlo POTS


Carlo, secondo me, ribadisco, non hai definito il FILE SPECIFICA... non so più come dirtelo.
 
Per farlo devi fare l'importazione la 1° VOLTA a mano attivare il WIZARD e programmarlo come richiesto...
 
Quello che ti ho mostrato si fa in 10secondi... 
 
@Alex


Ci provo ...


 Ci provo ...
 
Allora: ho fatto la creazione del FileSpec con il Wizard come dicevi tu; 
ho selezionato, in una nuova tabella chiamata "Acquisizione", ogni campo 
(chiamato Campo1, Campo2, Campo3, etc) come campo di testo.
 
Lui mi scompatta tutto (diciamo) alla perfezione.
Provo ad andare tramite VBA e lancio l'istruzione:
 
         DoCmd.TransferText acImportDelim, , "Acquisizione", Percorso
 
Mi dà Errore RunTime 2391 - Campo 'F1' non presente nella tabella di 
destinazione "Acquisizione"
 
Vado nella FileSpec della tabella e cambio "Campo1" con "F1"
 
Rilancio l'istruzione VBA e il sistema mi porta l'intero record nel 
campo "F1" e gli altri campi rimangono vuoti
 
:'(


 
 
Se vuoi ti rigiro in privato il file da acquisire così puoi vedere 
meglio ...


Si prova ad inviarmelo e faccio una prova.
 
@Alex

Sei certo di aver SALVATO la specifica dopo averla impostata...?
Se non la salvi non viene memorizzata e non la trovi.
 
@Alex

 
 
Inviato
 
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)
 



L'ho fatto come hai detto tu, utilizzando il Wizard
 
 
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)
 


 @Alex
 
 
Dalla lunghezza del Thread pensavo a un qualche file-rompicapo, ma se si tratta semplicemente di un .csv delimitato, perchè non va bene un banale split?
 
- Leggi record per record il file di testo
- Splitti ogni recod in un Array
- Scarichi l'array nella tabella desiderata con un ciclo sull'insieme Fields 
 
Cosa mi perdo?
 
Saluti
 
 

 Saluti
 
Non so se ti sei perso qualche cosa o meno...
Non è che non va bene lo SPLIT, ho detto che non serve in quanto i campi sono divisi dal carattere del separatore, quindi a valle del TransfertText ha già la corretta suddivisione dei campi ed anche dei contenuti.
Tu perchè useresti lo SPLIT avendo già il contenuto separato...?
 
Saluti
@Alex
 


+1
 
 

 Tu perchè useresti lo SPLIT avendo già il contenuto separato...? 
 
Personalmente non utilizzo TransferText perchè talvolta, quantomeno con installazioni Runtime, semplicemente non funziona (problemi di registrazione di MsText.dll, o roba del genere).
Tutto qui.
 
 
 


Bene, grazie
 
@Alex


personalmente userei lo split che mi da maggiore controllo sui singoli campi
mi spiego
 
se ho una tabella ID Nome Indirizzo
e un txt
1;pippo;via roma
2;pluto;via mazzini
3;paperino & compani;via maradona
 
leggendolo sequenzialmente e splittandolo avrei poi la possibilità di 
agire su ogni singolo campo prima di salvarlo in tabella
 
banalizzo :
Campo1=UCASE(relativo campo array splittato)
campo2=replace(altro campo dell'array, , )
etc
 
inoltre mi svincolerei dalle specifiche di importazione che se non 
ricordo male vanno esportate nel pc di destinazione e quando le usai 
anni fa mi crearono problemi su pc dei clienti con il solo runtime
 
e nel caso di modifica del txt, in un attimo posso gestirmi il campo 
aggiunto/tolto da codice
 
BFS
 
 
 

Leggendo il 3D dall'inizio, aveo suggerito la lettura sequenziale rigo per rigo... penso si capisse..., con la conseguente gestione dei campi e scrittura in tabella.
Quindi concordo conquanto dici tu e Simone che il metodo vada bene.
 
Detto questo... dal momento che complicava la vita al RICHIEDENTE, ho suggerito il metodo sopracitato in quanto semplifica il codice da scrivere.
 
Se volete possiamo riprendere il 3D dal primo messaggio...
 
Saluti
@Alex

 
 
Ho ricevuto il test
Domanda: il FileSpec l'hai definito tu o l'hai preso direttamente dal 
file da acquisire?
 
-- 
Carlo POTS


 Carlo POTS
 
L'ho costruito come ti ho suggerito sopra... importando la 1° Volta a mano il File e definendo Campo per Campo....
Ora lo puoi modificare come ritieni.
 
Non ho compreso se, il risultato è allineato con quello che chiedevi.
 
@Alex

 
 
E' tutto esatto e preciso!
 
-- 
Lamps a tutti from Naples's kingdom Carlo POTS on VFR VTEC '02
& Bmw F650GS '00 "insomma, e' un VFR, mica una zoccola che cede appena ci
provi..." (cit. PMF)
 


Il 27/11/2020 13:34, @Alex ha scritto:

Alla fine ci sono riuscito.
Ho fatto esattamente come hai detto e sono riuscito ad impostare la SPEC 
come dicevi tu.
Adesso mi resta solo fare la "ripartizione dei pani e dei pesci" e tutto 
dovrebbe andare in ordine
 
Grazie di cuore


 Carlo POTS 
 
Come mai ora ci sei riuscito e prima NO...?
Ciao
@Alex

 Come mai ora ci sei riuscito e prima NO...?
 
 
Perché prima non mi ero soffermato sulle opzioni avanzate dove settare 
la SPEC.
 
Stavolta ho fatto più attenzione.
Capita quando devi fare i conti con la tosse da CoViD e la febbre a 38.8


 
 
Visto cosa scriveva l' OP evidentemente non aveva ben acquisito la cosa.
E, sono ecumenico, suggerivo una istruzione talvolta rejetta.
L'OP, ne sono quasi certo, ne era all'oscuro altrimenti non si sarebbe 
posto il problema.
Nel VBA '97 (o quello prima)  forse non c'era.
Personalmente usavo il "wizard" di acquisizione solo per roba usa e getta.
Come per tutte le cose ci sono pro e contro.
I contro citati da Simone e BFS. Non so se sono veri per la semplice
cosa che, come detto, usavo il transfertext solo per l'usa e getta.
Fortunatamente tre istruzioni VBA erano a prova di qualsiasi  versione.
 
 
 
-- 
ac (y-1=x)