[VB6] ADO e i ritardi sulle DBGRID

[matt_vb6]

Ciao a tutti ,
approfitto di questo post per salutare tutti i partecipanti del forum ... spero nel tempo di dare un contributo alla causa .

Il mio problema è questo (premetto che ho cercato invano su internet) :

1) utilizzo ADO
2) ho un form con una truedbgrid , dove posso modificare i record
3) modifico i dati del recordset
(non direttamente dalla grid ma usando un normale recordset.update dopo avergli passato i valori dalle caselle di testo ...

e la griglia NON MI FA VEDERE l'aggiornamento appena fatto ...

Tentativi non funzionanti :
1) recordset.refresh , recordset.requery , recordset.resync
2) Dbgrid.refresh , Dbgrid.rebind

Unico metodo funzionante
Mettere sleep 1.000 prima del Recordset.refresh

Adesso io mi domando , è possibile che una tecnologia avanzata come ADO
non riesca a fare quello che DAO fa con una semplicità estrema ?
(ehh si , perche DAO questo problema non lo ha ...)
E devo scrivere nel codice una porcheria come sleep 1000 ?!?!?!?!?

Spero vivamente di non essere capace e che qualche anima pia mi dica ... ma come ??? non metti questo ? xxxxxxxxxx ??

Grazie a tutti e ciao buon WE

[gibra]

Questo avviene perchè per impostazione predefinita il refresh dei dati nel motore JET 4.0 avviene ogni 5 secondi, e se rileggi i dati prima che ciò avvenga, sono sempre gli stessi.
Le versioni precedenti del JET non avevano questo problema, ma vi sono delle precise ragioni dato che DAO non è nato per l'utilizzo in rete, ma in locale, quindi un continuo refresh dei dati porta anche ad un maggior traffico di rete.
Questa caratteristica ha fatto credere a molti che ADO fosse più lento di DAO.

Per risolvere il problema, dopo un'aggiornamento devi forzare il refresh della cache usando la libreria Microsoft Jet and Replication Objects MSJRO.DLL che è già installata in Windows dalla versione XP in avanti (forse anche Windows 2000 ma non ricordo bene), quindi una volta referenziata al progetto, la dichiari Public in un modulo:

Public Jet As JetEngine

poi all'avvio della applicazione crei l'istanza

Set Jet = New JRO.JetEngine

Dopo di ché potrai (dovrai) chiamare il metodo RefreshCache nelle routine che usi per aggiornare i dati, ovviamente DOPO l'aggiornamento:

Jet.RefreshCache CN

Nota: CN è l'oggetto ADODB.Connection con cui hai aperto la connessione.

Dopo, potrai aggiornare i tuoi controlli nel modo classico. Esempio per il recordset:

Resync adAffectCurrent, oppure Requery a seconda dei casi.

ed aggiornerai automaticamente anche il TDBGrid (per me insuperabile!)

[matt_vb6]

Ti ringrazio davvero tantissimo !!!
Una risposta veramente professionale complimenti !

Sto aggiornando un progetto in azienda e sto migrando da DAO ad ADO
e sembrava tutto cosi semplice fino all intoppo tremendo dei ritardi
con "compromessi" inaccettabili .
La mia idea era migrare prima su ADO e poi a visual basic 2008 .

Devo dire la verità che dopo 20 anni di programmazione non mi andava tanto
la "legge" Microsoft di riscrivere tutto il codice e sopratutto non vedo i vantaggi
mirabolanti di passare a .NET .
Ma si sà in questo mestiere chi si ferma è perduto e allora mi piego ...

Ho letto anche nel forum che i controlli ADOdatactrl sono visti come fumo negli occhi ...
per cui li sostituiro' con normali ADODB.Recordset .

Grazie e prometto di dare il mio contributo !

[gibra]

Originariamente inviato da matt_vb6
Ti ringrazio davvero tantissimo !!!
Una risposta veramente professionale complimenti !

Prego.

Originariamente inviato da matt_vb6
Sto aggiornando un progetto in azienda e sto migrando da DAO ad ADO
e sembrava tutto cosi semplice fino all intoppo tremendo dei ritardi
con "compromessi" inaccettabili .
La mia idea era migrare prima su ADO e poi a visual basic 2008 .

Devo dire la verità che dopo 20 anni di programmazione non mi andava tanto
la "legge" Microsoft di riscrivere tutto il codice e sopratutto non vedo i vantaggi
mirabolanti di passare a .NET .
Ma si sà in questo mestiere chi si ferma è perduto e allora mi piego ...

Mica è obbligatorio migrare a .NET a tutti i costi!
Insomma, voglio dire che bisogna molto valutare i pro e i contro.
Migrare al NET può essere solo giustificato dal fatto di ottenere migliorie altrimenti non ottenibili, altrimenti non vi è motivo.
Una migrazione può essere un vero bagno di sangue, in termini di tempo e risorse, perchè bisogna riscrivere tutto il codice imparando da zero un nuovo linguaggio perchè il .NET è completamente diverso! Ma a questo punto allora preferisco usare C#, invece del VB.NET.

In ogni caso, per riscrivere un'applicazione già funionante devi avere dei motivi più che ottimi per farlo, se invece inizi a scrivere una nuova applicazione allora sì che non vi sono motivi validi per scriverla ancora in VB6!

Tienilo presente e fatti due conti, prima di migrare, valutando bene se e quali benefici reali ottieni riscrivendo tutto il programma.

Originariamente inviato da matt_vb6
Ho letto anche nel forum che i controlli ADOdatactrl sono visti come fumo negli occhi ...
per cui li sostituiro' con normali ADODB.Recordset .

Ottimo scelta! Ti risparmierai un sacco di grane...

Per semplificarti la vita ti indico 3 ulteriori suggerimenti, soprattutto se usi l'applicazione in multi-utenza:

1) usare Command e Parameter per l'accesso ai dati.
Il codice è più robusto, efficiente e facile da creare e manutenere.
Vedi questo mio articolo, con codice a corredo (e qualche tips!):
ADO, Parametri ed affini
http://nuke.vbcorner.net/Articoli/VB...5/Default.aspx
(ove troverai altri progetti utili sempre su ADO).

2) Compattare sempre il database in uscita dell'applicazione.
In questo modo eviterai di avere grane sulla rottura del DB, che per Access è un punto debole. Ovviamente in ambiente multi-utenza la compattazione verrò eseguita solo dall'ultimo utente che si disconnette, ma è sufficiente.

3) non usare i campi Contatori di Access, che possono provocare gravi danni in multi-utenza. Usa un contatore 'custom' come spiegato qui:
HOW TO Implement Multiuser Custom Counters in Jet 4.0 and ADO 2.1
http://support.microsoft.com/default...b;EN-US;240317


Ho realizzato diverse applicazioni multi-utente che girano in LAN con 10-15 utenti (VB6 + Access) e non ho mai avuto alcun problema.

Infine ti segnalo questi link che sono a mio avviso tutti molto utili:
How to use connection control to prevent users from logging on at run time in Access 2002
http://support.microsoft.com/kb/287655/en-us

Determine Which and How many Users are Connected to a Database
http://www.freevbcode.com/ShowCode.Asp?ID=4768

How to keep a Jet 4.0 database in top working condition
http://support.microsoft.com/kb/303528

[matt_vb6]

Grazie mille per i consigli .

Ho provato stamattina e ho scoperto che :

1) Il datactrl maledetto non si aggiorna anche se richiami Jet.RefreshCache CN
2) Ho messo un recordset normale è ... funziona !

Se posso ricambiare credo che il nostro forte sia la gestione dinamica delle immagini con Crystal Report 11.5 .
Ci occupiamo di gestionali aziendali multiutenza dove l'uso di immagini è molto importante .

Grazie di nuovo

[gibra]

Originariamente inviato da matt_vb6
Grazie mille per i consigli .

Ho provato stamattina e ho scoperto che :

1) Il datactrl maledetto non si aggiorna anche se richiami Jet.RefreshCache CN
2) Ho messo un recordset normale è ... funziona !

Questa è una delle tante dimostrazioni (semmai ce ne fosse ancora bisogno) del perchè il Data control è un'altra ciofeca, pari all' ADODC, come più o meno tutti i controlli della serie Data<qualcosa>.
Sembrano utili a 'qualcosa' (Microsoft li ha fatti apposta solos per vendere...) ma nella realtà quando si il gioco si fa duro, mostrano tutti i loro limiti.
Ma questa è una cosa orami assodata da tempo...

Nello specifico, il Data control è un semplice controllo che non è collegato dinamicamente alla connessione, quindi dopo aver chiamato il metodo RefreshCache dovresti a sua volta fare il Refresh del controllo stesso.
Almeno credo sia così. Sinceramente non uso più il controllo Data da moltissimi anni (non ricordo nemmeno quanti), quindi potrei anche dire una fesseria.