连接sql server 2000的问题
发布网友
发布时间:2022-04-07 15:21
我来回答
共1个回答
热心网友
时间:2022-04-07 16:50
有许多种办法可以连上一个数据库. 你可以用System DSN, DSN-less连接或是本地的OLEDB provider. OLEDB? 这是什么什么玩艺儿? 也许你们中的许多人以前没有听说过. 要回答这个问题,我们先得回顾一下数据库连接的历史.
早期的数据库连接是非常困难的. 每个数据库的格式都不一样,开发者得对他们所开发的每种数据库的底层API有深刻的了解. 因此,能处理各种各样数据库的通用的API就应运而生了. 也就是现在的ODBC(Open Database Connectivity), ODBC是人们在创建通用API的早期产物. 有许多种数据库遵从了这种标准,被称为ODBC兼容的数据库.
ODBC兼容的数据库包括Access, MS-SQL Server, Oracle, Informix等.
但ODBC并不是完美无缺的,它仍然含有大量的低级的调用,开发ODBC应用程序仍较困难. 开发者不得不将大量的精力花在底层的数据库通信中,而不能专注于他们所要处理的数据. 后来微软提出了一个解决方案: DAO(Data Access Objects). DAO的代码看起来象这样:
objItem.AddNew
objItem.Name = "Chair"
objItem.Price = 10
objItem.Update
你也许看过DAO的代码. 后来DAO演变为RDO(Remote Data Objects, 为分布式数据库体系设计), 再后来是ADO. 尽管它们都有各自的不足之处. 根据微软的说法,"ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
OLEDB位于ODBC层与应用程序之间. 在你的ASP页面里,ADO是位于OLEDB之上的"应用程序". 你的ADO调用先被送到OLEDB,然后再交由ODBC处理. 你可以直接连接到OLEDB层,如果你这么做了,你将看到服务器端游标(recordset的缺省的游标,也是最常用的游标)性能的提升. 那我们该如何直接连接到OLEDB呢?
要想直接连到OLEDB层,你必须改变你的connection对象连接字符串. 先用老办法创建一个connectiong对象:
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
接下去,我们不用常规的类似DSN=pubs or DRIVER={MS SQL-
Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine的连接字符串,而采用下面的连接字符串:
objConn.ConnectionString = "Provider=ProviderName; Data
Source=DatabaseSource; Initial Catalog=DatabaseName; User ID=UserID;
Password=Password"
对于SQL:
ProviderName = SQLOLEDB
Data Source = Server Name
Initial Catalog = Database Name
对于Access:
ProviderName = Microsoft.Jet.OLEDB.3.51
Data Source = Full path to .MDB file
下面让我们来看两个例子,一个是针对Access的,还有一个是针对SQL的. 如果你的连接SQL的DSN-less连接串是这样的:
DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine
那么直接连接到OLEDB的连接字符串应该是这样的:
Provider=SQLOLEDB; Data Source=myMachine; Initial Catalog=pubs; User
ID=sa; Password=
让我们来看看Access,如果你的Access的连接字符串是:
DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=c:\inetpub\wwwroot\users.mdb
那么直接连接到OLEDB的连接字符串应该是这样的:
Provider=Microsoft.Jet.OLEDB.3.51; Data
Source=c:\inetpub\wwwroot\users.mdb
就是这么简单,挺棒的吧?
这很重要吗?
现在你也许对为什么要学习这种新的数据库连接方法感到有些儿迷惑,为什么不走标准的DSN-less/System DSN路子呢? 让我来告诉你为什么. 据Wrox出的ADO 2.0
Programmer´s Reference一书中的测试,用OLEDB连接而不是DSN或DSN-less的连接会得到的性能提升如下:
性能比较
SQL Access
OLEDB DSN OLEDB DSN
Connection Times: 18 82 Connection Times: 62 99
Iterating through 1,000 Records Times: 2900 5400 Iterating through
1,000 Records Times: 100 950
我希望这篇文章能对你有点儿帮助,我相信你会对你的连接SQL及Access数据库的方法做一些小小的改进的.
有许多种办法可以连上一个数据库. 你可以用System DSN, DSN-less连接或是本地的OLEDB provider. OLEDB? 这是什么什么玩艺儿? 也许你们中的许多人以前没有听说过. 要回答这个问题,我们先得回顾一下数据库连接的历史.
早期的数据库连接是非常困难的. 每个数据库的格式都不一样,开发者得对他们所开发的每种数据库的底层API有深刻的了解. 因此,能处理各种各样数据库的通用的API就应运而生了. 也就是现在的ODBC(Open Database Connectivity), ODBC是人们在创建通用API的早期产物. 有许多种数据库遵从了这种标准,被称为ODBC兼容的数据库.
ODBC兼容的数据库包括Access, MS-SQL Server, Oracle, Informix等.
但ODBC并不是完美无缺的,它仍然含有大量的低级的调用,开发ODBC应用程序仍较困难. 开发者不得不将大量的精力花在底层的数据库通信中,而不能专注于他们所要处理的数据. 后来微软提出了一个解决方案: DAO(Data Access Objects). DAO的代码看起来象这样:
objItem.AddNew
objItem.Name = "Chair"
objItem.Price = 10
objItem.Update
你也许看过DAO的代码. 后来DAO演变为RDO(Remote Data Objects, 为分布式数据库体系设计), 再后来是ADO. 尽管它们都有各自的不足之处. 根据微软的说法,"ODBC提供了本地SQL数据的存取,DAO提供了高级的数据对象". DAO和RDO都需要数据以SQL(Structured Query Language)的格式存储. 针对这些缺陷,微软提出了OLEDB,一个基于COM的数据存储对象,能提供对所有类型的数据的操作,甚至能在离线的情况下存取数据(比方说,你使用的是你的便携机,你可以毫不费力地看到最后一次数据同步时的数据映像).
OLEDB位于ODBC层与应用程序之间. 在你的ASP页面里,ADO是位于OLEDB之上的"应用程序". 你的ADO调用先被送到OLEDB,然后再交由ODBC处理. 你可以直接连接到OLEDB层,如果你这么做了,你将看到服务器端游标(recordset的缺省的游标,也是最常用的游标)性能的提升. 那我们该如何直接连接到OLEDB呢?
要想直接连到OLEDB层,你必须改变你的connection对象连接字符串. 先用老办法创建一个connectiong对象:
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
接下去,我们不用常规的类似DSN=pubs or DRIVER={MS SQL-
Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine的连接字符串,而采用下面的连接字符串:
objConn.ConnectionString = "Provider=ProviderName; Data
Source=DatabaseSource; Initial Catalog=DatabaseName; User ID=UserID;
Password=Password"
对于SQL:
ProviderName = SQLOLEDB
Data Source = Server Name
Initial Catalog = Database Name
对于Access:
ProviderName = Microsoft.Jet.OLEDB.3.51
Data Source = Full path to .MDB file
下面让我们来看两个例子,一个是针对Access的,还有一个是针对SQL的. 如果你的连接SQL的DSN-less连接串是这样的:
DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine
那么直接连接到OLEDB的连接字符串应该是这样的:
Provider=SQLOLEDB; Data Source=myMachine; Initial Catalog=pubs; User
ID=sa; Password=
让我们来看看Access,如果你的Access的连接字符串是:
DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=c:\inetpub\wwwroot\users.mdb
那么直接连接到OLEDB的连接字符串应该是这样的:
Provider=Microsoft.Jet.OLEDB.3.51; Data
Source=c:\inetpub\wwwroot\users.mdb
就是这么简单,挺棒的吧?
这很重要吗?
现在你也许对为什么要学习这种新的数据库连接方法感到有些儿迷惑,为什么不走标准的DSN-less/System DSN路子呢? 让我来告诉你为什么. 据Wrox出的ADO 2.0
Programmer´s Reference一书中的测试,用OLEDB连接而不是DSN或DSN-less的连接会得到的性能提升如下:
性能比较
SQL Access
OLEDB DSN OLEDB DSN
Connection Times: 18 82 Connection Times: 62 99
Iterating through 1,000 Records Times: 2900 5400 Iterating through
1,000 Records Times: 100 950
我希望这篇文章能对你有点儿帮助