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