[VB6] Conversione DAO --> ADO & Crystal Report

[matt_vb6]

Ciao a tutti ,
sto affrontando la conversione da DAO ad ADO e sto scoprendo sulla mia pelle e su quella dei clienti le varie rogne che ci sono quando entrambi ESISTONO sul medesimo progetto ...
Lo so è una pazzia ma nel progetto ci sono circa 530 finestre e non è possibile fare una conversione integrale .
La grana grossa è che se usi DAO , ADO ci mette circa 2 secondi a vedere i cambiamenti e viceversa . UN DISASTRO !!!
Pensate ad una distinta base che calcola i costi convertita con ADO e i vari inserimenti della distinta fatti con DAO , un casino ....
La routine che esegue la query non vede mai l'ultimo record , non si accorge della sua esistenza prima dei famigerati 2 secondi . Quindi i prezzi vengono tutti sbagliati .
NON esiste refresh che tenga ... ho provato con :

WS.Databases.Refresh
DBEngine.Idle dbRefreshCache
JetCache.RefreshCache ADODBCONN

Nulla ! Il problema rimane (anche se misterioso poichè alla fine entrambi usano quella porcheria chiamata JET ) .
La soluzione è quella di convertire tutte le varie finestre collegate tra loro in modo che i dati siano sempre aggiornati .

Alla fine sorge un'altro enorme problema : i reports !!!!!
Crystal usando l'apertura del database con jet HA LO STESSO PROBLEMA ...
vede i dati dopo qualche secondo e quindi non stampa qualche record (pensate alle risate quando si stampano le fatture...)

Ed ecco il nocciolo del problema ... devo rifarmi 250 reports o posso intervenire
in runtime e cambiare l'apertura del database da DAO a ADO ?

Sapete se c'è un metodo migliore per fare una conversione del genere ? (Ricordate però le 530 finestre zeppe di recordset e codice ...)

[gibra]

Capisco il tuo problema, purtroppo!
Anch'io a suo tempo usai DAO (ma era quello che passava il convento).
Ma quando è arrivato ADO non ci ho pensato due volte.

Però, sinceramente, voler migrare 'un po' alla volta' non mi trova d'accordo.
A parte il fatto che anche facendo così sei costretto a mettere mano a tutte le chiamate di DAO perchè usando insieme ADO e DAO devi per forza anteporre a tutti i metodi la classe che usi a seconda se DAO o ADO, cioè

Dim rs As DAO.Recordset
Dim rs As ADODB.Recordset

Ma, in ogni caso, usare insieme ADO e DAO vuol dire essere "temerari" amanti del rischio.
Tra l'altro, poi, questo ti costringe a scrivere ulteriore codice solo per evitare rischi e problemi, ed è tempo perso perchè sarà codice temporaneo.
Vedi ad esempio il refresh della cache che usanod solo ADO funziona a meraviglia!!!

Il mio consiglio è quello di migrare tutto su ADODB (eliminando anche tutte le porcherie di controlli insulsi come Data control!).
Ovviamente devi essere tu a valutare il mio consiglio in base alle tue esigenze in termini di risorse economiche e risorse umane, ognuno deve fare i conti in tasca propria.
Ma se ti fai i conti in tasca, ci metti poco a capire quanto tempo rischi di perdere per aggiustare alla meno peggio le cose, ed è tutto tempo buttato via.
Invece questo tempo perso potresti investirlo nel creare codice che serva a migliorare la migrazione.

Poi rilascerai l'aggiornamento del tuo programma solo alla fine, dopo i dovuti tempi di test.

Mi permetto un paio di consigli (scusami, magari li conosci già, ma meglio dirlo per niente piuttosto che non dirlo quando invece era utile):

1) Creati una classe 'helper' in cui centralizzare tutti i metodi INSERT, UPDATE e DELETE.
In questo modo è più semplice migrare e manutenere il codice.
Se un domani devi migrare verso un database diverso, hai tutto in una classe, e basta modificare solo la classe!

2) Usa sempre Command e Parematers per i metodi di cui al punto 1.
.... Se dai un'occhiata al mio articolo ti renderai conto degli enormi vantaggi!
.... vedi i link che ho indicato qui
.... Tipi di dati non corrispondenti nell'espressione criterio
.... http://forum.html.it/forum/showthrea...9#post12894609

Inoltre anche qui troverai indicazioni interessantissime:
http://www.xtremevbtalk.com/showpost...00&postcount=4

[gibra]

Scusa, dimenticavo i report!

Certo che NON devi rifare i report. Basta cambiare la stringa di connessione.
Immagino che i report siano esterni, cioè non inglobati al programma.

[matt_vb6]

Grazie Gibra ,
proverò a seguire il tuo consiglio ... quello che mi preoccupa è la fase di testing... su 530 finestre ci sono milioni (!!!) di linee di codice e migliaia e migliaia di combinazioni possibili cmq è doveroso farlo .

Per quanto riguarda i report si , sono esterni all'applicazione e creati con crystal 11.5 .
Ma è Crystal 11.5 che ti chiede come connetterti al database quando crei un nuovo report , non lo faccio da codice ...
Da codice gli passo i percorsi del database per essere sicuro che in qualunque cartella siano trovino sempre il database .... in questo modo :

Dim crxSubreport As CRAXDDRT.Report
Dim crxSection As CRAXDDRT.Section
Dim crxObject As Object
Dim crxSubreportObject As CRAXDDRT.SubreportObject


ObjReport.FormulaSyntax = crCrystalSyntaxFormula

For cnt = 1 To ObjReport.Database.Tables.Count
ObjReport.Database.Tables(cnt).Location = PathMdb
Next

Ma di rifare la stringa di connessione non ne ho trovato traccia (sicuro non guardo nel posto giusto...)

[gibra]

ObjReport.Database.Tables(cnt).Location = PathMdb

Non conosco CR11 quindi non so esattamente come funziona, in effetti non uso più CR da secoli, ma non penso proprio che basti indicare il percorso (come mostri nella riga sopra).

Supponiamo che il database è protetto da password?
Quale provider viene usato?
Da qualche parte vi saranno le impostazioni, e secondo me sono DENTRO ad ogni report che esporrà queste proprietà così da poterle impostare direttamente da code.

Una volta impostata la stringa di connessione generica del tuo database, la userai per impostare quella di tutti i report, quindi l'istruzione sarà la stessa ma cambierà solo il nome del report (ed eventuali altri parametri che già usi per conto tuo).