SQL 214/ ISAM 355 error (drop database)

Hi All, Running Informix 12.10.FC4. I am receiving the following error when trying to drop a database. There are no locks on the database (verified with who-lock & querying sysmaster:syslocks) or the table. There are no connections to the database or table, verified by onstat -g sql. In dbaccess: drop database ballot 214: Cannot remove file for table (systables). 106: ISAM error: non-exclusive access. I do not currently have the ability to restart the instance or kick out the users and bring into admin or quiescent modes. Thanks, Michael

Are you connected to that database? Try dropping while connected to sysmaster. Art On Feb 9, 2017 17:41, "MICHAEL HOFFMAN" <offdisc@gmail.com> wrote: Hi All, Running Informix 12.10.FC4. I am receiving the following error when trying to drop a database. There are no locks on the database (verified with who-lock & querying sysmaster:syslocks) or the table. There are no connections to the database or table, verified by onstat -g sql. In dbaccess: drop database ballot 214: Cannot remove file for table (systables). 106: ISAM error: non-exclusive access. I do not currently have the ability to restart the instance or kick out the users and bring into admin or quiescent modes. Thanks, Michael ************************************************************ ******************* Forum Note: Use "Reply" to post a response in the discussion forum. --001a11442ee4e843570548218b6f

I wish there was a "Delete posted message" option. :-) Turns out there was actually a connection. Someone had dbaccess open to the database, but hadn't run a query (so didn't show up under -g sql). And no locks, so not in the syslocks table. Well, at least it didn't take much effort on anyone's part to answer this thread. Thank you Art for the quick response. (I was connected to a different db when I tried the drop. That would have produced a 359 error anyway) Thanks, Michael

Mr. Hoffman - Don't forget "onstat -g opn" ... many times partitions are being accessed/"held" that will block ops without the standard "locks script" showing locking/blocking. A few papers out there explaining how to track users down - no scripts yet that I know of. Buy me lunch and I'll explain ... ;) Thanks - Mark Scranton