标准表达式中数据类型不匹配(Access) - 参数化顺序必须一致!

弄了半天才发现,执行参数化语句时添加参数的顺序与sql语句中参数出现顺序不一致也会报错。 汗- -

cmd.CommandText = "insert into [Dog]([Name],[Age]) values (@Name,@Age)";//Name在前,Age在后
cmd.Parameters.Add("@Name", "dog name");//这里也必须 Name在前
cmd.Parameters.Add("@Age", 100);//Age在后

  

参考:http://cnzc.cnblogs.com/archive/2004/07/09/22787.html

以下摘抄自:http://blog.sina.com.cn/s/blog_48a45b950100kkum.html

 

补充:Access日期参数化时又遇到错误 - -,google半天找到一个说的比较清楚的

http://blog.csdn.net/tjvictor/article/details/4752236

http://blog.csdn.net/tjvictor/article/details/4776817

 

2010年8月6日

 

      标准表达式中数据类型不匹配(Access)

这个问题我记得刚接触asp.net时就出现这个问题。结果今天又碰到这个问题,花了N个小时才发现问题的所在(还没想出解决方法)。

在Access中,是无法使用存储过程的,但可以使用文本命令,如
update news set title=@title,types=@types,context=@context where id=@id 

 

ID字段类型为自动增加,这句语句放在sql里是不会有问题的,但在access却有一个明显的错误:标准表达式中数据类型不匹配,同时也不会更新该条记录。 而造成的这个问题的原因就在于id的字段类型,在Access中 "where id=@id", 如果id类型为数字,那么就不能存在单引号''(在sql这里''是指定一个字段的值用,如'aaa'),而上面的文本命令的最后执行结果是:

update news set title='标题',types='类型' ,context='内容' where id='1'

 

不知道这种错误算什么错误,而正确的语句应该是:

update news set title='标题',types='类型' ,context='内容' where id=1

 

偏偏 DELETE 语句又不会出现上面所说的错误,如:

delete from news where id=@id


发现数据库用access所花的编写代码的时间远远超出了用sql的代码编写时间,而且用access经常出现莫名错误,更主要就是可能有非法字符如果不使用文本命令就会执行错误,怀念sql。

 

上面引自网上的一位朋友,我今天遇到了同样的问题,这里十分感谢这位朋友的分享!

以后使用Access时,还是不要使用命令参数OleDbParameter了,会出现一些莫名奇怪的错误。

 

2010年8月8日更新:

    昨天再次碰到一样的问题,“标准表达式中数据类型不匹配”。在Insert语句和Delete语句都能正常使用的语法,到了Update语句里面怎么改都不行,实在是郁闷。代码如下,其中出生日期是DateTime类型,性别是bool类型:

    "Update 网页信息表  Set 名称=@Name,出生日期=@Birth,性别=@Sex Where 编号="+ID.ToString()

    command.Parameters.AddWithValue("@Name", p.Name);
    command.Parameters.AddWithValue("@Birth", p.Birth);
    command.Parameters.AddWithValue("@Sex", p.Sex);

    command.ExecuteNonQuery();

    如果不是Access表现怪异,这段代码绝对能够正确运行。但是,Access执行这段SQL后,没有报告异常,在数据库中也没有更新数据,叫人那个郁闷啊。调了半天也理不出头绪,然后想到之前遇到过Update变现异常的情况,也就是这篇博客中所说的,于是就一个字段一个字段的单独测试,都能正常Update。但是,几个字段一起更新时,要么报错“标准表达式中数据类型不匹配”,要么就是不报错也没有实际更新。

    估计,Update使用命令参数OleDbParameter参数确有问题,而且问题很怪。如果不使用命令参数,估计可以正确更新,不过当字段很多而且有一些复杂的数据类型(如BLOB)时,使用命令参数更方便甚至是必须使用。所以,Access让我很头疼,经常是一个问题调试大半天都却查不出其中原因。在真正接触Access两天后,我决定放弃使用Access,不让时间白白耗费在Access上。

    于是,我盯上了Firebird。这个东西太牛了,目前有1.5稳定版本已经拥有大量特性,完全支持ANSI SQL92、98等,一些超酷的特性让人疯狂,主要开发人员是一个俄罗斯人,目前开发队伍已经扩大到近100人,有3种模式,单机独立,典型C/S,超级服务器。2.0版本和3.0版本将在近期推出,看完其路线图(2.0、3.0)你就会疯掉。有.NET驱动,目前是1.7beta版。主要特性:  
     ◆A.C.I.D;  
     ◆MGA(任何版本的引擎都可以处理同一数据库记录);  
     ◆PSQL(存储过程)超级强大,ms sql相对的太次,它啥都能在服务器端实现并推送到客户端成为强大的报表,存储过程;  
     ◆触发器都可以在客户端获取监控追踪;  
     ◆自动只读模式;  
     ◆创新的事务保证绝对不会出错;  
     ◆24*7运行中仍然可以随时备份数据库;  
     ◆统一触发器:任何操作都可以让某表唯一的触发器来总控;  
     ◆大部分语言都可以写plug-in,并直接在存储过程中调用函数;  
     ◆c->c++,更加少的代码但更加快的速度;  
     ◆3种运行模式,甚至可以嵌入式;  
     ◆主流语言都可以调用它;  
     ◆动态sql执行;  
     ◆事务保存点;

    我选择它,一是因为它的功能性能还不错,二是因为它能很好的支持C#访问(有.NET Provider提供数据库访问功能,三是它能轻松的嵌入到应用程序中,不用安装,发布方便。昨晚弄了一个通宵有了不小的收获,终于能够将其嵌入到应用程序中了。FireBird真是个不错的东西,我会慢慢学习总结,熬了一晚,太困了,洗洗睡吧...

你可能感兴趣的:(Access)