ciao
Alex
magari ti torna utile
fai attenzione a cosa cerchi nella riga FOR altrimenti unirai anche il
file che stai creando
=============
if exist C:\Programmi\PF\Pack\PacchettoPrefatt.txt del /f C:\Programmi
\PF\Pack\PacchettoPrefatt.txt
for %%A in (C:\Programmi\PF\Pack\AP*.txt) do (
type %%A >> C:\Programmi\PF\Pack\PacchettoPrefatt.txt
echo. C:\Programmi\PF\Pack\PacchettoPrefatt.txt
)
=============
No non è questo che mi serve, mi basta che
mi importi il file così comè, ho già la procedura
che mi fa scegliere il file sul pc e che mi estrae
i dati in un'altra tabella con i campi separati
Grazie lo stesso
Possibile che nessuno si sia mai imbattuto in
un problema analogo ?
No non è questo che mi serve, mi basta che
mi importi il file così comè, ho già la procedura
che mi fa scegliere il file sul pc e che mi estrae
i dati in un'altra tabella con i campi separati
Grazie lo stesso
Possibile che nessuno si sia mai imbattuto in
un problema analogo ?
[risposta]
Sì è possibile; ma se cerchi nell'help in linea di access (e nei vecchi
messaggi) troverai le istruzioni per accedere a file di testo (ereditate dal
lontano Basic): Open/Input/Close.
Visto che i dati nel record non sono separati, dovrai leggere tutta la riga
e tramite le funzioni di manipolazione delle stringhe
(Mid/Left/Right/Split/Instr/etc.etc.), estrarre i valori...
Ciao.
--
Sergio MAZZA
Grazie Sergio ma anche col metodo da te descritto
il risultato non cambia, i record vengono importati
alterando la loro formattazione quindi le funzioni
mid ecc. non possono estrarre valori se le loro
posizioni non sono costanti ma variano da un record
all'alltro, il problema non è estrarre le informazioni dal campo
ma fare in modo che ci finiscano così come sono,
e pensare che con Foxpro funziona alla grande.
Grazie Sergio ma anche col metodo da te descritto
il risultato non cambia, i record vengono importati
alterando la loro formattazione quindi le funzioni
mid ecc. non possono estrarre valori se le loro
posizioni non sono costanti ma variano da un record
all'alltro, il problema non è estrarre le informazioni dal campo
ma fare in modo che ci finiscano così come sono,
e pensare che con Foxpro funziona alla grande.
[risposta]
A questo punto bisognerebbe vedere come è strutturato il file; perché se
FoxPro "...funziona alla grande..." con Access dovrebbe essere la stessa
cosa.
Se tra un valore e l'altro c'è un carattere di tabulazione puoi specificarlo
nelle impostazioni di importazione...
Ciao.
--
Sergio MAZZA
Non credo ci siano tabulazioni (come faccio a saperlo?) sicuramente
ci sono degli spazi a causa della diversa lunghezza del cognome e nome
adesso non ho sottomano il codice di foxpro e non ricordo quale metodo
ho adoperato per importare i dati, con access funziona solo con
l'importazione
guidata salvando il relativo file della specifiche, altrimenti nisba
Ciao..........
Non credo ci siano tabulazioni (come faccio a saperlo?) sicuramente
ci sono degli spazi a causa della diversa lunghezza del cognome e nome
adesso non ho sottomano il codice di foxpro e non ricordo quale metodo
ho adoperato per importare i dati, con access funziona solo con
l'importazione
guidata salvando il relativo file della specifiche, altrimenti nisba
Ciao..........
[risposta]
Lo sai se il file o lo hai creato tu o sai come è stato creato;
l'alternativa è leggere il codice ASCII dei caratteri contenuti oppure
importare alcune righe in word e vedere i caratteri nascosti.
Secondo me c'è proprio un carattere speciale come separatore tra un dato e
l'altro...
Ciao.
--
Sergio MAZZA
Allora il file non lo creo io purtroppo viene generato da un CED
e sono i nostri stipendi (Sig!) , facendo una importazione con
word mi fa vedere tra la fine del nome e i primi codici
dei puntini così, anche se le righe restano allineate
119251001021157844175777777DSEFPINCO PALLINO...................
000010000100001000
mentre alla fine ci sono delle y coi puntini sopra ed alla fine il
ritorno a capo
Ciao
Cesare
[risposta]
Se è stato creato da un CED dev'essere strutturato in modo decente.
Le righe sono tutte della stessa lunghezza? Se è così devi indicare, per
ogni campo, l'inizio e la fine dei dati. es.
matricola da: 1 a 5 (11925)
sedelavoro: da 6 a 12 (100102)
etc. etc.
in questo modo definisci le specifiche di importazione.
Le y con i puntini potrebbero essere dei caratteri speciali per indicare la
fine della riga.
Ciao.
--
Sergio MAZZA
Scusatemi ma forse non mi sono spiegato bene
o non avete letto i post iniziali
1° Le righe sono tutte della stessa lunghezza
2° Ho già scritto che non posso usare il metodo docmd.transfer....
perchè può cambiare sia il nome del file che le coordinate di
estrazione dei dati dalla riga es: COGNOME oggi è nella posizione 32
domani 44 ecc.
3° io vorrei SEMPLICEMENTE CHE LA RIGA MI VENGA SCARICATA
COSI' COME' poi me lavedo io come estrarre i dati (sono 20 anni che
faccio programmi sono passato per DB III clipper ecc.)
Grazie comunque per la vostra pazienza al limite se volete vi
invio il file TXT così noterete che oltre ad estrarre solo NOME-
COGNOME -IMPORTO
bisogna ripurilo dai totali ecc. ma questo lo faccio già
Ciao
Per Sergio : con FoxPro bastava solo questa riga di codice
...
APPEND FROM NomeFile SDF
Ciao
Ok, allora puoi usare sia i comandi di gestione dei file ascii e
leggerti il tuo buffer della stessa lunghezza per poi dividerti le righe
oppure transfertext passandogli la variabile con il percorso completo
del file.
Fatto questo, spazzoli la stringa e estrai i tuoi campi in base ai
criteri che solo tu conosci.
Spettacolo il clipper!!!
Ho lavorato tantissimi anni con lui fino ad abbandonarlo alla prima
versione visual (ho ancora in giro programmi funzionanti)
Pensa che con la versione 5 ho iniziato ad utilizzare la programmazione
ad oggetti per poi trovarmi anni fa qualcuno che mi disse:
Abituati a programmare ad eventi perchè windows ragiona così.
L'altro giorno alla CISA hanno detto:
Abituatevi a programmare ad oggetti......... ????? ..... :-) (a volte
ritornano)
ciao
Cesare
Scusatemi ma forse non mi sono spiegato bene
o non avete letto i post iniziali
[risposta]
No comment.
1° Le righe sono tutte della stessa lunghezza
[risposta]
Bene.
2° Ho già scritto che non posso usare il metodo docmd.transfer....
perchè può cambiare sia il nome del file che le coordinate di
estrazione dei dati dalla riga es: COGNOME oggi è nella posizione 32
domani 44 ecc.
[risposta]
La soluzione potrebbe essere quella di richiedere, prima del transfer, il
path e il nome del file;
es.
Dim nomeFile as string
nomeFile = inputbox("inserire path e nome file da importare")
if len(nomeFile)>0 then
Docmd.Transfertext acImportFixed, ,"nomeTabella",nomeFile
endif
3° io vorrei SEMPLICEMENTE CHE LA RIGA MI VENGA SCARICATA
COSI' COME' poi me lavedo io come estrarre i dati (sono 20 anni che
faccio programmi sono passato per DB III clipper ecc.)
[risposta]
Non urlare (scrivere in maiuscolo) non ce né bisogno; come non c'è né
bisogno di continuare a dire che sono 20 anni che programmi, perché mi
preoccupa se con 20 anni di esperienza non riesci ad importare un file di
testo...
Grazie comunque per la vostra pazienza al limite se volete vi
invio il file TXT così noterete che oltre ad estrarre solo NOME-
COGNOME -IMPORTO
bisogna ripurilo dai totali ecc. ma questo lo faccio già
[risposta]
Non ce né bisogno (almeno per me); è più semplice di quanto pensi basta
applicarsi un poco...
Ciao
[risposta]
Ciao.
--
Sergio MAZZA
Esatto secondo me chi è nato con quei linguaggi, dove secondo me i
record li potevi
toccare con le mani e manipolarli come volevi, a prezzo di dover
scrivere per un giorno,
se penso alle query di adesso brrrr., non teme nessuna innovazione
infatti
HO RISOLTO grazie anche a tutti voi, in pratica l'errore consiste ne
fatto che
le informazioni dal file txt andavano estratte "affettate" prima
mentre io mi
ostinavo ad importarle prima in una tabella provissoria e poi
elaborarle
semplicemente cosi'
....
Open "C:\STIPENDI\NASBAN.TXT" For Input As #1
While EOF(1) = 0
Line Input #1, riga
Xnominativo = Mid(riga, 32, 30) ' le coordiante poi le
prendo da una tabella di riferimento che l'utente può cambiare quando
vuole
Ximporto = Mid(riga, 71, 7)
rst.AddNew
rst!nominativo = Xnominativo
rst!importo = Ximporto
rst.Update
Wend
Close #1
rst.Close
Altro che transfer ecc. alla fine quatro righe di buon vecchio
codice ...............
CIAO E GRAZIE A TUTTI
Scusami Sergio ma avevo già scritto che il primo aspetto
quello relativo alla selezione del file da cui importare l'avevo
risolto, così come il metodo trnsfertext non va bene perchè
funziona solo creando il file delle specifiche, che in questo
caso non possono essere adoperate perche le specifiche
di estrazione dei valori li deve poter cambiare l'utente.
L'esperienza maturata con altri linguaggi non ha niente
a che fare con quello utilizzato da poco specialmente
quando poi questo non funziona per quello che serve a me
infatti come dicevo prima quattro righe di codice...........
Spero di essere stato chiaro
Ciao
Scusami Sergio ma avevo già scritto che il primo aspetto
quello relativo alla selezione del file da cui importare l'avevo
risolto, così come il metodo trnsfertext non va bene perchè
funziona solo creando il file delle specifiche, che in questo
caso non possono essere adoperate perche le specifiche
di estrazione dei valori li deve poter cambiare l'utente.
L'esperienza maturata con altri linguaggi non ha niente
a che fare con quello utilizzato da poco specialmente
quando poi questo non funziona per quello che serve a me
infatti come dicevo prima quattro righe di codice...........
Spero di essere stato chiaro
Ciao
[risposta]
Quello che hai scritto fin dall'inizio io l'ho capito e già t'avevo
suggerito la soluzione:
'---
Visto che i dati nel record non sono separati, dovrai leggere tutta la riga
e tramite le funzioni di manipolazione delle stringhe
(Mid/Left/Right/Split/Instr/etc.etc.), estrarre i valori...
'---
fin dal primo messaggio...
Ciao.
--
Sergio MAZZA
Vedi Sergio non credo a questo punto
che trascinare oltre questa discussione serva a qualcosa,
anche per chi dovesse in futuro imbattersi in questa specifica
problematica .
Il nocciolo è che il metodo transfertex
non è adatto per importare dati da file testo
dove le posizioni dei valori all'interno della riga
devono essere passati come parametri dall'utente
Vedi Sergio non credo a questo punto
che trascinare oltre questa discussione serva a qualcosa,
anche per chi dovesse in futuro imbattersi in questa specifica
problematica .
Il nocciolo è che il metodo transfertex
non è adatto per importare dati da file testo
dove le posizioni dei valori all'interno della riga
devono essere passati come parametri dall'utente
[risposta]
Sei sicuro di quanto affermi?
Per quanto mi riguarda, nel campo della programmazione non do mai per certo
nulla; ci sono tanti modi per arrivare alla soluzione e tu ne hai toccate
solo 2.
Poi, ovviamente, ogni soluzione ha un rapporto costo/beneficio che varia in
base all'utilizzo...
Ciao.
--
Sergio MAZZA
Sono certo di quello che ho sperimentato io
e nessuno si è fatto avanti con altre soluzioni
per il resto sono perfettamente d'accordo con te
Ciao
Cosimo S.
1) Fare un file di guida da visualizzare insieme al primo rigo del file
di input e consentire all'operatore di scegliere il dove, il come il
quando. Insomma "rifare" il transfertext.
Pensavo fossero piu' punti invece e' uno solo.
P.S. non credo che con foxpro la cosa sia diversa.
--
ac
Sono d'accordo con te ma la mia soluzione è stata
molto più semplice e fa esattamente quello che serve a
me, per quando riguarda Foxpro la cosa è totalmente
diversa come scritto sopra importa direttamente il file
txt, con una sola riga di codice, in una tabella di appoggio
in modo integrale da dove poi venivano prelevati i valori richiesti
Ciao
Si infatti però se hai letto tutti i post precedenti, mi puoi
spiegare
come fai tenendo presente che il file txt lo deve selezionare l'utente
in giro per il pc, e che le coordinate dei valori da estrarre dalla
riga del testo
possono essere modifcate dall'utente (Inizio Cognome e sua lunghezza)
ecc.
Alla fine credo che il codice che ho postato più su sia il metodo
migliore
ciao
cesare
E dalli.
Bisogna decidere il bersaglio.
1) Leggere un record completo e' una cosa
2) Estrarre i dati dal record e' un'altra cosa.
Teniamo fissa la barra del timone.
Sul punto 2 ero intervenuto in precedenza.
sul punto 1 in seguito alla mia/tua precisazione su foxpro.
Come direbbe Di Pietro, le due cose fra loro non ci azzeccano.
Come lo risolvi poi e' un'altra questione.
Poiche' la cosa, a suo tempo, la ho affrontata, mi risulta che in caso
di liberta' assoluta dei dati o riscrivi un nuovo "transfertext" o fai
una cosa che risolve "parzialmente" la questione. Se la cosa che risolve
"parzialmente" copre le tue esigenze il problema e' risolto!
That's all. Folks
P.S. Normalmente leggo i 3D. Soprattutto se e' presente "Sergignho" Mazza.
--
ac
Caro Cesare non è questo il nocciolo del problema
tranfertex non va bene se devi passargli dei parametri
che non siano costanti
per il resto sono d'accordo con te infatti ho risolto così
Ciao Cosimo
Daccordo su tutto, il riferimento a Foxpro era solo un nostalgico
ricordo per un linguaggio molto (a mio parere) semplice ed
efficace per medio/piccole applicazioni come qualcuno ha
colto qualche post fa infatti con una sola riga di codice ......
Ciao
Daccordo su tutto, il riferimento a Foxpro era solo un nostalgico
ricordo per un linguaggio molto (a mio parere) semplice ed
efficace per medio/piccole applicazioni come qualcuno ha
colto qualche post fa infatti con una sola riga di codice ......
Ciao
[risposta]
E dalli co' sta riga di codice!
Analiziamo la riga di codice di foxpro: APPEND FROM NomeFile SDF
(riferimenti)
APPEND FROM Command
http://msdn.microsoft.com/en-us/library/hx56f6t3(VS.80).aspx
La parolina chiave è l'SDF:
'---
Include SDF to import data from a System Data Format file. An SDF file is an
ASCII text file in which records have a fixed length and end with a carriage
return and line feed. Fields are not delimited. The file name extension is
assumed to be .txt for SDF files.
Effective conversion of date data from SDF files to Visual FoxPro tables
requires data to be stored in YYYYMMDD format.
If date information is stored in ambiguous formats, you should map the date
column to a character column of appropriate width so you can inspect the
value and then apply the correct conversion routine to create correctly
formatted date data.
'---
Ora passiamo al TranferText che sappiamo tutti cosa fa:
TransferText Method
http://msdn.microsoft.com/en-us/library/aa220768(office.11).aspx
, tra le costanti da utilizzare nel parametro: TransferType c'è la:
acImportFixed
Il passaggio delle specifiche di importazione è optionale ed è chiaro che se
non lo definisco mi ciuccio il file così com'é con impostati i paramentri di
default (acImportDelim).
(ri)Leggedo la SDF: An SDF file is an ASCII text file in which records have
a fixed length and end with a carriage return and line feed. Fields are not
delimited.
La domanda mi sorge spontanea: la differenza tra SDF e acImportFixed dove
stà?
Io dico che Append From e TransferText fanno la stessa cosa: importano un
file di testo con la possibilità di specificare la struttura del tracciato.
A voi la parola...
Ciao.
--
Sergio MAZZA
Function getTextFile(oConfig) As Boolean
Dim fso, ts, fx, sText
Dim sName As String
On Error Resume Next
Set fso = CreateObject("Scripting.FileSystemObject")
Set fx = fso.GetFile(oConfig.getItem("InputFileName"))
If Err.Number = 0 Then
Set ts = fx.OpenAsTextStream(1, -2)
sText = ts.readall()
oConfig.setItem "InputFile", Split(sText, vbCrLf)
ts.Close
getTextFile = True
Else
oConfig.setItem "InputFile", Array("")
End If
Set ts = Nothing
Set fx = Nothing
Set fso = Nothing
End Function
> vedrai che il nome del file č possibile passarlo senza problema, poi la
> tabella di appoggio con un solo record la spazzoli e la gestisci con i
> tuoi parametri utente come vuoi.
> E' ovvio che anch'io preferisco la scelta della gestione file ascii
> tradizionale come vedi su un mio post precedente.
> I parametri utente potrebbero sia stare in una form che proponi dopo la
> selezione che in un file ini modificabile (in questo caso senza
> controllo immediato) dall'utente.
--
ac
[...]
> Pensa che con la versione 5 ho iniziato ad utilizzare la programmazione
> ad oggetti per poi trovarmi anni fa qualcuno che mi disse:
> Abituati a programmare ad eventi perchè windows ragiona così.
> L'altro giorno alla CISA hanno detto:
> Abituatevi a programmare ad oggetti......... ????? ..... :-) (a volte
> ritornano)
Ciao Cesare.
Ehm... Una cosa (eventi) NON esclude l`altra (oggetti). Con Visual Basic
(Classic, quello integrato in Access) *devi* programmare "a eventi" e
*puoi* programmare "a oggetti". Intendendo con questo gli oggetti
"tuoi", quelli che, se vuoi, tu costruisci nella tua applicazione coi
moduli di classe, perche' gli altri, quelli di Access, di DAO, ecc. che
tu voglia o no, ti tocca usarli, perche' te li trovi belli e fatti e, se
hai capito come funziona la programmazione a oggetti di VB, li userai
meglio.
--
Ciao!
Maurizio Borrelli [Microsoft MVP Office System]
http://www.riolab.org/
Scusami Sergio ma io se pemetti
guardo alla sostanza delle cose quindi
ripeto con foxpro importavo lo stesso file
perfettamente senza perdere la formattazione
con access utilizzando transfertex senza il
file delle specifiche (che nel mio caso non è
utilizzabile) l'importazione perde la formattazione
quindi non va bene al mio scopo, tutto il resto è
solo teoria, per voi guru di access è giusto che sull'NG continuiate
a disquisire su questo argomento, in modo da illuminare i neofiti
come me. Mi fa comunque piacere che su questo argomento
si sia sviluppata una così interessante discussione.
Buona domenica a Tutti.
Cosimo S.
Scusami Sergio ma io se pemetti
guardo alla sostanza delle cose quindi
ripeto con foxpro importavo lo stesso file
perfettamente senza perdere la formattazione
con access utilizzando transfertex senza il
file delle specifiche (che nel mio caso non è
utilizzabile) l'importazione perde la formattazione
quindi non va bene al mio scopo, tutto il resto è
solo teoria, per voi guru di access è giusto che sull'NG continuiate
a disquisire su questo argomento, in modo da illuminare i neofiti
come me. Mi fa comunque piacere che su questo argomento
si sia sviluppata una così interessante discussione.
Buona domenica a Tutti.
Cosimo S.
[risposta]
Teoria? Guru? Sei fuori strada.
Fammi capire; con foxpro utilizzi una istruzione con impostazioni di
default, con access l'istruzione simile di default non ottieni lo stesso
risultato... (tua) Conclusione, l'istruzione di access non va bene?
Per me la sostanza è la totale libertà di poter utilizzare qualsiasi
istruzione tramite le impostazione delle opzioni; e questa la trovo nella
transfertext e nella append from del foxpro, entrambi fanno la stessa cosa
basta passargli i paramentri giusti.
Quindi mi rimane ancora la domanda: dove sta la difficoltà nell'utilizzare
l'istruzione transfertext definendo le
Capiamoci; non voglio assolutamente polemizzare, mi interessa il tuo punto
di vista.
Non ho nessuna velleità di fare proseliti (non mi sento assolutamente un
Guru, la pelata è natural non religiosa!), la bontà dello strumento la devi
scoprire tu, io (e l'NG) posso (possiamo) indicarti delle possibili
soluzioni, sta a te decidere se adottarle o meno in base alle tue necessità.
Ma se dici che con un linguaggio ottieni dei risultati che con VBA non
ottieni, e questo non mi sembra corrisponda ai fatti, mi si scatena la
curiosità; non fosse altro perché ottengo risultati differenti da quanto
affermi...
Ciao.
--
Sergio MAZZA
Cesare
[...]
> Grazie Maurizio per la precisazione; sono stato superficiale, ma
> soltanto perchè ho estremizzato per fare una battuta.
Ciao Cesare.
No prob. Non era mica un rimprovero! :-) Solo una doverosa precisazione
per gli eventuali terzi non scafati.
Mi disppiace ma continuo a non essere d'accordo, lasciamo stare
Foxpro il punto è che con transfertext non puoi importare un file
di testo con lunghezza fissa dei campi da estrarre senza che questi
perdano la formattazione a meno che non venga usato un file
delle specifiche. Con questo metodo però non si possono
passare parametri dinamici all'istruzione, se tu con questo
metodo riesci a farlo allora faccelo sapere così impareremo
una cosa nuova .
Cosimo S.
Ciao
Cesare
P.S. comunque i campi non perdono la formattazione
E quello che all'inizio facevo io per questo ho fatto riferimento
a Foxpro solo che importando lo stesso file con transfertext
"giuro" i singoli record perdono la formattazione, invece come
scritto qualche post fa con una semplice procedura che legge
il file di testo direttamente rigo per rigo mi importo
i valori nei campi interessati così con una fava............
Ciao
P.S. Se i campi non perdevano la formattazione non stavamo
qua da tre giorni perchè il mio primo quesito era proprio questo.
Mi disppiace ma continuo a non essere d'accordo, lasciamo stare
Foxpro il punto è che con transfertext non puoi importare un file
di testo con lunghezza fissa dei campi da estrarre senza che questi
perdano la formattazione a meno che non venga usato un file
delle specifiche.
[risposta]
La formattazione la perdi perché non hai specificato il tipo di campo (es.)
hai dei valori numerici e li infili in un campo di testo; con la specifica
di importazione questo non succede.
Con questo metodo però non si possono
passare parametri dinamici all'istruzione, se tu con questo
metodo riesci a farlo allora faccelo sapere così impareremo
una cosa nuova .
[risposta]
"parametri dinamici"? Fammi un esempio.
Cosimo S.
..........
Seguendo la strada di importare tutta la riga in un unico campo
di una tabella, diciamo così d'appoggio, per poi estrarre i dati che
mi
servono
1° Devo per forza specificare un solo tipo di campo in quando i
valori
contenuti nel file txt sono sia numeri che alfabetici
2° Non posso usare la specifica perchè la stessa una volta che
l'hai creata non credo che possa essere modificata on fly
cioè passargli dei parametri che indichino al metodo transfertext
le posizioni dei valori da estrarre
>
> Con questo metodo però non si possono
> passare parametri dinamici all'istruzione, se tu con questo
> metodo riesci a farlo allora faccelo sapere così impareremo
> una cosa nuova .
>
> [risposta]
> "parametri dinamici"? Fammi un esempio.
Parametri memorizzati in una tabella contenenti le coordinate per
estrarre
i valori dal file txt, questi paramtri possono essere modificati
dall'utente
Mi spiego meglio
........
Come già accenato nei post precedenti ho la
necessità che l'utente possa cambiare i parametri di
estrazione dei valori all'interno della riga .
es: cognome - inizio posizione 32 lunghezza 30
importo - inizio posizione 71 lunghezza 7
Per semplificare, tutta la procedura doveva :
- Trovare sul PC il file txt da elaborare (già risolto)
- Importare ogni riga del file in una tabella appoggio con un solo
campo
- Elaborare i record della tabella di appoggio estraendo i valori di
cui
sopra in base ai parametri impostati dall'utente in una tabella
Parametri
cosa che lui può cambiare in base al tracciato record del file txt
Adesso grazie anche al tuo suggerimento che all'inzio io non avevo
afferrato la procedura fa alla grande:
- Trovare sul PC il file txt da elaborare
- Accede direttamente al file txt
- Legge le righe una per una ed estrae direttamente non
più in una tabella di appoggio ma nella tabella definitiva
le informazioni in base ai parametri della tabella coordinate
Ciao
..........
Seguendo la strada di importare tutta la riga in un unico campo
di una tabella, diciamo così d'appoggio, per poi estrarre i dati che
mi
servono
1° Devo per forza specificare un solo tipo di campo in quando i
valori
contenuti nel file txt sono sia numeri che alfabetici
2° Non posso usare la specifica perchè la stessa una volta che
l'hai creata non credo che possa essere modificata on fly
cioè passargli dei parametri che indichino al metodo transfertext
le posizioni dei valori da estrarre
Ciao
[risposta]
Avresti risolto con l'utilizzo del file schema.ini, come ti era stato già
suggerito:
'--- tratto dall'help del metodo TransferText ---
NomeFileSpecifiche Elemento Variant facoltativo. Espressione stringa che
rappresenta il nome di una specifica di importazione o esportazione creata e
salvata nel database corrente. Per un file di testo a larghezza fissa,
occorre specificare un argomento o utilizzare un file schema.ini, che deve
essere memorizzato nella stessa cartella del file di testo importato,
collegato o esportato. Per creare un file schema, è possibile utilizzare
l'Importazione o l'Esportazione guidata. Per i file di testo delimitati e i
file di dati di stampa unione di Microsoft Word, è possibile omettere questo
argomento per selezionare le specifiche predefinite di importazione o
esportazione.
'---
Es. (preso da MS)
(contenuto del file schema.ini)
[Contacts.txt]
ColNameHeader=True
Format=FixedLength
MaxScanRows=0
CharacterSet=OEM
Col1="First Name" Char Width 10
Col2="Last Name" Char Width 9
Col3="HireDate" Date Width 8
(esempio di utilizzo)
Sub Test1()
DoCmd.TransferText acImportFixed, , "Contacts", "C:\My
Documents\Contacts.txt"
End Sub
Sub Test2()
DoCmd.TransferText acImportFixed, "C:\My Documents\Schema.ini",
"Contacts", "C:\My Documents\Contacts.txt"
End Sub
I file .txt e .ini devono stare nella stessa cartella.
Ora sai come creare/leggere un file di testo, ti rimane semplice crearti un
file ini per ogni txt da importare...
Ciao.
--
Sergio MAZZA
No grazie preferisco usare il mio metodo
sai sono un po all'antica e poi lo trovo molto più semplice
Ciao e Grazie
P.S. Ho fatto comunque una prova ma il file delle
specifiche non riesco a trovarlo
No grazie preferisco usare il mio metodo
sai sono un po all'antica e poi lo trovo molto più semplice
Ciao e Grazie
P.S. Ho fatto comunque una prova ma il file delle
specifiche non riesco a trovarlo
[risposta]
Il file schema.ini lo devi creare tu; invece la tabella con le specifiche è
presente nell'mdb ed è nascosta (non visibile) ma dalle opzioni puoi
impostare la visualizzazione per "studiarla" oppure puoi importarla in un
altro mdb...
Ciao.
--
Sergio MAZZA