数据窗口（大家都关心）

[ascap]

请问怎么让当前数据窗口实时自动刷新，也就是说数据库有变更，数据窗口也会
自动显示出来，此时又不影响对数据窗口的添加，修改删除等操作。

　　分马上送

[dotnba]

关注

[bapi]

1.用timer，隔段时间重新检索数据
2.写一个事务服务器，一个用户修改了数据并提交后，将这个改变广播到所有用户，各个用户接收这条消息后即重新检索数据

另外我觉得你的想法很难处理并发问题：假设你正在修改（还没提交），这时数据窗口自动刷新，又变成了之前的数据，你不是白忙乎了吗？
不知你到底想实现什么功能,怎样可否说清楚点?

[klbt]

用timer要付出很高的时间代价。
楼主对并发的要求有些苛刻。
能否说明你要解决的问题？

[ascap]

多谢上面几位的回答。我的问题，只是相当于实时显示当前的数据窗口，没有
其它的修改或删除、添加操作。
我很欣赏bapi(扒皮)的事务服务器，但不知道怎么写，请详细指教。
　谢谢！

[tommyhuanglei]

呵呵，我也是这么解决的不过很想让其在屏幕的右下角和时间在一起，最小化！

[bapi]

一般的C/S程序，客户端只连接到数据库服务器，我说的所谓的事务服务器，实际是运行在另一台机器上一个PB程序（可以运行在数据库服务器上，也可以运行在网内上的任何一台机器上），客户机同时连接数据库服务器和事务服务器，数据库服务器是作什么用的就不用说了，事务服务器主要用来在各个用户之间传递消息，如：一个客户端程序修改了物料表，则在提交时通过这个事务服务器向其它客户端广播一条消息（消息由开发者统一定义）,其它客户程序收到这个消息后对其进解释，发现其意义是物资料被修改，如果该用户正好有打开的窗口上显示了关于物料资料的数据，则自动重新检索数据
说白了这个事务服务器就是一个多层应用，就象一个聊天室的服务器，而所有的用户就在它上传递消息

另外，说一点我们这边的经验：
这个服务器实现起来并不难，难的是消息的定义及解释，非常之麻烦，就好比开发一套新协议，所以除非是大型的应用，否则不要用这种方法，不然得不偿失，如果你一定要用，也可以定义一套简单的消息解释系统来实现这个功能，不用象我们这样将业务规则也定义到其中

[博旺软件]

好办法，用事务管理，只是很难做。

[bapi]

to devil_heart:
我们公司的产品中就融合了这种事务服务器，事实证明完全可行，说到效率问题，呵呵，根本不用担心，这个事务服务器与数据库基本无关，只进行极少数访问（如：在启动时将自己当前的运行机器等信息注册到数据库中/或需要保存当前消息等）,但是对网络流量肯定是存在影响的

to yingmu:
因公司网络的原因，我无法上传代码，请见谅，但回答一下问题是可以的

[wangyu_hn]

数据窗口的刷新问题是比较难的一个问题，你可以写一个timer，隔段时间重新检索数据库中的数据

[devil_heart]

to:bapi
不错的想法，但不知效率如何?如果客户端很多的话，对数据库的操作会不会太频繁，有实际在应用吗?

[yingmu]

to: bapi(扒皮)
有没有这方面的资料，给兄弟看一下好吗？

[dotnba]

bapi(扒皮)说得不错，以前也讨论过这个问题。
可惜我自己一直也没尝试过。
我不太清楚的就是客户端如何确定自己修改、删除以及新增哪些记录，DW在UPDATEEND里也只记录了插入、删除、更改几条。我不知道如何通知事务服务器，望指点

[Methodor]

1、timer控件-一般不使用~
2、dw有此属性，默认为0，可设置为定时自动检索~
3、实时是相对的--看性能代价了~

[888888888888]

同意楼上

[bapi]

to ldy:
如何通知事务服务器：前面不是说了吗,客户端程序与事务服务器是建立有连接的,事务服务器Listen,客户端程序Connect,就象你连到聊天室的情况

另外,要求明确知道修改了哪条记录甚至字段是很难实现的而且大部分情况下都是无意义的,就我们现在的实际情况,主要有二类数据需要明确记录主键并进行处理:
1.基础数据如物料资料/供应商资料/客户资料等,因为这些数据在其它很多地方都会被频繁引用,所以一定要能实时刷新
2.业务单据,如操作员A录入了一张订单并保存,此时就要记录这张单的类型及编号等信息,通过事务服务器向该张单据的下一个操作者(可能是A的上司)提交这样一条消息:A向你提交了一张订单XXX,需要你审批
除以上两类数据外,目前我们对其它的数据暂时是不作处理的,毕竟消息的定义及解释是一件很麻烦的事

还有,以前的版本我们是在相关基础资料表及业务单据表上建立trigger,当有数据变更时,生成对应消息并写到一个特定表中,事务服务器通过定时扫描该表来获取需处理的消息,但事实证明这种方法不可行,开发及维护的代价都太大,当连接用户过多时,服务器根本负担不了,所以如果有想以此方法来实现的朋友,请三思,除非你能准确预计到程序投入使用后的实际负载

[flythinking]

to bapi(扒皮):
很好！！

不过，对于消息在网络中传递，要自己在tcp/ip基础上封装协议（消息），挺麻烦的！