Re: -289 -113 error message
Because you have used exceptions to initiate the rollback it may be possible that the rollback is still in progress when you try to run the procedure again. Art S. Kagel Ioannis Demetriades wrote: > > Hi folks, > > I am running Informix 7.31 UC2 on SCO Unix 5.05 and I use a Visual Basic > application to communicate with the server via ODBC (Openlink 3.0). The > Visual Basic application runs sequentially some procedures on the server by > sending SQLs like "Execute procedure eod_auth_file ()". There is no > parallelism or multithreading involved in the VB application -the SQLs are > all sent sequentially and only when the previous one has finished. > > In some cases I run Function A twice in a row but with different arguments. > Function A runs in database transaction mode with Begin Work. If an > exception is raised we do a "RollBack Work", otherwise a "Commit Work". This > function locks one of the tables in exclusive mode. I know that the locks > are released when the transaction is either commited or rolled back (and > this is always the case with Function A). The weird thing is that sometimes > I get a -289 -113 error message when the VB app tries to execute this > procedure a second time. This error message suggests that we tried to lock a > table which is already locked but this is not possible because the previous > call to Function A had locked the table in exclusive mode and as soon as the > function had been completed the VB application made a second call to the > same function. > > I don't beleive that anybody else was accessing the database at that time, > and even it there was somebody, there is no way they could have locked the > table that Function A is trying to lock. > > Would it be possible that Informix requires some more time to release the > locks? > > Your comments are greatly appreciated > > -- > Ioannis Demetriades > ioannis@ctl.com.cy > CTL Ltd.
Art, I've tried to simulate the problem by doing a RollBack right at the end of the procedure and the second call to the same procedure takes place only after the rollback has been completed (the first call to the procedure returns control to the VB app only when the rollback has been completed). Art S. Kagel <kagel@bloomberg.net> wrote in message news:39A2DA3E.4BB775AA@bloomberg.net... > Because you have used exceptions to initiate the rollback it may be possible > that the rollback is still in progress when you try to run the procedure > again. > > Art S. Kagel > > Ioannis Demetriades wrote: > > > > Hi folks, > > > > I am running Informix 7.31 UC2 on SCO Unix 5.05 and I use a Visual Basic > > application to communicate with the server via ODBC (Openlink 3.0). The > > Visual Basic application runs sequentially some procedures on the server by > > sending SQLs like "Execute procedure eod_auth_file ()". There is no > > parallelism or multithreading involved in the VB application -the SQLs are > > all sent sequentially and only when the previous one has finished. > > > > In some cases I run Function A twice in a row but with different arguments. > > Function A runs in database transaction mode with Begin Work. If an > > exception is raised we do a "RollBack Work", otherwise a "Commit Work". This > > function locks one of the tables in exclusive mode. I know that the locks > > are released when the transaction is either commited or rolled back (and > > this is always the case with Function A). The weird thing is that sometimes > > I get a -289 -113 error message when the VB app tries to execute this > > procedure a second time. This error message suggests that we tried to lock a > > table which is already locked but this is not possible because the previous > > call to Function A had locked the table in exclusive mode and as soon as the > > function had been completed the VB application made a second call to the > > same function. > > > > I don't beleive that anybody else was accessing the database at that time, > > and even it there was somebody, there is no way they could have locked the > > table that Function A is trying to lock. > > > > Would it be possible that Informix requires some more time to release the > > locks? > > > > Your comments are greatly appreciated > > > > -- > > Ioannis Demetriades > > ioannis@ctl.com.cy > > CTL Ltd.
Ioannis Demetriades wrote: > > Art, > > I've tried to simulate the problem by doing a RollBack right at the end of > the procedure and the second call to the same procedure takes place only > after the rollback has been completed (the first call to the procedure > returns control to the VB app only when the rollback has been completed). Darn a Red Herring! No other ideas here. Art S. Kagel > Art S. Kagel <kagel@bloomberg.net> wrote in message > news:39A2DA3E.4BB775AA@bloomberg.net... > > Because you have used exceptions to initiate the rollback it may be > possible > > that the rollback is still in progress when you try to run the procedure > > again. > > > > Art S. Kagel > > > > Ioannis Demetriades wrote: > > > > > > Hi folks, > > > > > > I am running Informix 7.31 UC2 on SCO Unix 5.05 and I use a Visual Basic > > > application to communicate with the server via ODBC (Openlink 3.0). The > > > Visual Basic application runs sequentially some procedures on the server > by > > > sending SQLs like "Execute procedure eod_auth_file ()". There is no > > > parallelism or multithreading involved in the VB application -the SQLs > are > > > all sent sequentially and only when the previous one has finished. > > > > > > In some cases I run Function A twice in a row but with different > arguments. > > > Function A runs in database transaction mode with Begin Work. If an > > > exception is raised we do a "RollBack Work", otherwise a "Commit Work". > This > > > function locks one of the tables in exclusive mode. I know that the > locks > > > are released when the transaction is either commited or rolled back (and > > > this is always the case with Function A). The weird thing is that > sometimes > > > I get a -289 -113 error message when the VB app tries to execute this > > > procedure a second time. This error message suggests that we tried to > lock a > > > table which is already locked but this is not possible because the > previous > > > call to Function A had locked the table in exclusive mode and as soon as > the > > > function had been completed the VB application made a second call to the > > > same function. > > > > > > I don't beleive that anybody else was accessing the database at that > time, > > > and even it there was somebody, there is no way they could have locked > the > > > table that Function A is trying to lock. > > > > > > Would it be possible that Informix requires some more time to release > the > > > locks? > > > > > > Your comments are greatly appreciated > > > > > > -- > > > Ioannis Demetriades > > > ioannis@ctl.com.cy > > > CTL Ltd.