有关更新的几种情况的并发?

[zhongasen]

有 dw_a dw_b ,dw_c 三个dw的表名,字段名,类型 一样
dw_a用于显示给用户看,及让用户修改
dw_a.sharedata(dw_b)
现dw_a 发生了修改,要更新到数据库中去,如果dw_a 因为有其它的原因不要能更
那么(下面两种的情况的并发性)
1,用dw_b去更新
2,把dw_a DataModified!/datanew! 行 rowcopy 到dw_c(之前没有做任何retrieve等操作) 里,再更改变相关的更新标志,再更新
请问上面两种方法的可行性及并发处理的优越性?

[jlwei888]

程序逻辑混乱！用来显示就专门显示，保存数据的就专门用来保存！
关于DW的并发操作书上写得很详细，好好看书吧！

[zhongasen]

?其它就是想知道一下
sharedata中被share的 dw 如果做update做乍么样?
而copy出来的再update的会乍么样?
因为他们的原始缓冲区不一样...

[31737951]

你rowscopy过去的保存是 insert 行状态为 newmodify
把行状态 先改为 motmodify
再把行状态改为 datamodify
就是update语句了
好象是这样 你测试下 反正不能直接从 newmodify 到 datamidify

[lovemoreh]

梦回唐朝说得对，rowscopy到dw_c后，再保存，就是新增记录了。

另一方面，sharedata到dw_b后，dw_b也是不能保存的，这是sharedata的局限。

何不让dw_c提供给用户看，将dw_c中的修改用代码同步到dw_a，然后在dw_a中更新呢？

[zhongasen]

嗯! 谢谢楼上的! 都很精彩,谢谢!

[zhongasen]

我是想如果rowcopy的话，那么dw_c同有原始缓冲区，会不会出现说，当用户Ａ先retriev 后Ｂ对数据做了修改，然后Ａ再去改时，可以修改，而没有做到并发处理？

[永生天地]

看看这篇文章，对pb的并发会有很好的帮助：

update property中各个选项的意思:
Update属性详解：

大多数情况下,您的应用程序将在网络环境下运行。有可能会有多个人同时使用一个程序。在这种情况下使用数据窗口应注意并发控制问题。
数据窗口的并发性控制可以用"rows"菜单的"Update Properties"项进行设定。
1. Allow Updates：如果选中,则整个数据窗口允许修改,否则不允许;
2. Table to Update：在多表查询时,用该项选择要设置的表名;
3. Where Clause for Update/Delete：这项设置是对数据库并发控制最重要的一项,要仔细设置。
当调用数据窗口的Update方法时,数据窗口使用SQL语句将数据结果传递到数据库系统,这项设置决定在SQL语句的where子句中使用哪些列作为整条记录的标志。
(a)Key Columns：仅仅使用关键字作为整条记录的标志。在网络环境下不推荐使用此选项。如果两个用户同时修改了同一条记录,后进行保存操作的人会把先保存的人所做的修改"抹掉"而毫无察觉。如果选择Key Columns,那么Update对应的SQL语句是：
Update A.xh, A.xm, A.csrq, A.py
Set ... //用户修改后的新值
Where A.xh = ... //用户修改前的旧值
如果被修改的不是xh列,那么后一个用户将察觉不到前一个用户所做的修改。
(b)Key and Updatable Columns:使用关键字和所有可更新列作为记录的标志。
采用(a)中的例子,Update对应的SQL语句将是:
Update A.xh, A.xm, A.csrq, A.py
Set ... //用户修改后的新值
Where A.xh = ...
And A.xm = ...
And A.csrq ...
And A.py = ... //用户修改前的旧值
在这种情况下,后一个用户的Update将不能成功执行。
(c)Key and Modified Columns：使用关键字和所有已更新列作为记录的标志。
功能和(b)很相似,不同点在于(b)的前端执行速度快,数据库端慢;而(c)则刚好相反。
4. Key Modification：该项设置决定了更新数据库的方法。
(a)Use Delete then Insert：先删除,再插入。
(b)Use Update：直接修改。
建议使用(b)选项。
5. Updatable Columns：用来选择"可更新列",这里所做的选择与3.(b)对应,没有选中的列将不会出现在Update语句中。
6. Unique Key Columns：用来选择关键字,这里所做的选择与3.(a)对应,没有选中的列将不会出现在Update语句中。
---------------------------------------------------------------
原因:执行dw_1.update()之前,表中的数据被其它人修改过的话就可能会出现这种情况

什么情况下发生这种错误是由dw的update properties 的设置决定的,
关键因素就在这里

表1: a,b,c,d 列(在updatable columns中选中全部列)
a为key列(在unigue key columns 中设置)

关键是where clause ...中的设置
(a)Key Columns：仅仅使用关键字作为整条记录的标志。 当选择这种方式时,只有a字段的值在你update()之前发生改变,才会引起这个错误

b)Key and Updatable Columns:使用关键字和所有可更新列作为记录的标志。 使用这种方式更新,最容易引起这种错误,因为只要a,b,c,d任何一个可更新的列由其它人改变了,就会引起错误.

c)Key and Modified Columns：使用关键字和所有已更新列作为记录的标志。假如: 你修改了b列,那么,在你执行update()之前,如果a,b中任何一个列由其它人改变了,就会引起这个错误. 这种情况下,如果a,b列没被其它人修改,而c,d列被修改了,则不会引起错误.
---------------------------------------------------------------
但是，有些时候，是单击版开发，数据改动全部由开发者控制，基本上不存在多用户同时使用的问题，也会发生Row changed between retrieve and update 这样的错误，原先由高人指点过一二，但是也不是很清楚，请高人再指点一下
---------------------------------------------------------------
哪怕是单机版的程序,同样有可能出现这个错误!

1.检查本程序中是否有多个事务对象,假如两表同时读取表的数据,事务a对表更新了,这时dw用事务b再去更新就会发生这个错误.

2.有时候有些朋友,在开发的时候,打开了两个PB,(特别是对database操作), 另一个程序运行

时也有可能出现这个错误

3.对于dw如果用setitemstatus() 或 update(false,false) 之类的语句,很容易会引起这种错误

4.如果程序中有语句修改了数据窗口的original缓冲区的值,同样会引起这个错误

以上是我的经验总结,其中1,3条是最容易出现的

[zhongasen]

楼上的，这个知道！　
就如那个第四点，因为copy的时候　,dw_c 的original缓冲区没有值，那样的话是不是发生这个错呢？

另外再相问一点:
Key and Modified Columns
Key and Updatable Columns
两个对比的原始值指的是数据库里的值还是original缓冲区的值？？？

[永生天地]

dw_c 的original缓冲区没有值：是insert语句

Key and Modified Columns
Key and Updatable Columns
是和original缓冲区进行比较

[zhongasen]

是和original缓冲区进行比较吗?? 那样的话根本就不知道有没有改过数据库了呀？　　
因为original缓冲区是没有人会改的　Ｂ　用户根本就改不到．．．　

[做梦的猫]

数据窗口的并发控制就是通过将原始缓冲区的值与数据库的实际值进行对比而实现的，除非故意想禁止并发控制，否则没有理由修改原始缓冲区。

dw_c 中的原始缓冲区不是没有值，而是 rowscopy() 中源数据窗口主缓冲区的值，所以要想通过 dw_c 实现 update 而非 insert，理论上应该把 dw_a 的原始缓冲区的值赋给 dw_c，同时把 dw_a 的更改标志也赋给 dw_c。这样 dw_a 和 dw_c 就成为两个完全一样的数据窗口，无论更新哪个都是一样的；但问题是这样做没有意义，因为直接更新 dw_a 好了，何必要复制出个 dw_c 来更新。

单机版单个事物时也会出现并发问题的原因是触发了另一个“事物内并发控制”：当使用 Key Modification 的 Use Update 直接更新时，主键列是不允许进行交叉修改的，例如 1 和 2 是唯一主键列的两条记录，1 改 2，同时 2 改 1，这在逻辑上是合理的，但必须使用 Use Delete then Insert 删除后更新才能成功。

pb 数据窗口的并发控制属于其内部机制，尽管我们可以通过 SetItemStatus() 来控制更新标志来达到一些特殊的目的，但由于状态标志的修改上有一些不是那么容易搞清楚的特性（例如梦回唐朝说的那个，但绝不止这个），再加上 pb 的稳定性不够好，我就碰到过获取状态标志竟然为空的情况，所以建议并发控制方面不要进行太复杂的“二次开发”。