准备批量增加记录至某一个表,但该表的增加必须得事务处理多个相关表,因为涉及到增加数据的合法性,故在新增时就有一个判断,而这些判断须全做在SQL服务器上的存储过程里。现在问题来了:
1.我前台中的数据要如何让后台SQL服务器访问?
2.后台SQL用存储过程处理这些数据时,如何在检出不合法数据的时候,返回相应的变量给调用该存储过程的主程序,以便前台获得处理时的具体不合法资讯?
9 个解决方案
#1
如果用数据库校验合法性,当不合法时会出错前台返回更新不成功,当不成功时,回滚事务。
用前台校验合法性,当不合法时回滚事。
用前台校验合法性,当不合法时回滚事。
#3
谢谢版主!
可是我需要用SQL的存储过程来做数据判断!第一,这个在前台的数据,SQL服务器要如何访问,一定要先开始事务处理,用视图先提交,后台调用存储过程,进行数据判断,再条件结束事务处理?
第二,如何得知具体不合法数据的原因,而不是合法就提交结束事务,不合法就回滚事务!比如,我设定了一个字段的上限制值,在用服务器端存储过程中查出已超上限规定,用什么方法可以让前台的用户知道具体的不合法原因?当表无规则约束,需靠程序控制!
#4
可以在客户端检验合法后再提交。
或
不管3721都事务,提交,提交失败就回滚。
或
不管3721都事务,提交,提交失败就回滚。
#5
版主,如果在客户端进行合法性检验的话,明显比在服务器上运行慢很多。我有一个20万笔,库容量30M的数据表,如果在客户端进行SUM()等求和运算比在服务器上进行至少慢上1倍以上,甚至有时像是卡死状态!不知你是否有遇到这种现象!所以才想到在服务器端用存储过程来加速。不知有否更好的建议?
#6
如果多个客户并发呢,还会快吗?
你需要考虑频繁对大数据量SUM()是否合理,可能你的思路有问题。
你需要考虑频繁对大数据量SUM()是否合理,可能你的思路有问题。
#7
SQL服务器不是可以同时处理与处理器一样核数的同一存储过程,直到存取资料时才序列化吗?还是我理解错误?
按版主的意思,是不是说就算是VPN远程连接,在客户端进行运算和判断相比数据并发由服务器上的存储处理还要来得快?当然VPN的网速质量另当别论。
#8
要看你运算和判断什么数据了,包括是什么量级的。
也就是说要看你的实际需求。
也就是说要看你的实际需求。
#9
其实运算和判断也简单,就是在新增时要判断新增的数量和已存的数量之和是否超过规定的数量,编辑的时候除了做一次新增的运算和判断外,还要处理编辑前的原数据!数据是分散的且是逐日以1千笔的速度递增,现在有15万笔,用repl for更新一个已打开索引的记录都在10秒以上,所以用循环批处理多笔记录非常慢!用Select where也慢!不知道如果上150万笔该如何处理!
#1
如果用数据库校验合法性,当不合法时会出错前台返回更新不成功,当不成功时,回滚事务。
用前台校验合法性,当不合法时回滚事。
用前台校验合法性,当不合法时回滚事。
#2
请参考:<VFP 客户/服务器应用程序中的事务处理>
http://blog.csdn.net/apple_8180/article/details/1229946
http://blog.csdn.net/apple_8180/article/details/1229946
#3
谢谢版主!
可是我需要用SQL的存储过程来做数据判断!第一,这个在前台的数据,SQL服务器要如何访问,一定要先开始事务处理,用视图先提交,后台调用存储过程,进行数据判断,再条件结束事务处理?
第二,如何得知具体不合法数据的原因,而不是合法就提交结束事务,不合法就回滚事务!比如,我设定了一个字段的上限制值,在用服务器端存储过程中查出已超上限规定,用什么方法可以让前台的用户知道具体的不合法原因?当表无规则约束,需靠程序控制!
#4
可以在客户端检验合法后再提交。
或
不管3721都事务,提交,提交失败就回滚。
或
不管3721都事务,提交,提交失败就回滚。
#5
版主,如果在客户端进行合法性检验的话,明显比在服务器上运行慢很多。我有一个20万笔,库容量30M的数据表,如果在客户端进行SUM()等求和运算比在服务器上进行至少慢上1倍以上,甚至有时像是卡死状态!不知你是否有遇到这种现象!所以才想到在服务器端用存储过程来加速。不知有否更好的建议?
#6
如果多个客户并发呢,还会快吗?
你需要考虑频繁对大数据量SUM()是否合理,可能你的思路有问题。
你需要考虑频繁对大数据量SUM()是否合理,可能你的思路有问题。
#7
SQL服务器不是可以同时处理与处理器一样核数的同一存储过程,直到存取资料时才序列化吗?还是我理解错误?
按版主的意思,是不是说就算是VPN远程连接,在客户端进行运算和判断相比数据并发由服务器上的存储处理还要来得快?当然VPN的网速质量另当别论。
#8
要看你运算和判断什么数据了,包括是什么量级的。
也就是说要看你的实际需求。
也就是说要看你的实际需求。
#9
其实运算和判断也简单,就是在新增时要判断新增的数量和已存的数量之和是否超过规定的数量,编辑的时候除了做一次新增的运算和判断外,还要处理编辑前的原数据!数据是分散的且是逐日以1千笔的速度递增,现在有15万笔,用repl for更新一个已打开索引的记录都在10秒以上,所以用循环批处理多笔记录非常慢!用Select where也慢!不知道如果上150万笔该如何处理!