Newsgroup: it.comp.lang.visual-basic
Titolo: ADO vs DAO con i DBF

Ho un file DBF di 22 MB.
Per fare alcuni test ho predisposto un form con 2 pulsanti, uno inizializza
l'ambiente e apre il file usando ADO e l'altro usando DAO. I due modi non si
sovrappongono, nel senso che ognuno lavora come istanza a se e in modo
asincrono (provo o l'uno o l'altro).
i recordset che imposto è la tabella semplice semplice, senza select o SQL
particolari.
il risultato è che aprendolo con ADO ci pensa circa 1 minuto, con DAO lo
apre immediatamente.
E' possibile che le prestazioni siano inferiori con ADO?
ps* ho provato con aperture in sola lettura, senza locks, ma il risultato è
lo stesso.
ps2* (avrei postato il codice, sono 3 righe per pulsante,  ma non ce l'ho a
portata di mano)
Grazie,
--
Fabio Guerrazzi
http://www.sourcecode4free.com/cgt
fab...@libero.it

 E' possibile che le prestazioni siano inferiori con ADO?
Non c'è alcun dubbio. ADO è molto più lento di DAO.
Se vuoi migliorare le prestazioni (rinunciando però a un tot di cose) apri
con cursore asUseServer e adLockOptimistic.
Prova con modalità adOpenStatic e (per avere la massima velocità) con
modalità adOpenDynamic.

 E' possibile che le prestazioni siano inferiori con ADO?
lupo ha fatto un vbp di confronto. fattelo mandare...
nei miei primi tentativi ado, mi ha gia' depresso che opendatabase dao e'
istantaneo, ado sta li' 4-5 secondi.
poi ci ripenso: ado e' un esperanto, il suo obiettivo non e' la velocita'...
--
ciao, j.
www.sundaysw.com

 ha scritto
E' sul Sito Comune, cercare VBDAOADO

> Non c'č alcun dubbio. ADO č molto piů lento di DAO.
thanks, magra consolazione. Domattina scaricherň il tuo progetto dal sito
comune per valutare bene le prestazioni a confronto.
Perň ammesso che con i DBF ADO fa pena mi sbaglio io o con gli MDB č invece
molto piů veloce di DAO?
immagino che la risposta sia nel tuo progetto, ma non ho resistito, sono
troooppo curioso:)
Ciao
Fabio

 troooppo curioso:)
Anch'io sono piuttosto curioso, ti capisco. Fammi un favore (saresti il
primo, dalla pubblicazione in poi, sic!), mandami i risultati, ti basta un
click...

 poi ci ripenso: ado e' un esperanto, il suo obiettivo non e' la
velocita'...
Scusa, Java, ma a te la cosa ... consola?

 E' possibile che le prestazioni siano inferiori con ADO?
sì. ADO, OLEDB, ODBC hanno senso solo quando devi mischiare più basi di 
dati diverse, o cambiare la base di dati da un momento all'altro senza 
che il tuo programma ne risenta. Se usi un solo formato alla volta, e 
il tuo programma nascerà e morirà con quella, usa sempre l'interfaccia 
nativa di quel formato
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 molto piů veloce di DAO?
non ci scommetterei neanche una crocchetta di java.
imho, in locale, e forse anche in lan, con mdb, dao/index e' ca 5-10x piu'
veloce.
e' che e' diversa la concezione.
--
ciao, j.
www.sundaysw.com

 Scusa, Java, ma a te la cosa ... consola?
se stessi progettando un db abbastanza complesso, che dovra' crescere, ma
che al momento, sia per competenze sia per possibilita' reali di
implementarlo, dovra' partire in access, ma finira' probabilmente su
sqlserver o un omologo...
a portare la lan da 10 a 100 mbit ci metto un pomeriggio. a riscrivere il
codice un anno...
...e poi lo vorranno sull'internet... gia' me lo sento...
...si', consola.
intanto dove posso continuo con rs.index="xyz", ovvio.
dove posso.
--
ciao, j.
www.sundaysw.com

 nativa di quel formato
e per un mdb sull'internet sarebbe ?

javalab ha scritto:

Non lo so, cosa intendi?



:)))))))))
(a buon intenditor...)
ciao
ugo

perchè, perchè un dbf? c'è qualche
ragione particolare?
si, decisamente. Ho una base dati in DBF fatta in
clipper nel 87 (e ancora funzionante alla grande)
Gli archivi in totale
occupano intorno ai 2GB. In clipper gli accessi sono straveloci, ma
accedervi da applicazioni windows non è così semplice. Purtroppo il formato
DBF è e resterà così per lungo tempo. 
 
Fabio
--------------------------------
Inviato via 
http://usenet.iol.it
 

 E' possibile che le prestazioni siano inferiori con ADO?
CUT
Definire "inferiori"
....Access+DAO è il top (configuazione monoutente è super-top....)
Quindi una Applicazione per un limitato numero di postazioni SENZA accessi a
Internet o possibili trasformazioni "internettiane" OK
MA DAO è noto proprio per referenziarsi con JET (sono come le auto col
motore rotativo...come si chiama..Wankel?...ottimi prodotti ma "mondi
chiusi")
ADO nasce proprio per ovviare questi limiti....
in teoria...ma con un po di occhio, anche nella pratica....puoi scrivere la
tua applicazione e poi trasportarla da un motore db ad un altro
semplicemente cambiando la stringa di connessione al DB...scusa se è poco!
Plus...la gestione anche di access tramite ASP la fai con ADO...
ADO nelle ultime versioni si apre all'XML...
ADO (per ora) è supportato e continuamente implementato con nuove
feature...DAO no!
Io apprezzo molto quello che ha fatto Lupo...però per me non ha molto senso
(scusami Lupo posso dirtelo...con amicizia?).
Devi confrontare prodotti omogenei per target e collocazione.
Posso dirti che in una applicazione la velocità talvolta è solo uno dei
parametri e spesso NON il più importante.
Molto più importante talvolta è la facilità di interconnettere basi dati
diverse, la capacità di analizzare dati e presentarli in formati digeribili
da altre applicazioni etc etc...
Se poi è anche veloce tanto meglio.
ADO non è paragonabile a DAO....sviluppaci pure con DAO la Gestione
Condominiale...o il gestionale multi azienda...o il programma di magazzino.
Se rimani in mono utenza (ma multi azienda si) oppure in una piccola rete
senza tante sofisticazioni ...bingo!
Se cominciano però a volere cose "moderne"...gestioni client/server...multi
utenze...multi database....esportazioni di dati verso as400, report
direttamente sul sito web etc etc..allora (per ora)..devi usare il "lento"
ADO
Una piccola considerazione finale:
Noi programmatori (almeno a me capita) spesso abbiamo a che fare con pc dei
clienti male ...anzi malissimo..configurati!
Tanto che tutti noi dobbiamo anche spesso improvvisarci sistemisti per
configurare ambienti e pacchetti vari.
Spesso la velocità potrebbe essere aumentabile con una buona ottimizzazione
del tutto.
Un esempio mi capitò circa 2 mesi fa dove un programma installato sotto
win2kserv andava lento....
cliente incazzato..."programmatore idiota", "Che schifo di programma..." etc
etc...io che son molto permaloso non capivo la differenza di velocità con un
ambiente simile su cui l'avevo precedentemente installato....spinta dalla
rabbia presi un mio amico  (certificato M$) e li chiesi di venire a dare un
occhiata a  sto win2kserv.
Beh!...sapeva dove mettere le mani e l'applicazione (ma anche tutto
l'ambiente in generale)..cominciò a respirare!
Concusione: l'idiota è il cliente che per risparmiare 2 lire si fa
configurare ambienti "anche pesi" dal ragazzino della cdc o della casa dello
sconto, se non dal figlio del lattaio
 "che ci capisce però! Sta tutte le sere su Internet fino a tardi....vedessi
che occhiaie!!!"
:-)
P.S.
Fabio prova a vedere su internet se ci sono provider OLEDB di terzi +
performanti (non sei mica passato dal provider ODBC vero?...quello è lento
per forza !)

 Non lo so, cosa intendi?
che il linguaggio nativo di access e' jet/dao, indicizzato, ma che fare un
seek sulla rete sarebbe abbastanza suicida. il db _e'_ anche il suo
environment.
be', pero' non ho mai provato com
    a="pippo"
    with rs
        .google "+-", a
    end with
magari funzia :)
ciao, a.

 win2kserv andava lento....
esempio iperstupido:
un miniexe sotto 95 andava a fionda. 98: piantato.
semplicemente c'era un
    for j = 0 to list1.listcount-1
e quello giustamente si scorreva tutto file1.
peccato che il 98 ha introdotto lo scroll morbido dei listbox...
io ora o blocco il refresh o uso una matrice o simili, ma queste ms sono
innovazioni del xpazzo...
--
ciao, j.
www.sundaysw.com

 innovazioni del xpazzo...
xpazzo... onomatopeico?   ;-P
ciao
ugo


il tuo progetto č interessante.
Il problema č che ho solo un vagone di DBF e alcuni mdb in Access 2000 ed
entrambi i formati non sono supportati. non c'arrivo all'invio dei risultati
:)
Comunque con ADO ho visto che le attese sono 'spaventose' per com'ero
abituato a vedere con DAO. Sarŕ che ci prendo poco con i gestionali.. ma
allora a che serve ADO?  ho capito che si possono fare incroci di dati
impensabili con DAO, ma per un gestionale di discrete dimensioni non č
meglio pensare a SQL Server o altro (visto le prestazioni)?
Grazie comunque
Fabio


Fino a VB5 tutti usavano DAO. + o - gli ODBC venivano usati solo per
connettersi a fonti dati su sistemi operativi diversi.
Con VB6  tutti sono passati ad ADO, anche per applicazioni di 1 mdb con una
singola tabella, monoutente e monocellulare :)
Le mie vecchie applicazioni in VB6, portate dal 5  che usavano DAO non si
possono compilare con Wise-Installer, che non riconosce + il DAO come Engine
di database, cioè, lo riconosce ma fa casino.
A malincuore mi era sembrato di capire che ADO dovesse sostituire DAO... ora
mi sembra  che dite che ADO ha un suo senso di esistere ancora.. e forse,
per i negozietti, videoteche e piccoli magazzini (buona fetta del mercato di
applicazioni in VB) è anche l'ideale.
morale..sono un pò confuso..
Fabio

 ha scritto

se ti puo' consolare, ado sta per essere sostituito da ado.net...
non scherzo...
dao continua ad avere senso, supportato o no da ms, in applicazioni in
locale o su lan non molto pesanti, e l'uso degli indici consente prestazioni
elevate. anche clipper non so quanto sia supportato da ca, ma io ne vedo
girare ancora un bel po', e parecchi hanno l'aria di essere stati compilati
da poco. un clipper solido non ti fara' vedere (saggio!) i gif animati, ma
gira finche' c'e' un dos vero o presunto. qualcosa di simile mi aspetto da
dao.
ado ha senso se pensi che il tuo programma crescera', o se deve potersi
connettere _indifferentemente_ (non tanto: contemporaneamente) a db diversi.
non so se i tuoi clienti sono contenti di farti riscrivere il codice da
capo. a me, dopo che cinque anni fa avevo detto: "un conto su un pc, un
conto sulla rete", e loro avevano risposto "su un pc, su un pc!": un mese fa
mi hanno detto: "mettiamo il db su internet, dai !" -- mi sono limitato a un
"parliamone". ma pensavo altre cose. qual piuma al vento.
pero' se un db da 1-5 utente so gia' che ne avra' 30-40-100, e dovra'
probabilmente passare da access a sql server, un po' ci penso... e sara'
meglio che ci pensi io, perche' il cliente/utente non sa neanche come si
chiama lui, figurati se sa quel che vuole. la palla e' che non puoi neanche
fargli pagare questa coscienza supplementare :)
intanto vediamo dove si indirizza ms -- e se ci arriva. ne ha gia' messi un
po' in cantiere, che sono stati sostituiti ancora in culla...
ciao, j.

 meglio pensare a SQL Server o altro (visto le prestazioni)?
OK, quel progettino di verifica velocità è nato appunto perchè devo
interfacciare il mio gestionale in DAO + Access a SQL Server. Già fatto con
DAO + SQL Server (tabelle Access collegate a SQL Server) con tempi piuttosto
criticabili. Cosa pensi che debba usare? Giusto, proprio ADO per andare a
gestire SQL Server. All'inizio mi sono cascate le braccia. Poi, modificando
un tot di cose e rinunciando ad alcune utility, con l'apertura adUseServer,
adlockOptimistic e adOpenDynamic sono riuscito a ottenere prestazioni
accettabili con ADO + SQL Server. E' ADO che è lento (io dico chiaro, non è
la prima volta, che mi sembra una ciofeca), non SQL Server.

 gestire SQL Server.
scusa ma con DAO non si legge SQL Server via ODBC, DSN o queslla roba li? è
questo il caso che ha fatto pensare alla creazione di ADO? perché con DAO
l'accesso a SS aveva tempi criticabili?
Insomma, tanto per capire.. a cosa si deve ADO? Qual'è stata la causa che
gli ha fatto dire: 'e no, qui ci vuole un'altro motore.. va rifatto, e già
che ci siamo anagrammiamo il nome di quello che c'è, tanto per accrescere la
confusione."
fabio

 confusione."
Beh, ti sei già risposto. ADO non l'ho certo inventato io... M$ deve vendere
e mostrare di essere molto attiva, digrignando i denti di fronte ai
concorrenti. Poco importa se, così facendo, alcuni denti cadono... loro
sono, prima di ogni altra cosa, IMHO, dei mercanti.
ADO non è un vero e proprio motore, ma, semmai, un'interfaccia per il motore
di gestione del database di destinazione, per esempio SQL Server. DAO è una
cosa analoga, è Jet il vero motore dei files Access.

 clipper nel 87 (e ancora funzionante alla grande)
A me di DBF hanno parlato malissimo. Ricordo un consiglio del tipo 
"usatelo solo come formato di scambio, giusto perchè è supportato da un 
sacco di programmi esistenti"



Ha i suoi bravi defettucci, sia concettuali che operativi,
ma ancora mezzo mondo gira su DBF...
(lasciatelo dire da uno che ha scritto codice clipper per una
decina di anni)
ciao
ugo