Uwe Grauer wrote: > Paul McNett wrote: >> Uwe Grauer wrote: >>> Paul McNett wrote: >> What happens when you set AutoCommit=False for firebird and manage the >> commits yourself? >> > > Not possible for firebird. > There is no autocommit support in the firebird backend. > We would have to mimic this in dabo. > See dbCursorMixin.flush()
I thought you said in your prior message that Dabo mimics Autocommit for firebird, so I thought that setting AutoCommit to False might turn off that mimicing. >>> I was willing to do the necessary adjustments for firebird, but couldn't >>> get the right answers for my questions. >>> See dabo-dev thread "Transaction handling in dabo". >> Ok, I began to review that thread, and found as the most recent message >> from Ed: >> >> """ >> On Mar 12, 2007, at 10:50 AM, Uwe Grauer wrote: >> >> > Now i'm asking again: >> > How should we make explicit transactions behave like it >> > has to be and still have the current behavior to mimic a >> > autocommit setting? >> >> OK, I get it. I will do it myself. When it is posted, please test >> and let me know if it works. >> """ >> >> Did nothing come of this? If not, why don't you add a ticket with the >> relevant info so we don't forget about it as we go forward. >> > > Nothing was done about this. > There is a ticket from about 5 month ago: > http://svn.dabodev.com/trac/dabo/ticket/1014 Man, that ticket is ugly. We really need to explicitly define the problem and format the examples so they aren't a bear to read. The problem isn't that the different database adapters have implemented flush() in different ways, but that transactions are being committed automatically when that isn't desired, at least for Firebird. flush() commits the data, so that is probably working right. However, when and where flush() is being called seems to be the problem. >>> I added begin/commit/rollback logging to the DatabaseActivityLog to >>> be able to see what dabo is doing for firebird. >>> Maybe we should add this for other databases also and write testcases to >>> be sure about if it works as it should. >> If we could come up with a set of DDL that basically works on all >> databases, we could write a test script that turns on the db activity >> log, runs the DDL to create the tables, and then does SQL queries using >> bizobjs. Then, we could diff the db activity logs to see if all backends >> are doing the same things in the same order. >> > > Let's create a test to be able to verify the case. > Either we have to precreate a database for this (DDL and DML in one > connection is not possible in Firebird) or we have to do DDL and DML in > two connections one after another. Whatever is needed. Two connections wouldn't be a problem. See my recent dabodemo/tutorial/dbEditableGrid.py if you need some boilerplate for how to set up Dabo connections in a script. -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
