Newsgroup: it.comp.lang.visual-basic
Titolo: prestazioni con ADO

L'utilizzo di oggetti ADO in connessione col database Jet 3.51 mi da delle
prestazioni molto inferiori all'utilizzo dei DAO.
Utilizzando lo stesso database locale !
Succede cosě anche ad altri ??

...

Le prestazioni di ADO su database Access sono da 2 a 3 volte inferiori a
quelle di DAO.
E' comprensibile, poiche' DAO e' fato "su misura" e ottimizzato per Access,
mentra ADO e' piu' generico.
Per questo motivo con db Access uso DAO.
--
Roal Zanazzi
z...@iol.it

...


Non e' assolutamente vero. Se ti succede una cosa del genere, vuol
dire che stai sbagliando il data provider. Permettimi di passarti la
funzione che ho appena finito di scrivere e che realizza la
connessione. I data providers presi in considerazione sono quello Jet,
quello ODBC e quello SQLServer. In assoluto, il piu' lento e' quello
ODBC, sia che ci si connetta a basi dati Access, sia che ci si
connetta a basi dati SQL Server. L'ho aggiunto, piu' che altro,  per
non precludermi alcuna strada gia' in partenza....
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
''  Connetti
''  Questo metodo opera una connessione a una sorgente di dati secondo
''  i parametri passati
''  PARAMETRI
''  dptParTipo      Tipo di connessione da aprire
''  strSorgente     Nome della base dati da aprire
''  strDataServer   (opzionale; solo connessioni di tipo SQLOLEDB)
''                  nome del server SQL su cui il database risiede
''  strUserName     (opzionale)nome dell'utente da connettere
''  strPassword     (opzionale)password dell'utente da connettere;
''                  utilizzato solo se indicato anche strUserName
''  strParametri    (opzionale) parametri aggiuntivi (vd. la
''                  manualistica ADO
''
''  Ritorna l'esito dell'apertura; se l'esito e' a FALSE, il codice
''  appropriato viene posto nella variabile dpeErrore
''
Public Function Connetti(dptParTipo As EDPTipo, _
			 strSorgente As String, _
                         Optional strDataServer As String = "", _
                         Optional strUserName As String = "", _
                         Optional strPassword As String = "", _
                         Optional strParametri As String = "") As
Boolean
 
    ''  #### Setup funzione ####
    Const FunctionID = ModuleName + "Connetti"
    Err.Source = FunctionID
    On Error GoTo Err_Connetti
 
    ''  #### Costanti e variabili ####
    Dim strConnect As String
 
    ''  #### Codice ####
    Connetti = False
 
    ''  verifica dello stato attuale della connessione ADO
    If adodbConnection.State <> adStateClosed Then
        dpeErrore = DPE_CONNESSO
        GoTo Exit_Connetti
    End If
 
    '' Verifica dei parametri
    If dptParTipo = DPT_NESSUNO Or _
       dptParTipo = DPT_SQLSERVER And strDataServer = "" Then
        dpeErrore = DPE_PARAMETRI_NON_VALIDI
        GoTo Exit_Connetti
    End If
    ''  Preparazione della stringa di connessione
    Select Case dptParTipo
        Case DPT_JET
            strConnect = "Provider=Microsoft.Jet.OLEDB.3.51;" + _
                         "Data Source=" + strSorgente + ";"
        Case DPT_ODBC
            strConnect = "Provider=MSDASQL;" + _
                         "Data Source =" + strSorgente + ";"
        Case DPT_SQLSERVER
            strConnect = "Provider=SQLOLEDB;" + _
                         "Data Source =" + strDataServer + ";" + _
                         "Initial Catalog = " + strSorgente + ";"
        Case Else
            dpeErrore = DPE_NON_SUPPORTATO
            GoTo Exit_Connetti
    End Select
 
 
    ''  Aggiungo il nome utente, se indicato
    If strUserName <> "" Then
        strConnect = strConnect + "User ID=" + strUserName + ";"
 
        ''  Aggiungo la password, se indicata
        If strPassword <> "" Then
            strConnect = strConnect + "Password=" + strPassword + ";"
        End If
    End If
 
    ''  Accodo eventuali parametri opzionali, se specificati.
    If strParametri <> "" Then
        strConnect = strConnect + strParametri + ";"
    End If
 
    adodbConnection.Open strConnect
    dptTipo = dptParTipo
    strNomeDB = strSorgente
    dpeErrore = DPE_NESSUNO
    Connetti = True
 
Exit_Connetti:
    Exit Function
 
Err_Connetti:
    MsgBox "Errore #" + Str$(Err.Number) + vbCr + _
           "Descrizione: " + Err.Description + vbCr + _
           "Sorgente: " + Err.Source + vbCr + _
           "Error handler: " + FunctionID, _
           vbCritical, _
           App.Title + " (" + Trim$(Str$(App.Major)) + "." + _
           Trim$(Str$(App.Minor)) + "." + _
           Trim$(Str$(App.Revision)) + ")"
    dpeErrore = DPE_ODBC
    Resume Exit_Connetti
End Function
Ciao!
Luca Menegotto



Ehi, ehi, fermi tutti (tu ed Enrico Santoemma)!!
Come si dice: "Ambasciator non porta pena"!
Io riferivo voci che ho letto e riletto (e sembrano tutti d'accordo) sui NG
internazionali e su quelli di M$, tra l'altro confermate ufficiosamente (a
denti stretti) da Microsoft stessa.
Non avendo fatto dei test, non posso ne' confermare ne' confutare queste
voci, ma, come ho scritto, mi sembrano realistiche, data le particolarita'
di DAO rispetto ad ADO.
E' chiaro (come dice Santoemma) che una applicazione che utilizza DAO
(quindi Access, in genere) non e' progettata con le ottimizzazioni e tutte
le accortezze che servono ad una app con DBMS client/server, e questo
potrebbe essere un'ulteriore svantaggio per ADO (nel caso in cui fosse
utilizzato in sostituzione di DAO.
Aggiungo anche (per Luca) che non so che tipo di data-provider sia stata
utilizzata per le prove, ma immagino che per Access abbiano utilizzato
l'OLEDB di Access (quanti altri data-provider ADO esistono per Access, oltre
ad ALEDB Access e ODBC?)
Per finire (sempre per Luca) ODBC e' SEMPRE il piu' lento, con qualsiasi
tecnologia di accesso ai dati. E' logico, perche' ODBC e' un ulteriore layer
da attraversare e cio' rallenta... E' anche per questo, credo, che Microsoft
s'e' inventata gli OLEDB providers.
--
Roal Zanazzi
z...@iol.it

>>use ADO for  just about everything except access/jet databases.
Ci sono riferimenti precisi (libro e rivista), per cui non vedo perche'
dovrei dubitarne.
--
Roal Zanazzi
z...@iol.it

s'e' inventata gli OLEDB providers.
Vero. Se l'e' anche inventata per garantire l'accessibilita' a basi
dati di tipo non relazionale.
Comunque, nel bene o nel male, mettiamocela via, ADO e' la tecnologia
ce Microsoft intende sviluppare nel futuro prossimo, abbandonando
tutto il resto, DAO compreso......
Ciao!
Luca Menegotto.

tutto il resto, DAO compreso......
Verissimo...
Anche VB6 crea exe piu' lenti di VB5... e' sempre stato cosi'...
hard disk piu' grandi? -> chi se ne frega di ottimizzare per dimensione...
processori sempre piu' veloci? -> ma si', mettiamo spazzatura nel codice,
tanto va veloce lo stesso...
E cosi' nacque e si sviluppo' Windows!
Pardon, piccolo sfogo personale...
--
Roal Zanazzi
z...@iol.it

Con la frase 'preparati a soffrire' mi riferivo solo al differente
protocollo di utilizzo di DAO, che personalmente mi interessa piu' delle
prestazioni.
Ho effettivamente convertito 6 applicazioni che usavano DAO. Per tre di
queste ho fatto prima a riscrivere tutto da capo, e ora funzionano bene. Per
le altre tre non avevo voglia e ho usato la vecchia tecnica del Find &
Replace, e ora gocciolano come tubi arrugginiti :)
Come mai non avete accennato a questo grosso problema di conversione, che
prima o poi l'applicazione potra' dover subire?
Enrico

Per due buoni motivi:
1 - io non ho mai usato la tecnica del Find e Replace perche', sempre
secondo documentazione, non garantisce la portabilita' massima (sara'
perche' vengo dal C++ che mi sono preoccupato di una cosa del
genere??)
2 - la mia esperienza mi insegna che, al di la di quanto viene detto
comunemente, il passaggio di tecnologia impone SEMPRE una revisione
critica del codice. Io per principio NON MI FIDO di quelli che mi
dicono "vai tranquillo, funziona"... prima provo, poi, una volta
eseguite le prove, traggo le mie conclusioni.
Ciao!
Luca Menegotto.
