Bakhtiar A Hamid wrote:

On 7/19/05, David H <bluepaul@earthlink.net> wrote:

...

Hi list,

At times (it seems) necessary to force a Zope transaction commit. This might occur between two zSQL calls where the second depends on the first's *SQL* transaction's availability but the first has not yet been commited because the *Zope* transaction that includes both zSQL calls has not yet been commited.

I handled this with a call to an external script as below, eg

. zSql1() . pyCommit() zSql2() Publish new page

Here's pyCommit()

# ............................................................... # Extenstion/pyCommit.py # ............................................................... from ZODB import FileStorage,DB

def commit( self ): t = get_transaction() # ZODB builtin if t: t.commit() # ...............................................................

Thats it. And it solved my problem. Is there a reason why this is a bad idea, all things being equal? A better way to do it, when needed?

you're playing with fire ;)

let zope handle the transaction

use <dtml-var sql_delimeter> to separate two or more sql calls

this way, if one of the call fails, the transaction will be aborted

gurus, correct me if i'm wrong, please

hth

Bakhtiar, Thanks very much for responding. Your idea is what I thought of at first - but my Interbase Adapter doesn't like COMMIT statements (!) and I didn't test it out. But it seems that would not solve the problem because both ZSQL methods are embedded in the *same* zope transaction stream, e.g. . Submit a page . call ZSQL1 (part of Zope Tran 100) . call ZSQL2 (part of Zope Tran 100) <--- this depends on zSqL1 being executed but the transaction has not been executed yet, its pending. . Display a page . *now* Zope commits (executes all calls - which is too late in this case). When ZSQL2 is called ZSQL1's results are not yet executed into my RDMS and therefore ZSQL2 cannot see whatever ZSQL1 did. (COMMITs not with-standing). Its understandable that Zope might wait between page presentations to transact all changes until all succeed ( an exception aborts the transaction). Its just in some cases they can't all succeed until some are transacted. David (even with your recommended COMMIT) is not available at the time ZSQL2 is called. From what i've seen it appears that Zope commits transactions David