Diversamente da come molti pensano, per la connessione a database in ASP non esiste solo ODBC. Certamente è il metodo più usato e forse il più semplice da implementare abbinandolo ai DSN, ma non è l'unico e neanche il più veloce.
Come avrete già capito dal titolo dell'articolo l'alternativa di cui sto parlando si chiama OLE-DB.
Come sapete l'ambiente ASP non è altro che un insieme di oggetti e componenti richiamati con un linguaggio di scripting (Vbscript, Jsscript o altri). Uno di questi componenti è ADO (Activex Data Object) che si occupa appunto della comunicazione con le sorgenti di dati (database), e OLE-DB è appunto una parte di esso.
Per capire meglio come lavora OLE-DB all'interno di ADO bisogna aprire una parentesi sui concetti di Data Consumer e Data Provider.
Data Consumer
Il Data Consumer è una qualunque applicazione che richiede dei dati per una successiva elaborazione all'interno del proprio codice.
Nel nostro caso il Data Consumer è la pagina ASP in quanto si occupa della richiesta dei dati al database per elaborarli successivamente.
Data Provider
In contrapposizione, il Data Provider, è colui che si occupa del dialogo diretto con il DB per l'estrapolazione dei dati richiesti e che successivamente li passerà al Data Consumer. Nel nostro caso il Data Provider è OLE-DB.
Esattamente come succede per l'ODBC (che è esso stesso un Data Provider) ogni database ha bisogno di un suo OLE-DB specifico che ne conosca la struttura e che sappia come prendere i dati.
In pratica sia OLE-DB che ODBC sono due Data Provider e superficialmente si potrebbe pensare ad una equivalenza tra i due ma vedremo che non è così.
Perché usare OLE-DB al posto di ODBC.
Forse qualcuno ci rimarrà male dal non vedere ancora neanche una linea di codice, ma ciò deriva dal fatto che le modifiche per utilizzare OLE-DB sono veramente esigue mentre la filosofia che si basa dietro ai due mondi è completamente diversa ed è questa che bisogna capire per apprezzare le differenze tra i due metodi.
OLE-DB è uno dei primi passi che la Microsoft ha fatto per implementare efficacemente la sua strategia chiamata UDA (Universal Data Access).
Lo scopo di UDA è di rendere accessibili, in modo uniforme, i dati provenienti non solo dai DB ma anche da qualunque applicazione come Word, Excel, Outlook. Ci troveremo quindi in un futuro molto prossimo a collegare non solo database ma qualunque applicazione OLE-DB compatibile.
Dal canto suo la Microsoft sta spingendo molto per raggiungere la massima diffusione di UDA e vedrete che in poco tempo ogni applicazione avrà il suo bel driver OLE-DB esattamente come adesso ha quello ODBC.
Se pensate che questo non sia abbastanza per abbandonare i vostri vecchi metodi di programmazione tenetevi forte perché la tabella che segue vi sbalordirà più di 1000 parole:
CONFRONTO PRESTAZIONI - ACCESS | ||
OLE-DB | ODBC (DSN) | |
Tempo di connessione | 18 | 82 |
Tempo di iterazione su 1000 Record | 2900 | 5400 |
CONFRONTO PRESTAZIONI - SQL server | ||
OLE-DB | ODBC (DSN) | |
Tempo di connessione | 62 | 99 |
Tempo di iterazione su 1000 Record | 100 | 950 |
Nota: questi risultati sono tratti dalle pagine 232 e 233 del libro: ADO 2.0 Programmer's Reference edito dalla Wrox. I tempi sono espressi in millisecondi e le iterazioni attraverso i 100 record sono calcolate usando cursori server-side. (C'è una minore differenza di prestazioni fra OLE-DB e ODBC usando i cursori Client-side)
Usare OLE-DB
Siamo arrivati finalmente alla parte forse più attesa, dove vedremo come effettuare la connessione OLE-DB rispetto a quella ODBC.
Il codice che segue funziona solo con la versione 2.0 o superiore di ADO. Se si sta usando una vecchia versione (vedi tabella) si può scaricare gratuitamente l'aggiornamento alla pagina http://www.microsoft.com/data
Prodotto | ?include?. |
IIS 3.0 | ASP 1.0 e ADO 1.0 |
IIS 4.0, PWS 4.0, NT4 Option pack | ASP 2.0 e ADO 1.5 |
Windows '98 | ASP 2.0 e ADO 1.5 |
Visual Studio 6.0 | ADO 2.0 |
Office 2000, IE 5.0 | ADO 2.1 |
Windows 2000, IIS 5.0 | ASP 3.0 e ADO 2.5 |
Guardate il seguente pezzo di codice:
<% Dim objRS Dim strConnect StrConnect = "Driver={Microsoft Access Driver (*.mdb)}; DBQ=c:\inetpub\wwwroot\?\nome_db.mdb" Set objRS = Server.CreateObject(ADODB.Recordset) objRS.Open "Nome_tabella" , <b>strConnect</b> , <tipo di cursore>,<tipo di lock> %>
Questo è quello che avete sempre fatto per aprire una connessione ODBC (in questo caso con il driver di Access).
Per connettersi con OLE-DB l'unica modifica che dovete fare è cambiare la stringa strConnect come segue.
Connettere Access
StrConnect = "Provider = Microsoft.Jet.OLEDB.4.0; Data Source = C:\inetpub\wwwroot\?\nome_db.mdb; Persist Security Info = False"
Connettere SQL server
StrConnect = "Provider = SQLOLEDB; <br /> Data Source = nome_della_macchina_server;<br /> Database = nome_del_db;<br /> User ID = user_id; Password=password"<br />
Da notare come, similarmente all'ODBC, la sintassi della stringa di connessione varia da un DB all'altro.
Essenzialmente può essere composta da:
Provider: Il tipo di provider OLE-Db usato per la connessione
Initial File Name o Data Source: Il path fisico del DataBase (compreso il nome del file)
Initial Catalog: Il nome del database
User ID: L'user name necessario per la connessione
Password: La password per il nome utente specificato
Persist Security Info: E' una variabile boolean che se messa a True dice a Windows di ricordare la password per noi.
Che corrispondono in ODBC:
ODBC | OLE-DB |
Driver | Provider |
Dbq | Initial File Name o Data Source |
Uid | User ID |
Pwd | Password |
Credo che adesso siete pronti per iniziare i vostri primi programmi utilizzando la connessione OLE-DB.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.