To use ADO and ADO extensions, the corresponding libraries must first be referenced. Here are the latest versions as of 2002 Jan:
Microsoft ActiveX Data Objects 2.7 Library .msado15.dll . (2.0 = msado20.tlb, 2.1 = msado21.tlb, 2.5 = msado25.tlb, 2.6 = msado26.tlb)ADODB .2.7 .Microsoft ActiveX Data Objects (Multi-dimensional) 2.7 Librarymsadomd.dll .ADOMD .2.7 .Dim cmdObject1 as New ADODB.Command Dim cmdObject2 as ADODB.Command
Set cmdObject = Server.CreateObject("ADODB.Command") 'VBS
var cmdObject = Server.CreateObject("ADODB.Command"); //JS
_CommandPtr rs("ADODB.Command");
ADO Named Constants hold values that are frequently used by the methods of ADO objects. This makes the code easier for developers to write and read.
EG: The first line of code has the actual parameter values but the second uses the ADO named constants:
rsMy.Open sql, cnn1, 0, 1, 1
rsMy.Open sql, cnn1, adOpenForwardOnly, adLockReadOnly, adCmdText
In VB and VBA, ADO named constants are available by the mere fact that a VB project is referencing the ADO type library.
VBScript and JavaScript do not support type libraries but they can include files which declare and initialize the constants. The files are usually located and named as follows:
'Server-side constants
C:\Program Files\Common Files\System\ado\adovbs.inc
'Client-side constants
C:\Program Files\Common Files\System\msdac\adcvbs.inc
Here is an example of how SSI directive code might include the adovbs.inc file:
<!-- #include file="..\includes\adovbs.inc" -->
If you make a connection to a SQL Server via DSN and you make a recordset using the default parameters (ieRecordset.Open(SomeSQLString, YourConnection)), then it is a forward-only cursor with read-only locking. This is fine and dandy but even in this ordinary situation, some ordinary properties of the Recordset object will act funky. EG: The RecordCount property always returns a "fake" value of-1for forward-only cursors!
Page Modified: (Hand noted: 2007-10-10 19:02:09Z) (Auto noted: 2007-11-17 06:46:17Z)