iedmFile.UnlockFile says non-current user has file checked out?

[revenki]

I have a VBA script which checks out a file, makes a couple changes to the references, and then checks it back in.

Or, it used to. For about a year and a half. Now the file.UnlockFile command....doesn't.

Script runs all the way through, but it gets to file.UnlockFile and throws the error:

Run-time error '-2147220976 (80040210)':

The file isn't checked out by you, which is required by the operation.

Which is a lie -- the file.LockFile command twenty lines above it is what locked it in the first place. I've verified this by printing file.IsLockedByUser.Name in the Immediate window in VBA.

After I terminate the script, I can go into PDM directly and check the file in without trouble. It's just when I try to do it via code using the file.UnlockFile command that it has an issue. This is in every script where I use this command, it happens every time the script is run, it happens with every user, it happens with every file of the type the script runs on (a virtual doc we use for engineering signoffs), and it happens no matter how the script is invoked (via a dispatch or via a test sub in the code).

I have the suspicion it's related to a change in our network that happened earlier this year, same time as the problem first cropped up - working on that angle with our IT guys.

But, is this familiar to anyone? Maybe I'm missing something simple that I somehow used to get away with.

(Using SW 2021 SP5, and Enterprise PDM, with the code hosted in an Excel spreadsheet - long story).

[JSculley]

Can you post the code? Or at least post the code where you lock and unlock with 10 or so lines before and after each.

Also, using IEdmBatchGet/IEdmBatchUnlock instead of LockFile/UnlockFile will give you more control and you can call ShowDlg as a debugging tool to see all the files involved.

[AlexB]

I agree with @JSculley

If we can see your code, it'll help us help you. I've had PDM return errors that have nothing to do with the actual problem before so the only real way to verify if there's an access error on check-in is via the warnings on the batch check-in dialog he mentions.

[revenki]

I think I may have figured out the problem, but for completeness, here's the relevant parts of code:

Code: Select all

        If Not swModel Is Nothing Then
        
            esoIsLocked = swModel.IsLocked
        
            ' -- if the model is locked, it needs to be unlocked
            If esoIsLocked = False Then
                Dim ffile As IEdmFile5
                Dim pFolder As IEdmFolder5
                Set ffile = eVault.GetFileFromPath(currFields(39), pFolder)
                
                swModel.LockFile pFolder.ID, 0
            End If
            
            ' -- NOTE: for some API reason the var enumerator has to be both dim'ed AND set AFTER checking out the file
            Dim varEnum As IEdmEnumeratorVariable10
            Set varEnum = swModel.GetEnumeratorVariable
            
            varEnum.GetVar "ESO Stop Recursion", readConfig, varTemp
            
            If varTemp = "" Then stopRecursionYN = 0 Else stopRecursionYN = varTemp
            
            varEnum.SetVar "ESO Stop Recursion", readConfig, 1
            
            [i]{20 more varEnum.SetVar commands omitted} [/i]           
             
            varEnum.CloseFile (True)  ' -- TRUE to flush the enumerator variable (apply the changes) before closing

            ' make sure we're in either In Work or Under Review States before applying changes

            If (esoState = "In Work" Or esoState = "Under Review" ) Then
                ' -- if the ESO had been locked, and no arg override passed, check it in and back out without versioning
                If esoIsLocked = True And swModel.IsLocked = True And Not (argRunFrom = "Manual" Or argRunFrom = "Dispatch") Then
                    swModel.UnlockFile 0, "Checked in by ESOValidator", 193
                
                ElseIf esoIsLocked = False And swModel.IsLocked = True And Not (argRunFrom = "Manual" Or argRunFrom = "Dispatch") Then
                ' -- if the ESO had been unlocked, and no arg override passed, check it back in without versioning
                    swModel.UnlockFile 0, "Checked in by ESOValidator", 192
                    
                ElseIf argRunFrom = "Manual" And esoIsLocked = True Then ' -- both conditions as double-check
                    ' -- check in, no version, keep checked out (original state was checked out)
                    swModel.UnlockFile 0, "Checked in by manually-invoked ESOValidator", 193
                
                ElseIf argRunFrom = "Manual" And esoIsLocked = False And swModel.IsLocked = True Then
                    ' -- check in, no version, don't keep checked out (original state was checked in)
                    swModel.UnlockFile 0, "Checked in by manually-invoked ESOValidator", 192
            End If
            
            Set varEnum = swModel.GetEnumeratorVariable
            varEnum.SetVar "ESO Stop Recursion", readConfig, stopRecursionYN
            varEnum.CloseFile (True)
            
        End If

It's failing on the last two ElseIfs.

[revenki]

What I may have figured out is...kinda dumb on my part.

Our company migrated to a new domain four weeks ago, right when this particular issue started. We did it in four groups over two weeks, which fits with it gradually appearing. And it fits (although it's kind of a stretch) that a change to any credentials, even just email, could be seen by a PDM operation that verifies credentials as a mismatch.

So, I updated the user emails in Active Directory, updated them in PDM (since validating logins in the admin panel doesn't do that part for you), and validated logins. And it worked.

... except for one file, which had references to a number of pipes designed using virtual parts. I added 32 to the EdmUnlockFlag value (telling it to ignore referenced files not checked out by the current user), and it worked.