纠结, 关于事务回滚~~广告真多啊

我在按钮的执行后脚本里写了一个表单明细表的数据库保存动作，但是在保存过程中细表报了错，主表确保存成功，但是系统还是让流程发送出去了 ，下面是我给客户的一段话：
本来作为我们开发来讲的这是一个错误的处理方式 主表保存了 但是在保存细表的过程中报错了 其实这是一个整体 但是系统没有回滚整个动作 这就造成了缺失 在保存按钮或发送按钮的这个动作执行过程中会出现很多的问题 我只能说我只能尽可能的查出我可能知道我预料到的问题以防止其产生 但是人脑必竟不是电脑吧 其实在以前的开发中这种错误控制是交给电脑控制的 但是现在局限于平台 我只能手动找错误 效率其实是很低的

做java开发的 什么SSH，平台也是用SSH，也有事务 你们只管自己的事务不管我的事务，出了问题就是我的责任，你们多写一笔就能少了我们多少麻烦，就不愿意多写一笔，老板出钱买产品，苦的还是像我这样的做开发的，老板要的是结果他不管过程，我还得想想怎么把这半成品绕不知道多少个圈圈才能绕出来，做开发这么些年，最憋屈

的是这几个月

您好，不好意思。昨天公司服务器出问题了。论坛上不了。您在按钮的执行后脚本里写了一个表单明细表的数据库保存代码里肯定不会执行主表的回滚事务啊。如果在动作执行前写就可以回滚。因为平台的按钮动作执行后脚本是供用户去处理自己的一些业务逻辑肯定不能在程序中写死事务回滚啊。要根据具体业务分析啊。

问题是，如果我的这个doc是新创建的呢，我写在动作执行前的话主表都不存在怎么能去保存细表的数据，这本身就不符合数据完整性的原则

额。。。。点击保存主表的事务已经提交怎么回滚。只能在动作执行前拦截。保存操作不只是单对于主子表这种情况。我们提供的动作执行后脚本是方便用户根据自己实际业务写逻辑。如果写死回滚是不合理的。不同系统的业务不同。

那么能否在var doc = getCurrentDocument();的这个doc里加个属性，比如叫isRollback=false,默认设置为false,这样我可以在动作执行前脚本里设置这个值为true,那么你们在执行保存动作时判断这个isRollback为false还是true,决定是否回滚事务，这样来讲的话是不是会方便很多并且不会影响操作。

你这个属于比较个性化的需要。您可以自己添加。因为站在平台的角度按钮动作执行后脚本是供用户自己去处理业务程序不需要控制。