Newsgroup: it.comp.lang.visual-basic
Titolo: OLEDB vs DAO : che scelgo?

Ciao a tutti,
preciso meglio una domanda posta in particolare a Sergio... sono come
sapete agli inizi della programmazione in Visual Basic e mi sento come
una spugna e non vorrei ubriacarmi subito con le cose sbagliate. 
Dato che mi piacerebbe fare il porting con Vbasic di un programma che
attualmente avevo sviluppato sotto dos (con clipper e archivi DBF) e
che funziona in rete con un server e tanti client che accedono a
database sul server (stesso prg su tutte le macchine) beh, volevo
sapere quale era la soluzione migliore considerando le seguenti cose :
- database di grandi dimensioni (*forse* anche >500Mb, a regime in
access, in dbf arrivo a 100Mb senza problemi ma aggiungerei altre cose
tipo dati ole etc. interessanti e dalle prove fatte gli mdb gonfiano
come niente)
- piccola rete, anzi, quantificando : 1 server e MAX una decina di
terminali che potenzialmente possono modificare/aggiungere/consultare
piu' tabelle e vorrei bloccare solo l'indispensabile per lasciare
possibilita' di movimento massime (tipo bloccare i singoli record
aggiunti o modificati etc.) 
- robustezza : ricostruire un archivio di 500Mb di cui 50Mb sono dati
relativi all'uso dell'ultima settimana sarebbe come uccidere chiunque
usi tale programma ! parlo quindi di robustezza all'usura, ai crash, e
a windows :)
da questo ne tiro fuori la domanda secca : meglio per fare un
gestionale generico usare JET o ODBC con un file MDB di access o
converto tutto (supposto di avere gia' l'mdb di base mezzo pieno) in
SQL e uso OLEDB (che non ho idea manco cosa sia) ? Tra l'altro mi
chiedo se i comandi (che ho gia' imparato per il DAO) sono gli stessi
per l'OLEDB o devo sudare sangue per convertire se per caso mi viene
di farlo dopo e non ora?
So che sono domande esistenziali ma non so a chi chiedere dato che i
libri e l'MSDN dovrei conoscerli a memoria o quasi prima di trarne
fuori il succo...
Vi ringrazio tutti, indistintamente, almeno perche' mi sopportate :)

 come niente)
Qui andiamo male...........(io ha database di circa 80-100 Mb)
Se usi DAO ti trovi un linguaggio abbastanza semplice e completo
(nel senso che puoi usare anche l'istruzione Seek molto spesso)
Se devi aprire database per visualizzarli in DBGrid è certamente veloce,
mentre se devi fare delle query con istruzioni SELECT anche su campi con gli
indici,
è notevolmente lento.
In più, Microsoft sconsiglia l'uso di DAO perchè un po' alla volta non sarà
più supportato.
ADO (leggi OLEDB) è molto più veloce di DAO ad estrarre i dati di un
database in base a query con proposizione WHERE, mentre è più
lento ad aprire una semplice tabella per visualizzarla su un DataGrid.
Non puoi però realizzare il blocco del singolo record come si fa
con .Edit in DAO e quindi ti devi costruire un sistema di blocco
di record personalizzato (come ho fatto io, casomai ti passo il source).
Attenzione però che non mi sembra esista un driver per VB per poter gestire
gli indici di Clipper.
Io ho acquistato da 
www.vistasoftware.com
 un driver OLEDB per
poter gestire i database in formato DBF di dBase, FoxPro e Clipper
(compresi eventuali indici) e devo dire che va abbastanza bene.
E' un po' un sistema strano, nel senso che è sì un driver OLEDB,
ma per fare cose particolari ti devi appoggiare ad una DLL che ti danno
lkoro. In questa maniera però hai a disposizione
anche comandi che non avresti con OLEDB standard
(ad esempio AppendFrom, Copy To, Zap ecc. ecc.).
La velocità è notevole.
Ma, ciliegina sulla torta, la VistaSoftware produce anche un motore SQL
client/server
basato sul loro driver OLEDB che sembra sia molto molto usato in ambiente
Delphi
anche da grosse ditte (in Italia anche da Fiat).
Stanno ultimendo in questi giorni l'aggancio VB-database server e dovrebbero
rilasciare la beta 1 del nuovo driver OLEDB a momenti.
Tieni presente che la bellezza di questo server SQL sta nel fatto che
comunque gli archivi rimangono in formato DBF mentre tutti i motori
SQL esistenti fonno degli archivi sempre in formato proprietario.
Io sto aspettando questo programma per vedere come funziona e
se la cosa ti interessa, posso condividere con te eventuali prove.
Ciao
Sergio

Delphi
i dati che userei sono gia' in mdb e in caso li convertirei in sql,
cmq l'idea di usare OLEDB mi attira tantissimo, ho visto che i comandi
stessi non sono troppo diversi e difficili in genere rispetto a quelli
DAO, unica differenza sostanziale e' il concetto client-server reale
che mi fa sorgere una domanda : ma dovro' comprare 15 milioni di Sql
Server 7 per fare funzionare la mia applicazione usando OLEDB ? o c'e'
qualche soluzione integrata in Vb6 come per il DAO ? A me interessa
alla fine dei conti avere una gestione robusta in rete con tanti
terminali (vabbe' max 8-10) di archivi che potrebbero (ma mi auguro di
NO) arrivare a mezzo giga... l'mdb mi sembra (e ho letto e sentito)
troppo fragile, lento e macchinoso per la gestione della concorrenza e
delle ricerche (sono quasi certo di usare query complesse e conoscendo
benino l'SQL le faro' direttamente in SQL, senza importare query da
Access etc.etc.). Che mi consigli allora?
A proposito... ho avuto delle info da amici che gia' lavorano con
OLEDB e mi hanno parlato benissimo di TrueDbGrid della 
apexsc.com
 e di
www.componentsource.com
 che insieme a Crystal Report fanno di Vb6 un
mostro di potenza e versatilita'... se non li conoscevi spero di
averti fatto sopresa gradita !

 averti fatto sopresa gradita !
Grazie molte per il pensiero, li conosco e li uso.
Personalmente preferisco ActiveReports per le stampe, ma anche Crystal non è
male.
Ciao
Sirjo

Server.
quanto l'hai pagato? perche' il problema che mi affligge e' che se Sql
Server 7 e' ottimo non posso permettere che ogni cliente a cui dovrei
vendere il database mi compri il Server perche' se metti che il
programma costa 1 milione si trovato decine in piu' solo per
quello.... e non mi sputano in faccia ? :D ahahah

 quello.... e non mi sputano in faccia ? :D ahahah
MSDE č il vecchio SQL Server Developer Edition. Lo trovi gratuitamente
distribuito con VB6 e Office 2000 PRO e Developer Edition.

 > Apollo Database Server.
 > quanto l'hai pagato?
Molto.
Ciao
Sitjo


Ma come diavolo fate a usare un database privo di gestione delle transazioni
in ambito client-server?
Benissimo per un sito web che devo solo "fornire" dati, ma in ambito
aziendale io personalemnte devo "gestire" dati.
Senza nulla togliere a MySql, non capisco come possiate lavorarci senza
problemi - e senza transazioni - ...
ciao
ugo

 ugo
Ho lavorato parecchi anni con database che non avevavo transazioni
(vedi Clipper, dBase, FoxPro, Paradox ecc.) e quando ho riscritto
i programmi in Windows non ne ho sentito la mancanza (in stand-alone).
Quando poi sono passato a client/server il passaggio è stato abbastanza
semplice
per cui non ho avuto necessità di usare transazioni.
Ciao
Sirjo

Ok, anch'io ho lavorato a lungo in ambiente xBase.
Resta però il fatto che molte problematiche risolte con semplicità dagli
ambienti transazionali non lo sono affatto in quelli privi di questo
supporto.
In ambiente xBase non esiste neppure il supporto relazionale e si può
lavorare ugualmente.
...Ma quante righe di codice e quanto debug si può evitare...
ciao
ugo
:-)


Infatti anch'io voglio passare ad un SQL Server, ma purtroppo non ne trovo
uno
abbastanza "leggero" da installare e veloce come la gestione che ho con i
DBF ?
Tu cosa mi consigli ???
Ciao
Sirjo

Devo essere sincero, Sql Sqerver.
Non ho lavorato molto con Oracle, lo confesso, e nemmeno con MySql, ma in
compenso finora SqlServer mi ha dimostrato ottime doti sia di
manutenibilità, sia prestazionali.
Lo sto utilizzando, in ambiente di sviluppo, su una macchina Win2000 con
solo 64 mb ram (non so se mi spiego...), che fa anche da file server, da fax
server e da gestore centrale del servizio antivirus e non ho mai avuto
problemi di sorta.
Presso un cliente, ho attivato con modico sforzo una replica tra 2
stabilimenti via cdn 19k con limitati sforzi e ancor più limitata
manutenzione. E proprio la limitata manutenzione credo sia uno dei suoi
pregi migliori.
Certo, ha un costo, ma considerando che per applicativi leggeri destinati a
piccole realtà è disponibile Msde gratuito, completamente (per davvero,
però) compatibile con Sql Server, mi sembra realmente una scelta molto
valida in ambito aziendale.
Per quanto riguarda lo sviluppo di siti, viceversa, credo che un prodotto
come MySql possa farsi valere, anche grazie alle sue doti di costo... :-))
Oracle resta il principe, ma resta un pacchetto estremamnete costoso e con
qualche "vizio" di concetto. Personalemente, per esempio, non sono affatto
convinto che il concetto del "Tutto database" sia il migliore. Non vedo
ragioni vincenti per preferire tenere un file all'interno di un Rdbms
piuttosto che su un database nato apposta per gestirlo così com'è il file
system (qualunque file system) e di conseguenza prefersco lasciare al file
system appunto il compito di permettere e regiolamentare l'accesso alle
risorse file/multimediali e di affidare al Dbms il suo compito: gestire i
dati.
Molto bene mi hanno parlato di Db2 e sono in attesa fremente di poter
testare un prodotto di un fornitore basato su questo Rdbms.
Poco spazio, secondo me, resta agli altri produttori, fermo restando che in
abiente informatico, le carte possono essere rimescolate in un batter
d'occhio.
Spero di non essermi dilungato troppo in questa digressione sul "Database
relazionale secondo Ugo",  e di esserti stato utile.
ciao
ugo

> ... e di esserti stato utile.
Senz'altro, grazie
Ciao
Sirjo