Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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();
                    Console.WriteLine(c.msg);
                    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;
                        Console.WriteLine(c.msg);
                        Messaging.Log(c.msg, c.lw);
                        sli2 = enumSLI2.Next();
                    }
                    keysToDelete.Add(kvp.Key);
                    break;
                }

sli2.UserName returns something along the lines of:

HOU-AGSPRD01.10768

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

share|improve this question
    
"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. –  matt wilkie 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 –  Kirk Kuykendall 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! –  Chad Cooper Sep 16 '10 at 3:23

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer

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:

D:\forumtest.gdb\ED50Points.S3430F.2924.7980.sr.lock
D:\forumtest.gdb\_gdb.S3430F.6740.6628.sr.lock

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.

share|improve this answer

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
share|improve this answer
    
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). –  Chad Cooper Oct 27 '10 at 20:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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