Hello out there in net-land...

I have a question/problem regarding table locks.  I am trying to drop an
audit on a table and get a message indicating the table is locked...
        242: Could not open database table (blah.blah)
        113: ISAM error: the file is locked.
However, there aren't any table lock instructions anywhere in any of the
code that uses this table.

If I try to issue an UNLOCK via SQL, I get a message that I'm not the user
who locked the table in the 1st place.

    1)  Where does Informix keep track of whether a table is locked and
        who has locked it?

    2)  If there were any .lok files - where would they be?  (I did a find
        from / and didn't get any results).

    3)  If I unlock the table as dbadmin (assuming I can do this), what
        possible problems could this cause??

    4)  What situations might cause the DB to believe that there is a lock
        on a table and can they be prevented?

I am using SE 4.10.UC2.

Thanks in advance, guys and gals...
--
Mark E. Heringslake                            CompuData Inc. - Philadelphia, PA
Help, I'm in a loop and I can't get            Phone: (215) 824-3000
Help, I'm in a loop and I can't get            FAX:   (215) 824-4423
Help, I'm in a loop and I can't get
Help, I'm in a loop and I can't get

Mark, find the entry for the table "under audit" in the systables catalog
(table) and set audpath to null. For example:

update systables set audpath = "" where tabname = "mytable";

I've seen this same situation from time to time.  At least I used to when
Informix was using file-based (*.lok) locking under SunOS.  We're up on a
version that uses kernel-based locking now, and I don't recall seeing it
recently.

For the Standard Engine, it may be either file- or kernel-based locking,
depending the OS.

They would be in the *.dbs directory that holds the database.  If you
weren't the owner of the database or root when you did the find, you wouldn't
have been able to descend into the directory.  If you don't see any *.lok
files in the database directory, then your version is using kernel locking.

None, if you're 100,000% sure that there is no database activity when you
do it.  With file-based locking, simply copy /dev/null on top of each
offending *.lok file.  Make sure the permissions & ownerships stay in tact.

I'm not familiar with the internals of kernel-based locking.  You may have
to go so far as to reboot the OS.

Could be problems in the OS locking, Informix, etc.  I have never been able
to figure out exactly.

One thing we saw here occurred when Informix changed from file to kernel
locking under SunOS.  To be clean with the Informix upgrade, we unloaded
all data from the old database, the created a new copy under the new
Informix version and loaded the data.  Thus, the new *.dbs directory had
no *.lok files.

Somehow, the new database got "touched" by the old Informix that used the
file locking.  This was while we were playing with a test database, so
we weren't too upset.  It was somewhat sobering, though, and reminded us
to keep very tight controls when we went into production with the new
verion.

Anyway, having spurious *.lok files in the database directory sometime
caused problems, even when the Informix version that used kernel locking
was running.  If you're in that situation, you might check that.

Good luck,

Walt.

--

Emory University               UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt

Atlanta, GA  30329  USA       Voice: +1 404 727 0648