Newsgroup: it.comp.appl.access
Titolo: Come esportare tutte le tabelle db ?

Sto tentando di ciclare fra tutte le tabelle per esportarne il 
contenuto, una roba del tipo:
------------------------------------------
For indice_tabella = 0 To MyDbSorgente.TableDefs.count - 1
	nome_file_esterno = MyDbSorgente.TableDefs(indice_tabella).Name & ".txt"
         DoCmd.TransferText 
acExportDelim,,MyDbSorgente.TableDefs(indice_tabella).Name,nome_file_esterno
         Next indice_tabella
------------------------------------------
Sul TransferText mi butta fuori errore 3441
"Il separatore di campo nella specifica dei file di testo corrisponde al 
separatore decimale o al delimitatore di testo."
 
Allora, premesso che su Access 2003 questa routine andava perfettamente, 
ho provato a creare una specifica di esportazione prevedendo come 
separatore di campo il  ;  e come separatore decimale il  ,
Ovviamente tale specifica si basa su una lista colonne di una certa 
tabella/query, mentre io vorrei esportare tutte le tabelle del db
Salvata come SPECIFICA_CSV, vado ad inserirla come secondo parametro 
nella TransferText  ma non vuol saperne comunque di andare, mi 
restituisce un  3011  (Il motore di database di Microsoft Access non è 
in grado di trovare l'oggetto 'AGENDA#txt'. Assicurarsi che l'oggetto 
esista e che il nome e il percorso digitati siano corretti. Se 
'AGENDA#txt' non è un oggetto locale, controllare la connessione di rete 
o contattare l'amministratore del server.)
 
Ho provato a rileggere la documentazione sulla TransferText ma si 
consiglia sempre di creare la specifica di esportazione dimenticando che 
si parte da un'unica tabella/query
 
Ma come si fa andare 'sta benedetta TransferText col 2013 ?
 
 


aggiungo qualche rilievo personale (non è una risposta "risolvente")
1) nell'elenco argomenti di DoCmd.TransferText  vedo che manca il nome della specifica (deve stare al secondo posto, qui è omessa ma può essere una dimenticanza, altrimenti è causa di errore)
2) da quanto ho presente per l'utilizzo (Export-Import) di TransferText:
(specifiche TUTTE generate in A2003, utilizzate con Runtime 2007, e poi  "solo valutate" in A2013, proprio per vedere l'effetto che fa)
A) ho anch'io il riscontro che A2013 rileva incongruenza fra separatore di campo e di decimali (e per me lo fa ANCHE se si utilizzano solo campi testo):
bene, evoluzione del sistema ...
B) (per completezza) utilizzo il carattere § come separatore campo: è un'inezia,
però si deve comunque testare che il separatore utilizzato NON sia presente (digitato) nei vari campi testo 
C) specifica valida per TUTTE le tabelle ? provo a dire la mia MA NON HO RIPROVE
proverei, per arrivare a questo, di tenere nella specifica i nomi di campo generici che affibbia Access (campo1, campo2 ... mi sembra che parta da 1 e non da 0) con il contenuto SOLO testo: quindi la prova andrebbe fatta con la tabella che ha più campi e vedere se quella specifica trasferisce anche le altre tabelle. Ovviamente, anche se la cosa riuscisse, si avrà un buon lavoro da fare per riportare i file di testo in tabelle
D) come avrai visto nelle tabelle di sistema ci sono le due tabelle che contengono le specifiche: MSysIMEXSpecs, MSysIMEXColumns che "possono anche essere gestite" (ovviamente su una copia del db per questo solo scopo).
Nel tempo ho riscontrato (con A2003) che se si aprono queste tabelle con una query (select *) si possono appunto effettuare modifiche dei valori (e anche accodamenti di singole specifiche ritoccate) ovviamente rispettando il fatto che Specs è master di Columns. Ho anche notato che in Columns i due valori Start (sequenza "caratteri impegnati") e Width (caratteri del campo) possono essere variati e portati a questa situazione: Width sempre a 1 e quindi Start diventa la sequenza numerica delle colonne


Si, manca il nome della specifica esportazione perche' sul 2003 NON era 
obbligatoria (quella riga funziona correttamente ancor oggi sul 2003)
Mi sembra di capire che sul 2013 sia obbligatoria, e quindi cercavo di 
capire come fare per fornire una specifica di esportazione, visto che 
non devo esportare una tabella ma tutte le tabelle del db
E stare li a creare centinaia di specifiche esportazone diverse, una per 
ogni tabella, non e' sicuramente cosa salutare
Si ho visto le tabelle di sistema e finora l'unica soluzione pensabile 
sta nel creare in automatico tante specifiche esportazione, via vba, 
quante sono le tabelle, ma mi rifiuto di pensare sia l'unica via 
percorribile
Magari c'e' qualche trucco che con eleganza risolve il problema
Inzomma la domanda e': come fare per esportare su file di testo i dati 
contenuti in tutte le tabelle del db?
 

 contenuti in tutte le tabelle del db?
 
per il poco che posso dire io, 
E SE lo scopo è "essenzialmente" quello di un backup di dati
(copia di sicurezza a eventuale reinserimento "non automatico" ?),
E (soprattutto) considerando che le specifiche esigono il nome di campo
 
porterei sul versante tabelle il lavoro da fare:
terrei un contenitore (tabella temporanea) con il numero di campi uguale al numero massimo di campi delle tabelle di lavoro 
(nomi generici: campo1, campo2 ..., dati tipo testo, a valore predefinito "aaa")
Il ciclo che scorre le tabelle svuota-riempie questo contenitore
(recordset ?, query accodamento con i vari AS per rinominare i campi ?)
utilizzando così UNA SOLA SPECIFICA di transferText.
In fondo questa "soluzione" assorbe piuttosto bene le variazioni di struttura del db
 
 
 


Certo
Se si capisse la ragione per cui la TransferText sul 2003 andava 
correttamente, e sul 2013 non va piu', allora potrei anche mettermi 
nell'ordine di idee di lavorare per far andare questa cosa
Ma e' piu' forte di me, almeno per il momento che la procedura 
esportazione dati non mi e' indispensabile, non riesco/voglio dedicarci 
tempo, se va bon, altrimenti pazienza
 

 tempo, se va bon, altrimenti pazienza
Ciao
la ragione per cui non funziona c'è: alla Microsoft hanno fatto casino con le versioni di Access localizzate.
Il problema sembra essere legato ai caratteri di default (separatore, decimale, e delimitatore di testo) che access dovrebbe reperire dalle impostazioni del sistema operativo.
L'unico modo per far funzionare il tutto è impostare "Inglese (Stadi Uniti d'America) come formato nella zona geografica del pannello di controllo di Windows (cambiare i singoli caratteri nelle "impostazioni aggiuntive" dello stesso pannello non funziona... almeno a me).
Workaround che al solo pensiero si accappona la pelle.
 
Ciao
Mat.

 Mat.
 
questo è un mio riscontro con A2013 sul mio portatile (Win 8.1)
Premetto che ho situazioni di utilizzo (continuo) di transferText (EXP-IMP) con A2007 Runtime con specifiche generate in A2003, e che queste specifiche vengono rispettate da A2013 (file MDB).
 
Quindi ho provato con una tabella di dati (file MDB, NON ACCDB) che contiene i tipi di dato più abituali (testo, numerici long e double) E l'esportazione avviene SE "anticipo" il riscontro del wizard sul carattere delimitatore di campo
 
sequenza operativa:
selezione tabella
da Menu: esporta file testo
premo OK sulla dialog (dopo aver indicato il nome file testo)
nelle finestre di guida scelgo formato delimitato
e poi SUBITO inserisco io il carattere delimitatore 
(io uso sempre §, ma forse va bene tabulazione ...)
e il tutto si chiude bene 
 
NON ho fatto il riscontro sul riutilizzo della specifica,
se necessario posso farlo
così come posso riferire i settaggi che sono stati menzionati
(mi occorrerà l'indicazione di come trovarli ...)
 
PS: nel definire una specifica la prima cosa che guardo è il carattere delimitatore dei campi,
NON CREDO che Access, nelle versioni precedenti, accettasse la virgola (carattere predefinito) come delimitatore in presenza di campi con decimali, 
FORSE "non abbaiava" se i tipi di dato erano senza decimali
 


Non ho capito se PER OGNI tabella devi creare la propria specifica 
esportazione oppure basta ne crei una e poi l'esportazione di altre 
tabelle fila liscio

 tabelle fila liscio
 
vedo che la specifica, generata in automatico, si basa sui nomi di campo (e sul numero dei campi), quindi vale ANCHE per più tabelle ma solo se queste hanno, appunto, gli stessi campi (ma sono casi rari: io ho una tabella "movimentiAttuali" e una "movimentiStorici" identiche, per le quali adopero la stessa specifica per consegne dati al sistema aziendale)
 
Quindi tabelle differenti --> specifiche differenti,
Il dettaglio della specifica (nomi campo soltanto nel caso di EXP su file txt) è visibile dal pulsante Avanzate
 
Il "raggiro" proposto in precedenza era appunto quello di creare una tabella contenitore a numero e nomi di campi FISSI, in cui far confluire, ad una ad una, le varie tabelle (ognuna la riempirà per la sua parte): in questo modo si utilizzerebbe UNA SOLA specifica.
MA è da verificare in essere, penso sia anche necessario che i tipi di dato siano solo testo (credo proprio che anche il tipo dati sia "verificato" dall'automatismo)
 
 


Avevo compreso la tua idea di fondo
Ma praticamente, per 300 tabelle (e non ce ne sono due di uguali), come 
procederesti?
Quindi migliaia di campi
Bisognerebbe crearla a manina la specifica oppure no?
 
 
 

 Bisognerebbe crearla a manina la specifica oppure no?
 
Era ovvia la difficoltà di "grosso lavoro da fare"
che appunto per me è meglio spostare sul versante preparazione ad hoc tabelle
 
Comunque faccio un riepilogo per punti (così che li puoi anche saltare ...)
EVIDENZIANDO che "ci si ferma" alla possibilità di automatizzare il salvataggio dei dati (SOLO il salvataggio E NON il recupero ...)
AGGIUNGENDO una descrizione di un comportamento di Access, 
riscontrato con un mio utilizzo manuale, che "apre una prospettiva"
 
1) specifica: creazione, utilizzo, differenze (?) A2003-2013
 
-con utilizzo da codice NomeSpecifica è obbligatorio
DoCmd.TransferText [TransferType], [SpecificationName], [TableName], [FileName]
 
-nel caso si scelga il file testo con delimitatore di campo 
(si può anche scegliere l'opzione di lunghezza fissa per ogni campo, 
ma quel che segue vale per scelta delimitatore)
 
SE si sceglie la virgola come delimitatore (file CSV ?) 
c'è poi conflitto con il delimitatore dei campi decimali (virgola anche qui): 
 
-creazione: occorre utilizzare il wizard, i passaggi sono facili da seguire
 
selezione tabella 
da Menu: esporta file testo 
OK sulla dialog (dopo aver indicato il nome file testo) 
formato delimitato 
scelta carattere delimitatore E ALTRE OPZIONI che sono riepilogate in <Avanzate>
premere <Avanzate> per il riscontro opzioni E PER REGISTRARE NOME SPECIFICA <Salva con nome ...>
NOTA: questo nome VALE SOLO per strutture tabelle IDENTICHE a quella della tabella che lo ha generato
 
si porta a termine il wizard per controllare il file testo
(l'ultima conferma di salvataggio vale solo per riprendere manualmente l'operazione: la specifica per il codice si salva da <Avanzate>)
 
2) suggerimenti operativi
 
niente di nuovo ...
poiché c'è identità fra struttura tabella e specifica trasferimento (EXP, IMP)
il lavoro da fare è molto.
 
Le tabelle di sistema IMEX sono "gestibili" (con query e attenzione ...) ma credo sia più efficace agire con lo scopo di portare TUTTE le tabelle di lavoro in una unica tabella contenitore
(è ovviamente un ciclo: si svuota e si riempie il contenitore, si lancia il 
transferText e via andare ...)
 
struttura contenitore (visto lo scopo):
campi SOLO testo, nomi: campo1->campo50 (abbondare ...), 
con valore predefinito riconoscibile: NON si confonde così l'effettivo valore vuoto
 
 
3) PROSPETTIVA
se si segue questa strada occorre rinominare i campi delle tabelle di lavoro per "accodare" i dati, di volta in volta, nel contenitore
 
PERO' ho riscontrato questo comportamento
(utilizzo molto spesso file di scambio dati, realizzo procedure modeste, mirate ad aspetti tecnici specifici -sono perito tessile - e quindi ci sono scambi IMP-EXP in azienda, il tutto è un retaggio dell'attività da dipendente)
 
SE si crea una form continua (utilizzo del wizard) basata sulla tabella contenitore (quindi con i nomi di campo generici) succede questo:
 
COPIANDO PER INTERO (o in parte) un set di dati in forma tabellare
(una tabella di Access, o parte di essa, un set tabellare di Excel ...)
e AVVIANDO l'operazione di INCOLLA nella tabella
(dal menu o con Ctrl-V, con il cursore sul selettore record)
ACCESS (dopo un avviso di sistema) RIESCE A INCOLLARE (bene) TUTTO IL SET
perchè riesce a individuare (e mantenere) la sequenza dei campi degli appunti
E NON FA PIU' IMPEDIMENTO la differenza di nomi dei campi
(e va tutto bene anche se il numero di campi è minore)
 
Quindi se riesci ad automatizzare questo comportamento (macro ?)
le operazioni di utilizzo del contenitore (svuota-riempi) si sveltiscono
e resta punto fermo l'utilizzo di soli campi testo
 


Ringrazio per la risposta
Ma a 'sto punto tanto vale mandare a ramengo la TransferText con la 
motivazione 'essa non funziona'
Non e' che possiamo tribolare noi perche' essa non funziona, essa (cit. 
Balasso)
Tanto vale spendere il tempo necessario per preparare una procedura 
generica che cicla per ogni tabella, legge il tipo campi e poi butta 
fuori in xml o testo csv
Fatta una volta cell'avrem'mo per sempre