标准表达式中数据类型不匹配（Access）-参数化顺序必须⼀致!
弄了半天才发现，执⾏参数化语句时添加参数的顺序与sql语句中参数出现顺序不⼀致也会报错。 汗- -cmd.CommandText = \"insert into [Dog]([Name],[Age]) values (@Name,@Age)\";//Name在前，Age在后cmd.Parameters.Add(\"@Name\这⾥也必须 Name在前cmd.Parameters.Add(\"@Age\Age在后
补充：Access⽇期参数化时⼜遇到错误 - -，google半天找到⼀个说的⽐较清楚的
2010年8⽉6⽇
这个问题我记得刚接触asp.net时就出现这个问题。结果今天⼜碰到这个问题，花了N个⼩时才发现问题的所在（还没想出解决⽅法）。
在Access中，是⽆法使⽤存储过程的，但可以使⽤⽂本命令，如update news set where
ID字段类型为⾃动增加，这句语句放在sql⾥是不会有问题的，但在access却有⼀个明显的错误：标准表达式中数据类型不匹配，同时也不会更新该条记录。 ⽽造成的这个问题的原因就在于id的字段类型，在Access中 \"where \"， 如果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
发现数据库⽤access所花的编写代码的时间远远超出了⽤sql的代码编写时间，⽽且⽤access经常出现莫名错误，更主要就是可能有⾮法字符如果不使⽤⽂本命令就会执⾏错误，怀念sql。
上⾯引⾃⽹上的⼀位朋友，我今天遇到了同样的问题，这⾥⼗分感谢这位朋友的分享！以后使⽤Access时，还是不要使⽤命令参数OleDbParameter了，会出现⼀些莫名奇怪的错误。
2010年8⽉8⽇更新：
昨天再次碰到⼀样的问题，“标准表达式中数据类型不匹配”。在Insert语句和Delete语句都能正常使⽤的语法，到了Update语句⾥⾯怎么改都不⾏，实在是郁闷。代码如下，其中出⽣⽇期是DateTime类型，性别是bool类型： \"Update ⽹页信息表 Set 名称,出⽣⽇期,性别 Where 编号=\"+ID.ToString() command.Parameters.AddWithValue(\"@Name\ command.Parameters.AddWithValue(\"@Birth\ command.Parameters.AddWithValue(\"@Sex\ command.ExecuteNonQuery();
如果不是Access表现怪异，这段代码绝对能够正确运⾏。但是，Access执⾏这段SQL后，没有报告异常，在数据库中也没有更新数据，叫⼈那个郁闷啊。调了半天也理不出头绪，然后想到之前遇到过Update变现异常的情况，也就是这篇博客中所说的，于是就⼀个字段⼀个字段的单独测试，都能正常Update。但是，⼏个字段⼀起更新时，要么报错“标准表达式中数据类型不匹配”，要么就是不报错也没有实际更新。
估计，Update使⽤命令参数OleDbParameter参数确有问题，⽽且问题很怪。如果不使⽤命令参数，估计可以正确更新，不过当字段很多⽽且有⼀些复杂的数据类型（如BLOB）时，使⽤命令参数更⽅便甚⾄是必须使⽤。所以，Access让我很头疼，经常是⼀个问题调试⼤半天都却查不出其中原因。在真正接触Access两天后，我决定放弃使⽤Access，不让时间⽩⽩耗费在Access上。
于是，我盯上了。这个东西太⽜了，⽬前有已经拥有⼤量特性，完全⽀持ANSI SQL92、98等，⼀些超酷的特性让⼈疯狂，主要开发⼈员是⼀个俄罗斯⼈，⽬前开发队伍已经扩⼤到近100⼈，有3种模式，单机独⽴，典型C/S，超级服务器。2.0版本和3.0版本将在近期推出，看完其(2.0、3.0)你就会疯掉。有，⽬前是版。主要特性： ◆A.C.I.D；
◆MGA(任何版本的引擎都可以处理同⼀数据库记录)；
◆PSQL(存储过程)超级强⼤，ms sql相对的太次，它啥都能在服务器端实现并推送到客户端成为强⼤的报表，存储过程； ◆触发器都可以在客户端获取监控追踪； ◆⾃动只读模式；
◆创新的事务保证绝对不会出错；
◆24*7运⾏中仍然可以随时备份数据库；
◆统⼀触发器：任何操作都可以让某表唯⼀的触发器来总控； ◆⼤部分语⾔都可以写plug-in，并直接在存储过程中调⽤函数； ◆c->c++，更加少的代码但更加快的速度； ◆3种运⾏模式，甚⾄可以嵌⼊式； ◆主流语⾔都可以调⽤它； ◆动态sql执⾏； ◆事务保存点；
我选择它，⼀是因为它的功能性能还不错，⼆是因为它能很好的⽀持C#访问(有.NET Provider提供数据库访问功能，三是它能轻松的嵌⼊到应⽤程序中，不⽤安装，发布⽅便。昨晚弄了⼀个通宵有了不⼩的收获，终于能够将其嵌⼊到应⽤程序中了。FireBird真是个不错的东西，我会慢慢学习总结，熬了⼀晚，太困了，洗洗睡吧...
