Paul McNett wrote: > Carl Karsten wrote: >> One thing I am totally in the dark in is how the server returns the number >> of >> records processed by an UPDATE command. > > Different servers can return this information, and if the Python > connector can get that value back from the server, then it can report it > in the return value from the cursor.execute() method. If so, then Dabo > can get at it. > > >> VFP's conflict detection dosen't happen until after the SQL UPDATE command >> is >> processed by the server. so I don't see how that is "ahead of time." > > It isn't. > > >> What backend would prevent an UPDATE command from updating that would update >> on >> some other server? we are talking standard SQL UPDATE command, right ? > > I'd like to know, too. I could see a server knowing that client > connection 1223 last queried the row prior to some other connection > committing a change to it, and so when client 1223 goes to commit the > server says "no way, you don't have the current data", but I don't know > which server or servers would do this. > > Firebird would do this if you specified the right isolation mode. 1. user1 begins transaction 2. user1 selects some rows 3. user2 begins transaction 4. user2 selects some rows 5. user2 updates some rows 6. user2 ends transaction 7. user1 updates some rows (same rows than user2) 8. user1 ends transaction and FB refuses it
Of cause only a multigenerational database would be able to do this. In Firebird you can start a transaction in snapshot mode and get consistent data for a report for this moment and still other users are updating and inserting records. Thats's one of the reasons i love firebird for. Uwe _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
