Newsgroup: it.comp.appl.access
Titolo: Codice VBA che dopo esportazione/importazione non funziona piu'

Ambiente: Access 2013, tabelle collegate via odbc, Win8
Uso le procedure di Tim Abell per salvare in formato testo tutte le 
componenti di un progetto Access
 
https://github.com/timabell/msaccess-vcs-integration/commit/15b0c0c3818dcd4854c22d3c68b297d4e12efa3b
 
 
In sostanza vengono esportati moduli, form, report, query, come file di 
testo
Poi e' possibile creare un nuovo file Access vuoto ed importare tutte e 
componenti dai file di testo generati in precedenza
Ogni volta che eseguo questa procedura succede una cosa che mi sta 
preoccupando
Dentro al codice Vba di una form (o report), i nomi campi db usati, non 
vengono piu' visti correttamente
Ad esempio, se nel codice uso scrivere:
 
dummy=avvia_stampa_fattura(ID_DOCUMENTO)
 
quel ID_DOCUMENTO (che e' il nome del campo db) non viene piu' 
riconosciuto, mentre se ci metto un
 
dummy=avvia_stampa_fattura(Me!ID_DOCUMENTO)
 
lo vede correttamente
Ora, andando a vedere lo stesso frammento di codice PRIMA della 
procedura di esportazione/reimportazione, era esattamente
 
dummy=avvia_stampa_fattura(ID_DOCUMENTO)
 
e funzionava/funziona correttamente
La preoccupazione sta nel fatto che, dopo una reimportazione di un 
progetto, se lancio Debug/Compila mi passa tutto correttamente
Quando vado ad eseguire quella parte di codice o lancio il report che 
contiene quel tipo di istruzioni, segnala l'anomalia
E quindi sicuramente all'interno del programma appena reimportato ci 
sono ancora delle sacche di codice che non verra' eseguito correttamente
E che non cono in grado di riconoscere se non facendo eseguire il codice 
potenzialmente affetto dal problema, operazione estremamente laboriosa 
se bisogna avviare tutte le form e poi tutti i report
La domanda e': come mai sul nuovo programma il campo db non viene visto?
O meglio, come mai il Debug/Compile non mi avverte che il codice non 
'vede' il campo db?

Non so risponderti ma se chiami in campo della form corrente é d'obbligo la forma me.nome_campo o me!nome_campo
Secondo me sei stato fortunato che prima andasse

 e funzionava/funziona correttamente
[CUT]
 
Parlo di A2010 ma, presumo, sia lo stesso.
Il "Me"!miocampo è facoltativo nel riferimento ad un controllo nella 
form, ed è per questo motivo che prima dell'esportazione funzionava.
 
Dopo un'importazione in altro db vuoto, probabilmente quel "miocampo" è 
privo del riferimento alla form a cui si riferisce, da qui l'errore!
Dico probabilmente perché le mie conoscenze di access non sono così 
profonde da poter dare un risposta tecnicamente corretta.
 
Io ho pagato lo scotto nel non esplicitare specificatamente il "Me" nel 
riferimento ai controlli perché, nei debug del codice, non riuscivo mai 
a capire se un nome (es. "miocampo") si riferiva ad un controllo, ad una 
variabile o ad una routine se non facendo mente locale di volta in volta.
Conclusione? Io il "Me" lo esplicito sempre. Ho evitato, ed evito, 
parecchi mal di testa. :-)
 

 
 
In che senso 'fortunato'  ?
Stiamo parlando di un programma per computer, mica del comprendere la 
nascita dell'universo
Voglio dire, ci sara' pure un motivo se funziona cosi', il problema e' 
trovarlo, e non e' problam da poco
Ma essendo una macchina, sicuramente, deve esserci un motivo
 
 


Cosa intendi per
"..quel "miocampo" è privo del riferimento alla form.."
Se e' nel codice vba della form, il 'riferimento alla form' c'e'


Dici che dopo l'importazione del testo precedente salvato 
dummy=avvia_stampa_fattura(Me!ID_DOCUMENTO) funziona mentre
dummy=avvia_stampa_fattura(ID_DOCUMENTO) non funziona.
 
Dalle mie limitate conoscenze di access ho dedotto che quando lanci il 
comando senza il "Me!", access, nella versione 'importata', abbia perso 
il riferimento alla form da cui lanci il comando. È illogico? 
Probabilmente sì, come dici.
 
Però, se prima dell'esportazione funzionava e dopo l'importazione non 
funziona più, e questo è un dato di fatto, la causa, quasi sicuramente, 
è imputabile ad access per motivi che ci sfuggono.
 
Io mi sono limitato a comunicare quanto avevo appreso da un testo di 
programmazione di Mike Davis che ho studiato. Mi dispiace, purtroppo di 
più non ti so dire. Sicuramente @Alex, o qualche altro guru, potrà 
essere più illuminante.

Potrebbe essere una function....una variabile....una struttura.....lo dici tu che c'è il riferimento alla form, ma invece non c'è. E questo te lo dice anche Access. Ma tu non gli credi!!!!!


Si, e' evidente che versione importata e versione da importare sono 
diverse, anche se listando il codice sembrano uguali
Ma la versione importata solo col ID_DOCUMENTO non funziona mentre la 
stessa versione prima dell'importazione, solo col ID_DOCUMENTO funziona
Non volevo sminuire il tuo contributo alla soluzione del quesito posto 
ma capire cosa intendevi con '..riferimento alla form..'
Se stiamo parlando del codice DENTRO alla form, penso che tutti i campi 
db inseriti nella form stessa dovrebbero essere accessibili anche senza 
il Me! ,  o no?
Il mio timore e' che potrebbero esserci delle zone di codice, senza il 
Me!...  che il Debug/Compile non riesce ad intercettare, e che quando 
andranno in esecuzione daranno una bella segnalazione di errore
Inzomma, pensavo che sto Debug/Complie permettesse di scovare questo 
tipo di errori ma evidentemente non e' cosi'

 
 
In che senso 'lo dico io' ?
Se stiamo parlando di codice vba DENTRO alla form Xyz, il riferimento 
alla form c'e' (per il fatto che il codice e' dentro alla form stessa)
Oppure non e' cosi' ?


Dovrebbero sì... ma access dice no! Perché? Non lo sappiamo.
Di fronte a questa situazione penso che l'unica cosa pratica da fare sia 
quella di intercettare tutti i riferimenti ai campi nelle form e 
correggere la sintassi usando il Me! Lavoro certosino che non ti invidio.
Cercare di capire il perché mi pare sensato e doveroso, ma, almeno per 
ora, non vedo alternative.
Debug/compile: anch'io l'ho sempre considerato un valido aiuto, ma qui 
sembra non fare quello che ci aspettiamo. Bah...


Non so dirti il motivo tecnico profondo (Karl? Alex?) ma le buone abitudini é meglio prenderle subito. Quando ti riferisci ad un oggetto, dovresti specificarne la gerarchia. Forms!TuaForm!Controllo sarebbe la sintassi corretta. Vba mette a disposizione la contrazione Me per riferire all'oggetto corrente (come Parent e via dicendo). Ma vba non sa nulla di Forms, tant'è che é presente in tutto Office. Se non sei preciso, lui quando 'interpreta' può non prenderci. Il debug non lo segnala perché Access non é compilato, ma interpretato, e gli errori run-time sono sempre dietro l'angolo!!!


Ora non ho letto per intero tutto il 3D, ma posso darti 2 mie considerazioni.
 
1° Che hai sbagliato a non inserire la Gerarchia nel Riferimento del Controllo, perchè è vero che [ID_DOCUMENTO] è un Campo di Tabella, ma secondo me per come lo usi tu è un CONTROLLO in una Maschera associato al campo in Tabella, e, formalmente è necessario definirne la gerarchia.
 
2° Il Link cui fai riferimento mostra solo, almeno io vedo solo questo, il salvataggio di SQL della query che ovviamente non ha nulla di INCOMPATIBILE, mentre io immagino tu abbia esportato con SaveAsText:
Sub SaveAsText(ObjectType As AcObjectType, ObjectName As String, FileName As String)
 
Per questo secondo punto, per esperienza personale, ho notato che se esporti Versioni create con A2003, e le reimporti con A2013 o superiore... ci sono pezzi di Testo da condizionare prima dell'importazione perchè sono properties non valide e/o non riconosiute... spesso viene restituito un messaggio che tuttavia non è sufficiente a capire il punto, altre volte ricevi qualche indicazione più dettagliata, altre ancora nulla, ma qualche cosa è successo...!
 
Me ne ero accorto quanto provando ad usare questo sistema per un mio giochetto, mi ritrovavo un sacco di erorri nella Reimportazione..., da li cercando in RETE, anche se si trova veramente poco, trovai qualche riferimento UTILE per andare a discriminare le properties in relazione alla Versione, questo si traduce nel leggere il File.TXT con FSO, ed andare a cercare/sostituire le Variabili specifiche.
 
Non so se questo è parte e soluzione del tuo problema, di certo il punto 1 è in ogni caso una procedura che dovresti evitare di dimenticare...
 
@Alex


1° cosa intendi "..per come lo usi tu e' un CONTROLLO.." ?
Il campo ID_DOCUMENTOTESTATA e' il nome del campo estratto con una query 
sql e messo come RecordSource sulla form
Quello stesso campo e' usato come ControlSource su una textBox, di nome 
txtIdDocumentitestate
Quindi credo che per riferirsi al controllo (da codice vba interno alla 
form)  sia sufficiente richiamare txtIdDocumentitestate, mentre per 
riferirsi al campo db sia sufficiente richiamare ID_DOCUMENTITESTATE
 
2° si, e' stato usato il SaveAsText per salvare gli oggetti (form, 
report, module, query) come file di testo
 
Il file e' formato Access 2003, estensione mdb, lo era prima 
dell'esportazione (codice funzionante senza il Me! ) e lo e' dopo 
l'esportazione (codice non piu' funzionante)
 
"..se esporti Versioni create con A2003, e le reimporti con A2013 o 
superiore... ci sono pezzi di Testo da condizionare.."
Si, credo anch'io sia da queste parti il problema
Io ho esportato con Access 2013 ed importato con Access 2013, ma sono 
file mdb nati con Access 2003
 
Non e' che potresti passarmi qualche link a documentazione trovata o un 
suggerimento sulle keyword piu' efficaci da cercare?
 
 
 
 
 
 


Volevo scrivere
"..Il campo ID_DOCUMENTOTESTATA e' il nome del campo estratto con una 
query sql e messa (la query) come RecordSource sulla form.."


Se:
ID_DOCUMENTITESTATE (Campo)
txtIdDocumentitestate (Controllo associato a ID_DOCUMENTITESTATE)
 
Perchè nella Funzione che per quanto ho capito chiami nella Form, scrivi
    dummy=avvia_stampa_fattura(ID_DOCUMENTO) 
e non
    dummy=avvia_stampa_fattura(Me!txtIdDocumentitestate)
....?
 
Il Campo viene riconosciuto ugualmente, ma... quando non associato ad un Controllo, ho avuto anch'io qualche stranezza... mentre usando sempre il Controllo mai avuto problemi.
 
Ricordo che problemi importanti venivano generati nel caso in cui nelle Form fossero presenti IMMAGINI Embedded... in questi casi la probabilità di CORRUZIONE in fase di LoadFromText aumentava, anche questo con riscontri di vari articoli nel WEB... 
 
Purtroppo è passato molto molto tempo, ho provato a vedere se trovavo nel mio archivio qualche cosa, ma è adata male....
 
Provo ad inserire dei LINK che magari posono darti qualche spunto:
 
https://github.com/timabell/msaccess-vcs-integration/issues/13
 
https://social.msdn.microsoft.com/Forums/office/en-US/45b5af7c-5a99-4bd0-a443-2d11777ad175/cant-loadfromtext-anymore?forum=accessdev
 
https://github.com/bkidwell/msaccess-vcs-integration/issues/12
 
https://social.msdn.microsoft.com/Forums/office/en-US/869a0c08-c1b8-4001-bae6-2cfbb4778405/new-form-property-nosavectiwhendisabled?forum=accessdev
 
 
Non ho trovato altro, ma allora ricordo che mi ero armato di un EDITOR COMPARE(usavo banalmente NotePad++) per capire cosa non tornava nella versione NUOVA e Vecchia.
 
In sostanza avevo fatto un po di sperimentazione in questo modo:
1) Esportavo con SaveAsText tutto il Progetto Originale
2) Importavo in un nuovo A2016 gli Oggetti con il WIZARD, quindi compilavo.
3) Esportavo con SaveAsText tutto il Progetto(NewVersion)
4) ANALISI DIFFERENZE.
 
Non serve un progetto enorme, basta un progetto TEST con 1 Maschera, perchè gli errori vengono generati da NUOVE o MODIFICATE properties o attributi del File che non vengono correttamente interpretati.
 
Quindi individuati quelli poi TEXTEDITOR si modificano e funzionava.
 
Ovviamente un conto è se la cosa si fa UNA TANTUM, altro conto e provare a fare un giochetto AUTOMATICO...
 
Non ho altro da aggiungere.
 
@Alex

 query sql e messa (la query) come RecordSource sulla form.."
 
aggiungo questo mio riscontro personale,
praticamente NON ha attinenza diretta con il 3D
 
ho passato anch'io un paio di procedure da 2003 a 2013
(e POI HO CESSATO !!!)
e succedeva questo:
 
con il pc sviluppo (access full): tutto bene
con i pc lavoro (runtime): errore di mancato riconoscimento
in alcuni casi in cui avevo scritto form.nomeform.nomecontrollo
come criterio in query
 
Cambiando form. con form! tutto torna a posto
 
però credo proprio che l'ambiente 2013 "interpreti più strettamente" questo tipo di espressioni rispetto all'ambiente 2003 (e 2000)
specie nella versione runtime
 
motivo per cui continuo ad adoperare 2000 e 2003 su pc di sviluppo davvero vecchi (fanno solo quello) e mantengo anche il dubbio su come 2013 possa "comporre" una versione mdb 
(certo, le opzioni di registrazione ci sono tutte. ma ...)
 
solita nota: nel mio caso si tratta di PICCOLE O MODESTE procedure 


Usavo sempre il nome campo perche' pensavo fosse lo stesso del nome 
controllo, ma evidentemente non e' cosi'
Ora vedo i link
Molte grazie
 
 


Ringrazio per la condivisione esperienze
Anch'io sono passato dal 2003 al 2013 un paio di anni fa, con una 
discreta libreria di procedure che un po' alla volta sto passando alla 
nuova versione
Ma non intendo ritornare al piu' vecchio
Vorrei capire come usare correttamente il 2013 e perche' attualmente 
funziona cosi'
Quando lo scopriro' potro trovare una soluzione definitiva al problema
Forse c'e' solo qualcosa da cambiare durante l'esportazione o l'importazione

 Molte grazie
 
Se li chiami UGUALE non è meglio...?
Io differenzio i Controlli Associati da quelli NON associati proprio in questo modo.
Gli associati NomeControllo=NomeCampo
I Non Associati [txtNomeControllo].
 
Nel caso degli Associati, quanto ti ho esposto, semplifica anche i CICLI sulla collection FIELDS che mi aiuta a recuperare il Valore del Controllo associato:
Es:
Dim fld as DAO.Field
For Each fld in Me.RecordSetClone
   Debug.print Me.Controls(fld.Name).Value
Next
 
Saluti
@Alex


Ma se li chiami con lo stesso nome come fai a sapere se stai chiamando 
un controllo oppure un campo db?
 

 un controllo oppure un campo db?
 
Ma da una Maschera, dove hai i controlli Associati al Campo... perchè devi chiamare il CAMPO...?
Non ha senso.
 
@Alex

 un controllo oppure un campo db?
 
Preciso, se il Controllo ha il nome del CAMPO chiami sempre il CONTROLLO di default, proprio perchè non ha senso riferirsi al CAMPO.
 
@Alex


Prestazioni?
Ma da una Maschera, dove hai i controlli Associati al Campo... perchè 
devi chiamare il CONTROLLO...?
 
(attansion che la domanda non e' posta ironicamente, vorrei capire 
esattamente il motivo, se esiste, per cui e' preferibile chiamare l'uno 
o l'altro)
 


Non ho risposto ironicamente, e non mi risulta di essere un "giocherellone", anzi mi chiedo che ragionamento poni in essere per quello che dici.
Ragionando Tecnicamente, gli OGGETTI hanno dei LEGAMI, e le Maschere espongono e gestiscono gli Oggetti come i Controlli in modo Nativo.
Diciamo che lo strumento Grafico Form è basato su Oggetti grafici.
Tra questi non fanno eccezioni i Controlli, nemmeno quelli associati.
 
Questo è il motivo per cui ACCEDERE al controllo è il DEFAULT METHOD di riferimento alla collection CONTROLS che sia IMPLICITA o ESPLICITA.
 
Me.Controls("NomeControllo")
Me!NomeControllo
 
La dove non trova un Controllo il VBA cerca riferimenti nel CAMPO... quindi quello che fai è doppiamente errato.
 
Ti dirò di più, se devi accedere al CAMPO, lo si fa passando per RecordSetClone.Fields("NomeCampo"), oppure RecordSetClone.Fields(ctl.Name)
 
Ovviamente come sempre, ognuno poi si muove come crede anche pensado di fare giusto... vedi tu.
 
@Alex


Hai frainteso, non intendo dire che tua risposta e' stata ironica
Intendo dire che la mia domanda (essendo stata copiata paro-paro dalla 
tua risposta, cambiando solo Campo/Controllo) avrebbe potuto essere 
considerata ironica
Ma non voleva esserlo
Il mio intento e' capire sempre meglio come funziona lo strumento di 
programmazione per poterlo sfruttare correttamente
Il punto non e' nemmeno quale sia la sintassi corretta oppure l'ordine 
di riconoscimento dei vari oggetti, ma il fatto che prima 
dell'esportazione il codice funzionasse, dopo l'esportazione e 
reimportazione non funzioni piu', e da editor vba il codice si vede allo 
stesso modo, e' questo il fatto preoccupante
E non c'e verifica possibile perche' oltre al debug/compile (che passa 
correttamente) non mi risulta ci siano strumenti per combattere un 
problema di questo tipo


Il problema è come giustamente dici, conoscere lo strumento ed usarlo correttamente.
Quindi nelle Form si usano i riferimenti alle Form, ed i CAMPI li si usa SEMPRE e SOLO se associati ad un Recordset.
Qualsiasi altro utilizzo artistico, ancorchè consentito, è passibile di problemi.
Come il riferimento a FORMS e MASCHERE da Visualizzatore Oggetti nelle varie versioni...
 
Saluti
@Alex