Newsgroup: it.comp.appl.access
Titolo: Creazione di una tabella con ADO non letta da un report

Ciao a tutti, ho il seguente problema già segnalato ma non ancora risolto. 
Vorrei fare un'altro tentativo prima di passare ad altra soluzione.
Tramite un tasto in una maschera svuoto e ripopolo una tabella ausiliaria. 
Apro un report che ha come sorgente la tabella appena aggiornata.
Il problema è che la tabella viene aggiornata correttamente, ma il report 
risulta vuoto.
Sembra un problema di sincronismo tra l'aggiornamento della tabella e 
l'apertura del report.
Nonostante aggiorno la tabella prima di aprire il report, querst'ultimo non 
riesce a leggere i dati che in tabella esistono.
Se salto la routine dell'aggiornamento della tabella, naturalmente il report 
si apre correttamente.
La cosa ancora più strana è che se esuguo la procedura passo passo non si 
verifica l'errore.
Sto utilizzando i comandi ADO. Mi sapreste dare un suggerimento prima di 
ripassare al vecchio DAO.
Esite un comando che dopo l'aggiornamento della tabella aspetti qualche 
secondo prima di aprire il report?
Ciao e grazie. 

 wrote in message
news:dpvuql$ftd$
1...@newsserver.cilea.it

Se è quello che penso è un problema che capitava anche a me.
Io agivo però con una connessione diretta al BE non usavo 
CurrentProject.Connection, quindi dovevo prima chiudere la connection
altrimenti non vedevo l'aggiornamento.
Ora la cosa strana è che sei passato ad ADO usando un BE(JET)
qualsiasi versione sia.
Il passaggio ad ADO è utile solo per rendere scalabile il progetto
ed esportabile su tecnologia Server, ma se rimani legato a JET
con un BE(Access) è decisamente fuori luogo.
@Alex
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio 
news:c7d37bda423c5c1a42...@mygate.mailgate.org...

Io in realtà non uso CurrentProject.Connection, ma la sintassi dell'apertura 
di una connect e di un recordset come da manuale, in più dopo 
l'aggiornamento della maschera chiudo sia i recordset che la connessione, ed 
imposto a nothini vari elementi. Ma a quanto sembra non serve.
Il passaggio ad ADO l'ho fatto più per spirito di curiosità nell'usare una 
nuova tecnologia, anche in previsione ad utilizzare VB per la creazione di 
applicativi che si connettono a DB. In più da Access 2000 in poi, ADO 
risulta nativo in access, mentre per DAO devo attivare il riferimento, e in 
fase di distribuzione installare la dll.
Anche se onestamente con access ho eseguito dei bei lavoretti, e in VB non 
sono ancora riuscito a sostituire tutte le comodità di access. Per esempio 
come gestire maschere e sottomaschere con le stesse possibilità grafiche che 
mi da access. Sembra che in VB la sottomaschera debba essere solo in formato 
tabellare tipo foglio di excell senza possibilità di modifiche grafiche ... 
ma questa è un'altra storia che affronterò in futuro.
Si ha sempre l'impressione che rimanere legati ad un ambiente non si cresca 
mai ... ma quanta fatica cambiare però.
Ciao e grazie per il consiglio. Penso che in questo caso ritornerò al 
vecchio ma funzionante DAO.

 vecchio ma funzionante DAO.
Ottima scelta.


 ha scritto nel messaggio 
news:15715f6cefca65f907...@mygate.mailgate.org...

Deguirò i tuoi consigli. Proverò comunque a vedere se risolvo con il tuo 
suggerimento, ma penso che ritornerò a DAo visto che in futuro sarà ripreso.
Ciao e grazie 1000.

 Deguirņ i tuoi consigli.
Hai dimenticato "Sģ Buana"..
i suoi erano consigli non ordini.
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 persiste.
Per completezza ti confermo che aprendo la connessione con currentProject la 
routine in ADO funziona.
Piccola curiosità:
che differenza c'è tra currentProject e CodeProject?