标准表达式中数据类型不匹配(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真是个不错的东西，我会慢慢学习总结，熬了一晚，太困了，洗洗睡吧...