Dag H. Wanvik wrote:
Hopefully, we should not even need a separate round-trip, but get info back with the row data (perhaps via a warning?), so the client would always be aware if a row had been updated as soon as it got it from server.
Frankly, my head is spinning trying to think about this. With all the various combinations of "own" updates versus "others" updates, transaction isolation levels, implicit and explicit rowsets, etc., this seems like a horribly complicated behavior to try to explain to a user. I tried looking at the docs for a couple of other DB vendors, and they were full of lots of complex language about when the rowUpdated() method would and would not detect an actual update. Some vendors seemed to say that rowUpdated only detects updates made by others; some seemed to say that it only detects updates made by this result set; some just punted and said they don't support the method. For example: http://www.lc.leidenuniv.nl/awcourse/oracle/java.920/a96654/resltset.htm#1020514 http://www.ipd.uka.de/~oosem/mobiledb/pb/docs/server_embedded/html/htmlfiles/dev_tutorial2.html Do we know anything about how actual applications use this method? Since I've never tried to use it myself, I don't think I can contribute much to the discussion about what might or might not be an acceptable implementation. thanks, bryan
