RDO 之Addnew/Update/Delete

先前讨论了OpenresultSet的种种特性，现在来看看使用Addnew/Update/Delete时，会有
什麽特性。以下都是在Read Committed的情况之下做的

一、SQL Server 6.5 / Informix Dynamic Server 之 rdUseOdbc
    先前说过，这种方式开启者，只有rdOpenStatic式的Cursor所以Process Addnew
的资料Process B看不见，非但如此，连自己也看不见。且此时无法用LastModified指
向新增的资料。
    Update呢，就得看谁先Update，先Update者会成功，後来才去update同一笔的Process
会失败，而且就算Move 0而後再来Edit ...Update也没有效，除非Requery之後再来做
    Delete呢，如果Process A删除了某一笔，Process B还是能Move到已删除的那一笔
其实那是指到自己Client端的那一份Copy，但如果想要加以修改，当然会产生Error

二、SQL SERVER 6.5之rdUseServer搭配rdOpenKeyset
   Addnew 後，自己看得见新增者，会出现在Resultset之最後一笔，就算这一笔资料不
落在Resultset的范围，它也会出现在Current Resultset之中，当然其他Proceess是看
不见，而且可用LastModified指向新增的资料。
   Delete後自己当然就看不见了，然而其他的Process也会反映那一笔已删除，就算
Delete的那一个Process Under Transaction，而删除後尚未Commit/Rollback，此时
其他的Process也会反映该笔已删除而读不到；但是等Delete的那个Process 执行Rollback
後，删掉的那一笔在其他Process也立即再出现。不过如果是rdOpenForwardOnly且
RowSetsize = 1，只要尚未读到该笔Data，有可能会等待Delete的那一笔Commit/RollBack
之後才能读取成功。讲说有可能，而不是一定，这是和rdoQuery.SQL的内容有关(这是本
人的假设)。
   某一笔资料被Update且Commit之後，其他的Process如果再去Update它，那要看该笔资
料没有事先被读取了，例如说原本读进来某个栏位值是5，而其他Process在这一瞬间将之
改成4且Commit了，目前的Process想改成3时就会有错。此时要Move 0後再重新Edit修改资
料再Update一次试看看能否成功。当然，如果我们Move到那笔资料时，它早就被改成4了
(且Committed了)，那麽直接Update不会有误。

三、SQL SERVER 6.5之rdUseServer搭配rdOpenDynamic
   这种方式不被建议使用，但仍提出比较。
   Process新增的Data，如果落在其他Process的Resultset之中，那也会见到这新增的
Data，然而rdOpenDynamic的Cursor不能用Bookmark。而Delete / Update皆可同时反映
到其他的Resultset(不过它的读取一定是Commit的资料，和Keyset有些不同)

四、Informix 的rdUseServer配合rdOpenKeyset(它rdOpenStatic/rdOpenDynamic行为和
    rdOpenKeyset相同)
  Addnew 後，自己看不见新增者，这和SQL Server不相同，当然其他Proceess是看不见，
而且没有办法用LastModified指向新增的资料。这真是一件很糟糕的事。甚者，如果一开
始我们的Table 内没有任何Data，那麽连AddNew都会有错，这是OpenLink ODBC Dreiver
For Informix的一个错！

  而Delete呢，和SQL SERVER的情况仍有不同，删掉的那一笔如果尚未Commit，那麽，
其他的Process要读取该笔时会Wait，如果TimeOut那就产生Error。
 
  而Update的特性和SQL Server也不太相同，例如说原本读进来某个栏位值是5，而其他
Processs在这一瞬间将之改成4，并且也Commit了，而目前的Process想改成3时，竟然没
有产生任何错误或Warnning，而Update过後的Data变成4，也不是想更正的3，这真的是太
令人惊奇了！当然，我们可以在更正资料前先Move 0後才Edit修改资料再Update，但是如
果其他的Process在这Move 0後的一瞬间更动原本的资料并Commit了，那结果仍然是错，而
程序却不会知道！我不知道这是否OpenLink 出的ODBC Driver的错，但是在这个现状下如何
解呢？只好设定Cursor Stability的Isolation Level，并配合Set Lock Mode to Wait
某个秒数，在这个例子中先下Update的Process会进入等待，後来才Update的Process会产生
Warnning，至於是什麽样的Warnning则不太一定，受这两个Process有没有都设定Cursor
Stability的Isolation Level与Set Lock Mode的影响，传回的Warnning说实在的，真是
满头雾水，不同的设定会传回不同结果，不过至少让程序能传回Warnning了，在产生Warnning
的同时，另一个正在Update而进入Waitting的Process只要尚未TimeOut便可以Update成
功了(因为此时Warnning的Process会把Share Lock解掉)。而那一个有Warnning的Process
呢，就可以使用Move 0, Edit .... Update的程序重新再来一次。另外，如果是Byte栏位的
更新/新增，使用rdUseServer都不会成功，要使用rdUseODBC才能成功，这也是OpenLink 出
的ODBC Driver的错误！

（阅读次数：）