Newsgroup: it.comp.appl.access
Titolo: Import html che non legge correttamente quanto Export-ato

Sto realizzando una routine per esportare in formato testo tutto il 
contenuto di un db
Access 2013 32bit, Win8pro 64bit, db Firebird 3.0 acceduto via odbc
 
Per esportare i dati uso l'istruzione:
DoCmd.TransferText acExportHTML, , nome_tabella, nome_del_file, True
 
Per importarli uso l'istruzione:
DoCmd.TransferText acImportHTML, , nome_tabella, nome_del_file, True
 
Bene, dopo l'importazione, nella tabella NON mi ritrovo il contenuto 
originale
Se vado a vedere con un editor di testo il file html generato, sembra 
corretto, in particolare un campo testo da 15 caratteri che uso per 
memorizzare l'ip address della postazione che ha scritto il record
Se vado a vedere la tabella, DOPO l'importazione, mi ritrovo che le 
stringhe del tipo 192.168.1.1 sono diventate  19216811
Sono spariti i punti, ripeto campo testo, e sul file esportato (formato 
html) i puntini ci sono
 
La domanda e': perche' l'importazione non rigenera il contenuto tabella 
come prima?


FORSE devi imporre il tipo dato a TESTO per il campo che contiene quel valore,
cosa da fare aprendo il pulsante <Avanzate> in cui si vedono i tipi di dato che Access "appioppa" di default (potrebbe essere NUMERICO nel tuo caso, e non va bene ...)


Non capisco bene il tuo suggerimento
Il campo incriminato e' gia' un campo testo
E' un varchar(15) nella struttura db, ed Access (nella tabella colegata) 
lo vede come 'testo breve' da 15 caratteri
Esportando in formato excel e poi re-importando ho risolto il problema 
contingente, ma vorrei capire come mai l'importazione dell'html 
esportato da poco non avviene correttamente
 

 esportato da poco non avviene correttamente
 
Access, NELLA SPECIFICA DI IMPORTAZIONE, genera "per sua intelligenza" un tipo di dati "ottimale" per ogni campo (e ne fa una tabella di sistema).
Nella tua continuazione NON dichiari che sei andato a riscontrare come è stato considerato quel campo nella specifica di importazione. 
Ripeto che ho il sospetto che Access lo stia considerando, in QUESTA TABELLA "INTERMEDIA" (interna !, di sistema ...), come un tipo di dato NUMERICO LONG.
Il tipo di dato si trova "fissato" nelle tabelle di sistema "SPEC" (nel 3D di qualche tempo fa trovi i nomi esatti), tabelle che all'occorrenza sono gestibili con insert e update di query di comando


Scuserai la mia ignoranza, ma non capisco di cosa stai parlando
Dove sarebbe questa 'tabella intermedia'?
Nel comando per l'importazione NON viene indicata nessuna 'specifica di 
importazione'
Come fa Access a considerare 192.168.1.1 un numero se il campo sul db e' 
un varchar() e difatti sulla tabella collegata viene visto come 'testo 
breve' ?
Non riesco a trovare nessuna tabella SPEC o che inizi con SPEC
 

 Non riesco a trovare nessuna tabella SPEC o che inizi con SPEC
 
allora
SE provi a fare una importazione manuale E SALVI la specifica di importazione
(pulsante <Avanzate>)  fra le tabelle di sistema appaiono le tabelle
MSysIMEXSpecs (master) e MSysIMEXColumns (slave)
(sono andato a rivedere per i nomi, ma l'altra volta, quando volevi esportare in file testo, avevi assentito sulla loro presenza)
 
In MSysIMEXColumns c'è il campo DataType che è il codice del tipo di dato
(ora non ho presente tabelle riempite, per cui non so indicare a memoria qual è il valore per un dato testo e quale per un dato numerico long)
 
Queste le mie "conclusioni" (strampalate ?):
1) con una operazione di exp-imp da codice penso che NON si generino queste tabelle (e niente si può controllare, anche per solo sfizio)
 
2) procedendo a mano (come riferivi di aver fatto con i tentativi imp-exp su file di testo) si ha la possibilità di registrare queste tabelle (pulsante <Avanzate>) e di vedere poi se Access in questo passaggio intermedio (creazione di tabelle  di sistema) si predispone un ostacolo al (ri)trasferimento perchè
"fissa" (con la sua intelligenza) il campo che inizia per 198 come numerico long (ma, ripeto. è solo una mia ipotesi)
 
Tutto questo per dire (in modo contorto ?) che Access può considerare in modo diverso un campo che inizia con "apparenza di numero" nelle due operazioni "automatiche" (MA consequenziali di import ("presa" di dati") ed export ("rilascio" dei dati)


Ti ringrazio per la pazienza
Ma non trovo le tabelle che indichi
Ci sono una decina di Msys ma roba del tipo MSysQueries, MSysObjects e 
simili

 simili
 
bene, vuol dire che non è stato eseguito il salvataggio
 
quindi basta rifare, da menu, le operazioni di Importazione file (Altro, da html) e appare una successione di videate a riempimento intuitivo.
 
DOPO aver indicato ("preso") il file html, Access "trova da sé" la tabella html con i dati presente al suo interno (ne propone una lista se ce ne sono più di una nel file html), 
 
E DOPO aver indicato se la prima riga della tabella html contiene i nomi dei campi,
 
basta premere il pulsante <Avanzate ...> in cui si vedono i tipi di dato che Access ha "indovinato" per i vari campi (e dove è possibile cambiare i settaggi di separatori numerici e di data). 
 
Quindi è qui che si vede quale tipo di dato Access ha assegnato al campo in questione (inizio 198.) ed è qui che si possono variare, a mano, i tipi di dato.
 
Puoi quindi salvare (<Salva con nome ...>) la specifica e vengono generate le due tabelle "IMEX".
 
INGHIPPO possibile: 
al termine l'operazione manuale PUO' NON riuscire perchè Access NON fa variare il carattere separatore dei campi (che in tutta evidenza QUI è la virgola, UGUALE al separatore predefinito dei decimali)
 
A questo punto, come detto nel 3D di qualche giorno fa su export file testo (situazione in cui però Access FA SCEGLIERE il delimitatore di campo) ci si trova in un vicolo cieco:
-o si cambiano le specifiche di sistema (nei modi indicati dall' altro rispondente)
-o ci si adatta (come faccio io) a tenere (variare) i tipi di dato decimali (o anche tutti ...) come stringhe (tipo dato testo breve) e poi si completa il trasferimento con una query di accodamento dati ad hoc (origine: tabella della importazione)
 
SE si segue questa strada, e si procede via codice, occorre registrare la specifica, e poi si possono anche gestire le tabelle "IMEX" con query di comando (insert, update, con le dovute cautele: prove "a perdere") rispettando il fatto che IMEXSpecs è Master di IMEXColumns 

 SE si segue questa strada, e si procede via codice, occorre registrare la specifica, e poi si possono anche gestire le tabelle "IMEX" con query di comando (insert, update, con le dovute cautele: prove "a perdere") rispettando il fatto che IMEXSpecs è Master di IMEXColumns
 
AGGIUNTA:
se il tipo dati decimale non appare fra quelli "indovinati", o se lo si elimina (sostituendolo), si può indicare come separatore decimale ANCHE UNA LETTERA DELL' ALFABETO ... (riscontrato)