Newsgroup: it.comp.lang.visual-basic
Titolo: ODBC - OLE DB - ADO

Allora...
volevo capire se qualcuno utilizza ODBC tramite API per interfacciare
database.
Attualmente, a prescindere dal linguaggio per lo sviluppo del client (VB,
VC++, ASP), utilizzo OLE DB ed ADO. Ho letto un po' di articoli dove si
parla di saltare il livello interposto da ADO e di comandare direttamente
ODBC tramite API. Logicamente dovrebbe essere più performante. Ho anche
letto che ODBC è più veloce di OLE DB... ed anche qui chiedevo conferma.
Inoltre... è possibile utilizzare ODBC senza dover creare obbligatoriamente
sulla macchina un DSN? La comodità di OLE DB è che attravarso la connection
string punto ad un db server o ad un altro con estrema facilità.
Grazie a tutti.

 string punto ad un db server o ad un altro con estrema facilità.
assolutamente no :)
L'OLE DB consente di connettere Applicazione con DB senza livelli di
"traduzione" intermedi, quale l'ODBC.
Con ODBC:
Applicazione -> ADO -> ODBC Layer -> Driver -> Database
Con OLE DB:
Applicazione -> Provider -> Database
ecco il motivo della maggiore velocità
un url di partenza: 
http://www.microsoft.com/data
ciao
--
Fibia "Sakamoto" FBI
E-mail: 
fibi...@hotmail.com
ICQ UIN 63586057
Sito Personale: 
http://www.geocities.com/fibiafbi
VB Simple: 
http://vbsimple.virtualave.net
Membro #26 delle Mitiche Brigate Takahashi sezione Sud

 Applicazione -> Provider -> Database
ops.. omissis :-D
Con OLE DB:
Applicazione -> ADO -> Provider -> Database
--
Fibia "Let me rape my outlook please" FBI

 Applicazione -> Provider -> Database
A parte il fatto che un livello di "traduzione" non puo' non esistere, dato
che esiste un provider, gli schemi secondo me sono:
Applicazione -> ODBC Layer -> Driver -> Database
Applicazione -> Provider -> Database
in realta' dal punto di vista di VB usare OLE DB implica usare ADO, per cui
il secondo diventa
Applicazione -> ADO -> Provider -> Database
IMHO il vero svantaggio dell'ODBC e' semplicemente che si basa su
un'interfaccia "a funzione" decisamente di vecchio stile, e non paragonabile
alla comodita' di un interfaccia ad oggetti; a lavoro comunque usiamo
tutt'ora l'API ODBC largamente, attraverso un wrapper ActiveX la cui prima
versione scrivemmo con VB4...
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett Brown

 ha scritto nel messaggio
news:3Gjq7.5187$Lp6.2...@news.infostrada.it...

Beh, il discorso si potrebbe fare lungo, tenterò di farlo breve...:
E' chiaro che chiamare Odbc senza passare da Ado (quindi da Oledb) è più
veloce.
Altrettanto chiaro che si perde il vantaggio della sintassi comune di Ado.
Ora, dal momento che la gran parte del codice Ado lavora attraverso i
provider Oledb specifici (vedi il provider per SqlServer, quello di Oracle,
quello di Jet etc...) e non attraverso il generico provider Odbc, il
vantaggio di avere uno strato ad oggetti comune e -quasi- identico tra un
database e l'altro risulta spesso più importante dello svantaggio derivante
dalla maggior lentezza nell'uso di quei sistemi database privi di provider
dati Oledb specifico (vedi db3, foxpro etc...).
ciao
ugo

 all' API ODBC rispetto all'utilizzo del provider ODBC in ADO; in
a dire il vero io parlavo proprio di ADO+ODBC, niente API
la domanda riguardava velocità tra ODBC e OLEDB.. niente api :P
il livello che si evita è, come ho detto prima io e poi tu ( :P )  quello
dell'utilizzare priva un interfaccia verso l'ODBC e poi verso il driver,
chiamando semplicemente un provider che provvederà a connettersi
al file del database.
APP -> ADO -> Provider -> DB


 al file del database.
Inoltre come ha sottolineato anche Ugo, la maggior velocita' dell'API in
genere non compensa la relativa scomodita' di utilizzo; nel mio caso,
ripeto, posso permettermi ancora di usare le API ODBC proprio in virtu' di
un wrapper ad oggetti ormai "consolidato" che ci portiamo dietro da un bel
po'.
