Re: Stored Procs + SQLWindows

Angelika = This is Product Defect # 78339: LOCK MODE changes (to NO WAIT) insid= e = a Stored Procedure. We found this on our box (IDS 7.23.UC3 on HP-UX = 10.20) when we were trying to migrate certain functionality from the= = application code to stored procedures, and were perhaps the second = customer to log this problem. Informix has reportedly fixed this = defect in IDS 7.3. Since our client was not in a position to upgrade= = at that time, we have since reverted back to the application code. = HTH = Sujit ______________________________ Reply Separator __________________________= _______ Subject: Stored Procs + SQLWindows Author: draheim@commerzleasing.de (Angelika Draheim) at internet Date: 12/16/1998 5:20 AM Does anybody have experience in Informix ODS 7.13 stored procedures that = are called from a client-programme (Gupta SQLWindows 5.0.4) via Inet? = The procedure deletes records and then inserts new records in the same = table. This should be possible for multiple users at the same time - so = we set the lock mode to wait with commited read in the client = application before the stored procedure call is executed. After the call = is executed, the application calls a commit. Now the problem: A runtime = error 'already in transaction' occurs when the application is run = including 'set lock mode' and 'begin work / commit work' statements in = the stored procedure. Running the application with 'commit work' in the = stored proc leads to runtime error 'not in transaction'. Without = transaction handling at all in the stored proc, the lock mode and = transaction handling in the application seem to be ignored during the = stored proc execution: an isam-error comes up if several users run the = application and delete at the same time. When running the stored procedure in DBACCESS including 'set lock mode' = and 'begin work / commit work' statements everything works fine. Any help is appreciated! = Angelika Draheim CommerzLeasing und Immobilien GmbH D=FCsseldorf Germany