SQL 214/ ISAM 355 error (drop database)
Michael Hoffman (12.10.FC4) got errors 214 and 106 (non-exclusive access) dropping a database although he saw no locks or connections. Art Kagel asked if he was connected to it and suggested dropping from sysmaster. Michael found someone had dbaccess open on the database without running a query, so it showed no locks. Mark Scranton added checking onstat -g opn for held partitions.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
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
Related threads
- Posting from the Informix-list
- Migrating from IDS 9.40.UC6 to 11.50.UC3
- Ip for a network session
- questions onstat -g