I'm using the ISchemaLock interface to return schemalock info on featureclasses in a file geodatabase:

// If schemalock count is >=2, then we have a problem, something else has a lock on the FC
                if (slc >= 2)
                    c.msg = "Schemalock count on FC '" + fc + "' in FGDB '" + kvp.Key[0] + "': " + slc.ToString();
                    Messaging.Log(c.msg, c.lw);
                    ISchemaLock sl2 = (ISchemaLock)ds;
                    IEnumSchemaLockInfo enumSLI2;
                    sl2.GetCurrentSchemaLocks(out enumSLI2);
                    ISchemaLockInfo sli2 = enumSLI2.Next();
                    while (sli2 != null)
                        c.msg = "  Schemalock info: " + sli2.TableName + " : " + sli2.UserName + " : " + sli2.SchemaLockType;
                        Messaging.Log(c.msg, c.lw);
                        sli2 = enumSLI2.Next();

sli2.UserName returns something along the lines of:


HOU-AGSPRD01 is my server name obviously, but can anyone tell me what the "10768" is? I'm thinking it's the PID of the process that has the lock on the particular featureclass. Any ideas?

EDIT: Kirk and Matt are both correct (can I not set 2 answers to correct?):

alt text

  • "There can be only one!" correct answer. The community generally balances this out by voting up the "other" answer, often higher than the accepted. You could summarize the answers into a single post to accept and mark it Community Wiki, example. I would only do that on long threads with more than two correct answers though, or where the correct parts are intermingled with maybe-not-right parts. And certainly not without upvoting the source answers. Sep 15 '10 at 19:04
  • I suspect if you ran the code while the screen displayed what is shown in your screen capture, that the username would be listed as HOU-AGSPRD01.3068 Sep 15 '10 at 20:35
  • Kirk, I bet you are correct, but unfortunately, this is only happening in my production system, so I can't run my process to test. D'OH! Sep 16 '10 at 3:23

I think they are just pointers to lock files. The lock file name has the suffix shown for the username and the PID. So if you want the PID you'd need to find the lock file having the username's suffix, then parse out the PID from the the lock file.

For example, when I open arcmap with a featureclass in it, then run a standalone exe that opens the same featureclass, I see these files:


The list of usernames looks like this:

username: S3430F.2924
username: S3430F.6740

In task manager, I see no process whose PID = 6740 or 2924, but there's one for both 7980 and 6628.


RE: In task manager, I see no process whose PID = 6740 or 2924

These numbers are thread IDs (TID), and seem to be the ID of the primary thread that started the ArcMap or ArcCatalog process.

To see the list of threads associated with a process in Process Explorer, right-click on the process (e.g., ArcMap.exe) and select Properties, then select the Threads tab.

So, the ISchemaLockInfo.UserName values seem to be:

[machine name].[TID]

And, the lock files seem to be named:
when created by a 9.2 app -

[dataset name].[machine name].[TID].[lock type?].lock

when created by 9.3 (or is it 9.3.1?) and later app -

[dataset name].[machine name].[TID].[PID].[lock type?].lock
  • True. You can use the "Find handle or DLL" tool in Process Explorer to locate the thread and thus the process (which in my cases are SOCs). Oct 27 '10 at 20:19

The PID hunch appears to be correct. Using Process Explorer from SysInternals and [F]ind'ing the lock file shows the number matches the pid.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.