Newsgroup: it.comp.lang.visual-basic
Titolo: vb6 dao2ado

Conoscete un tools che mi migra un megaprogetto da vb6dao  ad  vb6ado  ?
Grazie 

 Conoscete un tools che mi migra un megaprogetto da vb6dao  ad  vb6ado  ?
Il motivo della migrazione?
Non penso esista nulla del genere, cos� come non mi fiderei di un qualsiasi
tool di conversione automatica.

Il motivo della migrazione � che potrei gestire basi dati diverse ( 
access,sqlserver,mysql). Per piccole realta lasciarei access coem database , 
ma  le prestazioni  sono pessime   ( esempio salvare una fattura 
impiegherebbe circa 20 minuti, contri i   0.3 sec secondi di dao ).
Ottimizzando il codice potrei migliorare i tempi anche se per alcune 
operazioni tipo ricalcolo progressivi di magazzino si parlerebbe  comunque 
di diverse ore di esecuzione. che macello .
sinceramente sono molto indeciso.
"Andrea [Work]" <andrea.isw...@gmail.invalid> ha scritto nel 
messaggio news:12i396ah9dw27$.6xkxug6mhv04.dlg@40tude.net...


 sinceramente sono molto indeciso.
Lascia stare Dao contro Ado o Access contro SqlServer contro MySql.
A meno che tu non stia parlando di database con milioni di righe (su 
cui, effettivamente, Access va molto in crisi mentre per altri sono 
bazzecole), per il resto posso garantirti che il problema NON ï¿œ nï¿œ il 
db nï¿œ la libreria, ma il tuo modo di operare (che ignoro, ma 
'percepisco' che sia sbagliato, dai numeri che citi).
Alberto
-- 
Noi ammazziamo solo per motivi buoni.
E quando sono buoni, sta a noi indicarlo.
[Guccini]


Guarda, qualche tempo fa (per modo di dire... sono passati quasi 10 anni) ho 
realizzato un gestionale (bolle, fatture, magazzino e contabilit� base) e 
posso dirti che nemmeno con le operazioni pi� impegnative tipo 
contabilizzazione, ricostruzione saldi magazzino e varie stampe di registri 
avevo dei tempi cos� lunghi.
Ti consiglio vivamente di ripensare l'applicazione e se fosse possibile di 
passare all'ambiente .NET
Ciao, Vincenzo

 Stai sicuramente, e mi gioco i tuoi testicoli
LOL
Bye, G. 

 ricostruzione saldi magazzino
Anche a me questa impiega un epopea.
Poi me la sono tradotta in SQL per prova e in 8 secondi avevo praticamente
tutto. Ponendo di metterla in funzione diciamo 3 minuti contro la i 40
minuti della procedurale, su un discreto numero di movimenti.

 impiegherebbe circa 20 minuti, contri i   0.3 sec secondi di dao ).
lol
in venti minuti la salvi tu bit per bit, scolpendo i record sulla pietra
d.

 in venti minuti la salvi tu bit per bit, scolpendo i record sulla pietra
Preistorico! ;D
-- 
Ciao Fede
By Chicco Production
http://bcp.freetools.it

 in venti minuti la salvi tu bit per bit, scolpendo i record sulla pietra
A meno che non sia arenaria piuttosto tenera, col cavolo.
Su una normale pietra ti ci vuole almeno un'oretta, se sei pratico
e hai lo scalpello affilato.
Se ti chiami Michelangelo magari se ne pu� discutere :-).
Bye, G. 

a nessun sapientone � passato per la testa:
"Com'� possibile che un programma cambiando driver diventi lentissimo al 
punto da diventare inutilizzabile ?"
Microsoft ha risposto , dato che � lei la causa , dichiarando che la 
combinazione ADO + ACCCES  � decisamente da evitare !
eppure sono tutti prodotti microsoft ,  attualmente distribuiti , insomma se 
vuoi usare ADO devi usare sqlserver.
Mi starebbe anche bene , ma per alcune realta il db access , perbacco , � 
troppo comodo !
quindi , carissimi , non lasciatevi andare a commenti troppo superficiali 
... mostrate poca competenza
"Paperino" <non...@lo.dico.invalid> ha scritto nel messaggio 
news:h1u4bu$fco$1...@stargate1.inet.it...


 ... mostrate poca competenza
a me sta passando per la testa che stai farneticando
1. driver di che? mica stiamo parlando di accesso a db access (scusa il
bisticcio di parole) con ado o con dao? quali altri driver dovrebbero
intervenire, nell'uso di access, selettivamente con ado e non con dao?
2. uso (meglio: usavo, e mantengo) N programmi in cui uso access + ado, e
non ho mai avuto problemi di lentezza.
3. meglio: quando la base di dati cresce s�, problemi di lentezza arrivano.
ma certo non 20 minuti per salvare una fattura, a meno che il salvataggio
della fattura non includa N operazioni dispendiose in termini di tempo (che
per� non dipendono n� da ADO n� da DAO n� da LINQ n� da ODBC etc. etc.).
4. meglio ancora: se dovessi avere un'operazione che in ADO impiega 20
minuti, di sicuro in DAO non impiegherebbe 0,3 secondi. vabbene pi� veloce,
ma un rapporto di 4.000 : 1 si ha, appunto, con martello e scalpello
(ebbene s�, sono michelangelo!)
5. se vuoi usare ado devi usare mssql: ma quando mai?
senti, vuoi che ti dica quanta competenza stai mostrando tu, o posso
lasciar perdere?
d.

 > Bye, G.
LOL
torno dal mare abbastanza incazzato....anzi parecchio!
Meno male che ci sono post come questi!
Almeno faccio una risata e mi rilasso!
A mia nonna Access l'ha piantata da ragazza!....dice che "usciva a
stampare una fattura"....ancora aspetta!
eh eh eh!


perch� non citi le fonti di queste informazioni cos� verifichiamo?
Ciao, Vincenzo 

 Eh?
Considerando le follie che fa DAO quando non usa il Pass-Through per le 
connessioni ODBC
20 minuti son pure pochi.
Il problema reale ï¿œ:
Perchï¿œ nel 2009 ancora ci sono applicazioni VB6 che usano DAO considerando 
il fatto che NON
ci sarebbero dovute esser applicazioni VB6 DAO ma solo VB6 ADO?
La risposta sta nella societï¿œ che ï¿œ malata. :-)