Come esportare tutte le tabelle db ?

[RobertoA]

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 ?

[GiorgioDaPrato]

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

[RobertoA]

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?

[GiorgioDaPrato]

> 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?

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

[RobertoA]

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

[Potone]

Il giorno giovedì 15 giugno 2017 09:56:05 UTC+2, RobertoA ha scritto:
> Il 15/06/2017 09:48, GiorgioDaPrato ha scritto:

[Cut]

> 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

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.

[GiorgioDaPrato]

> 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.

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

[RobertoA]

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

[GiorgioDaPrato]

> 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

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)

[RobertoA]

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?

[GiorgioDaPrato]

> 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?

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

[RobertoA]

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