最近客户找我做一个更新SqlServer的算法，我在需求还算明确的情况下把代码写完，发了过去。
结果客户很快就打电话给我，说他们不是用 System.Data.SqlClient 的。要求我把代码改成OleDb的。
为了使程序能让OleDb和SqlClient都能用，我把程序的接口改为 IDbXXX .
可是问题出现了,OleDb竟然不把参数送到SqlServer那边去！
例如这样的代码，
其中 MyBussinessLogic 是我的实现。通过IDbXXX的方法，把CommandText,参数等信息放进去后，就执行Command 。 如果外面传一个 SqlTransaction 进来，那么是没有问题的。
但是如果外面传 OleDbTransaction 进来，那么这个OleDb的提供者就只把CommandText传到SqlServer去，那么执行当然会出错了。
以前没有用 OleDb 时，以为 SqlClient 只是性能上更加优化而已， 直到今天才知道还有这个问题存在。。
打印 | 张贴于 2004-09-03 03:20:00 | Tag:DotNet
留言反馈
这种方式好像是针对Oracle数据库的吧？
为了支持SqlServer和Access数据库，本打算当使用SqlServer数据库时用SqlClient而Access用OleDb。但后来也是因为OleDb中必须使用?表示参数而妥协全部使用OleDb。
我当时还考虑过自己实现 IDBXXX 接口。把SqlXXX和OleDbXXX封装在实现类中，为每个SQL语句写两个Command，但工作量太大了，最后放弃
谢谢Saucer。不过我这里无法用 '?' 了。主要是因为我不想去算参数的个数和顺序以适应具体的CommandText。
Initial Category我也没有发现。呵呵。
不过代码我是测试过的，还没有等到说找不到Orders，就抛出“必须定义@empid"的错误了。
至于命名BusinessLogic是因为，我做的东西算法比例几乎占全部。例子只是分析OleDb那边的问题。
使用IDbXXX的目的不是要跨数据库服务器，而是要同时支持OleDb和SqlClient。
不用存储过程的原因是，数据库根本不是我的。数据库中有什么东西我根本无法知道，更不要说去写存储过程了。
今天我发现OleDbCommandBuilder.DeriveParameters(cmd);返回的OleDbParameter的Name是不带"@"的。看来有新的解决方案。
Yeah, I'd more than agree that the name issue is not relelant to this specific problem. But I think it's quite a critical issue to a real programmer. Right?
It would be better to name that class as simple as Foo or Bar, but not MyBusinessLogic. It indeed reflects a further problem which could drive others mad when reading and understanding your code.
Believe me or not, naming helps thinking in software design. As soon as you realize it as a DAC, you know what to do next, in order to solve problem right, e.g., the portability issue.
Sorry for my off-topic comments here, if it's far too irrelevant. ;)
{
using System;
using System.Data;
using System.Data.Common;
using System.Data.OleDb;
class Class1
{
[STAThread]
static void Main(string[] args)
{
string connstr="Provider=SQLOLEDB;Data Source=(local);Initial Category=Northwind;Integrated Security=SSPI;";
using(OleDbConnection conn=new OleDbConnection(connstr))
{
conn.Open();
using(OleDbTransaction trans=conn.BeginTransaction())
{
using(IDataReader reader=MyBussinessLogic(trans,1))
{
while(reader.Read())
{
Console.WriteLine(reader.GetValue(0));
}
}
}
}
}
static public IDataReader MyBussinessLogic(IDbTransaction trans,int empid)
{
if(trans==null)throw(new ArgumentNullException("trans"));
IDbCommand cmd=trans.Connection.CreateCommand();
cmd.Transaction=trans;
cmd.CommandText="select ShipName from Orders where EmployeeID=@empid";
IDbDataParameter pEmplolyeeId=cmd.CreateParameter();
pEmplolyeeId.ParameterName="@empid";
pEmplolyeeId.DbType=DbType.Int32;
pEmplolyeeId.Value=empid;
cmd.Parameters.Add(pEmplolyeeId);
return cmd.ExecuteReader();
}
}
}
By the way, it should be "Initial Catalog"
All you have to do is to define a data access interface upon which your actual business logic components use to access all underlying data, and implement specific data access component against this data access interface to provide all the detail to actually access the data store. After this, you simply use a helper data access component FACTORY to instantiate proper data access component to use for the business logic components.
Have fun! :)
funny, in OleDb, somehow on my machine, "Initial Category" doesn't work
string connstr="Provider=SQLOLEDB;Data Source=(local);database=Northwind;Integrated Security=SSPI;";
.....
static public IDataReader MyBussinessLogic(IDbTransaction trans,int empid)
{
if(trans==null)throw(new ArgumentNullException("trans"));
IDbCommand cmd=trans.Connection.CreateCommand();
cmd.Transaction=trans;
cmd.CommandText="select ShipName from Orders where EmployeeID=?";
IDbDataParameter pEmplolyeeId=cmd.CreateParameter();
pEmplolyeeId.ParameterName="@empid";
pEmplolyeeId.DbType=DbType.Int32;
pEmplolyeeId.Value=empid;
cmd.Parameters.Add(pEmplolyeeId);
return cmd.ExecuteReader();
}
of coures, there goes your portability.....