经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » MS SQL Server » 查看文章
一次补打引起的思考
来源:cnblogs  作者:欲得其上,必求上上  时间:2019/5/31 8:49:17  对本文有异议

问题背景:

       业务人员要求补打一张17年的标签,根据标签号在系统补打界面进行打印,结果提示“输入字符串的格式不正确”。

解决过程:

       1、先是在数据库标签年份表中查询该标签的具体信息,结果正常;

       2、通过调试跟踪发现在打印方法中有个字段A在转换成Double类型时报错,问题就出在这里。打印时查询出来的表中该字段的值变成了‘Y’,导致转换失败;

  3、跟踪查询语句发现是从视图中查询出字段A的信息。按道理从视图查询和从年份表查询结果应该是一样的。

       4、在数据库查看年份表字段的设计信息时发现19年表的字段A顺序和之前的年份表中字段A顺序不一致。而视图的语句是:

  1. SELECT * FROM txx2019
  2. UNION ALL
  3. SELECT * FROM txx2018
  4. ...
  5. UNION ALL
  6. SELECT * FROM txx2011

       个人推测视图中查询时会以第一个表的列的顺序作为整个结果集的列的顺序。这样就导致通过视图查询17年数据时字段A的值发生了变化。

  5、验证一下推测。创建两个表testA和testB,两个表的字段个数和类型完全一致,后两个字段顺序不一致。

  1. create table testA (
  2. A varchar(4),
  3. B varchar(4),
  4. C varchar(4),
  5. D varchar(4)
  6. );
  7. create table testB (
  8. A varchar(4),
  9. B varchar(4),
  10. D varchar(4),
  11. C varchar(4)
  12. )

    插入数据后进行查询。结果就是UNION 和UNION ALL联合查询时会以第一个表的列的顺序作为整个结果集的列的顺序

  1. select * from testA
  2. union all
  3. select * from testB
  4. --查询结果
  5. A B C D
  6. 1 2 3 4
  7. 2 2 3 4
  8. 3 2 NULL 4
  9. 4 2 4 3
  10.  
  11. select * from testB
  12. union
  13. select * from testA
  14. --查询结果
  15. A B D C
  16. 1 2 3 4
  17. 2 2 3 4
  18. 3 2 NULL 4
  19. 4 2 4 3

  6、到此问题已经很明确了。但是由于年份表太过久远而且改动的话风险太大,就用其他方法帮业务补打了标签,这个坑就留着吧。

后记:

  以后再遇到创建年份表或新增字段的时候一定要注意各字段的顺序和之前的保持一致。

 

原文链接:http://www.cnblogs.com/captaintang/p/10950828.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号