I am in a test VRC trying to reconfigure a table and I am getting error 113.

I have users on my system, but NOT in test VRC. How do I free up this lock to enable a change to the data definition?

I get the 113 locks too when developings sometimes, oddly just yesterday on our c3 system... Yes, most of the time it's because the record is locked by yourself or someone else. Sounds like you have eliminated that possibility by logging off and back on, and checking to be sure no one is in the test comany. However, sometimes I have found them to be very stubborn - there is no where to tell what locks are out there, is there? and what process is holding them? And even when I remove all processes, the lock persists - usually after I have been developeing and debugging and the process gets killed or bad sql gets run.

Unfortunatley, what I have had to do is stop and start Baan (rc.stop / rc.start). This removes all DB locks from Baan.
Was hoping someone else would have a better answer, but no other replies so far. Maybe if you can try it tonight when people are off. :(

Added: I checked a couple postings - do a search for Error 113 on these boards, and you can see the discussions. Mostly they say to stop / start Baan - I did not read them all.

Good luck, let us know how it goes.

Not sure if this is the problem you are experiencing, but it is something to keep in mind with Informix and parse locks.

Past cases when I've experienced this I received error message 106 error "Non-exclusive access". In such cases we've had to 'bounce' the Informix engine.

Regards,
Brendan

From a DBA colleague:
----------------------------
"If a table is going to be dropped, all users who can access that table should exit the Virtual Machine while one user drops the table. This is not mandatory, but is recommended for these reasons:

- For a prepared statement, Informix always keeps a parse lock on the table. As long as the prepared statement exists, the table cannot be dropped. In a multi-user environment many drivers may have prepared statements on a table, so dropping the table will fail.

- Once the Informix driver has prepared a statement, it is reused without being prepared again. This increases performance, but will result in errors if the table is dropped by another user. After one process prepares a statement, if a second process drops the table and recreates the same table, the prepared statement for the first process becomes invalid and will return an error when the driver tries to reuse it. In this case, the $BSE/log/log.informix file will contain the cause of the error."

When a user uses a table in any way , it loads the table definition in shared memory and increments a counter (to indicate the number of users using the same table). When the user log's out of Baan this counter is decreased . So if 5 people has used the table, then the counter against it has a value of 5.

Somehow when a user expereinces a fatal error , his/her BW connection goes and this counter against the table used by him/her is not decremented , the table remains locked in shared memory and this lock goes when shared memory is re-initialized. This lock prevents reconfig of table , re-organize and deletion of table.

We stopped and started BaaN last Thursday evening. Apparently this removed the table lock and I was able to proceed with table changes.

Thanks for the comments.

For more info. Refer to - http://www.baanboard.com/baanboard/showthread.php?s=&threadid=13279

-Suhas