aaApi_ChangeDocumentFile

One of our tools to migrate into ProjectWise from other document management systems has started having an intermittent issue that I cannot figure out.  To add multiple versions of a document, we fetch all of the versions into a staging area with the version number appended to the filename so they're all unique, and then loop through all of the versions (e.g. Versions of "A.docx" will have "A_1.0.docx", "A_1.1.docx", etc.)  The first version is created with aaApi_CreateDocument.  Subsequent versions get the new version added using aaApi_ChangeDocumentVersion, which creates the new version and attaches the previous version's file to it.  The file is then updated with aaApi_ChangeDocumentFile, specifying the folder and the latest version's document ID, and the local file (e.g. "c:\temp\A_1.1.docx").

This has worked for years with no issues.  Recently, it will sporadically fail on some files.  It doesn't happen often, but fails on certain files consistently.  The error message is "Error 58028: Error changing document file.
The file name is already used in this folder. Change the file name and try again."

I can get around the issue by renaming the file in the staging area ("A_1.1.docx" becomes "A_1.1.docxA") and reprocessing it.  So far, that has not failed to fix the issue.  But I don't understand why it is necessary.

Any insight would be appreciated.

Parents
  • ,

    FWIW, I ran into a very similar problem.  If this is a hosted system by Bentley, please contact the designated support for your system and report the issue.  They may or may not be able to help.

    The "fix" for my similar issue was a change in how the (Bentley) hosted system was clustered. My understanding is that when the first (or latest) version is created, the OS "reports" to the calling program that the file has been successfully written to disk, but that's not necessarily true.  It is might be in "write cache" or written to one of the clustered drives but not the other and when you try to replace the file, the OS tells ProjectWise that the file doesn't exist because it hasn't been written yet to the drive being access.  At least that is my understanding of the underlying issue.

    Like you, I was using a native code application, and the time between a return of success and the attempt to replace the file was very short, so this issue would only show itself intermittently, and never when done manually with ProjectWise Explorer.

    As a test, you might consider adding a sleep statement between when you create the new version, and when you try to replace the file and slowly shorten the amount of sleep time to see if that's the trigger.

    Also, I should mention that I got better (but not perfect) results when I changed my code to remove the file first, then add the new version of the file rather than a "replace".

    HTHs

Reply
  • ,

    FWIW, I ran into a very similar problem.  If this is a hosted system by Bentley, please contact the designated support for your system and report the issue.  They may or may not be able to help.

    The "fix" for my similar issue was a change in how the (Bentley) hosted system was clustered. My understanding is that when the first (or latest) version is created, the OS "reports" to the calling program that the file has been successfully written to disk, but that's not necessarily true.  It is might be in "write cache" or written to one of the clustered drives but not the other and when you try to replace the file, the OS tells ProjectWise that the file doesn't exist because it hasn't been written yet to the drive being access.  At least that is my understanding of the underlying issue.

    Like you, I was using a native code application, and the time between a return of success and the attempt to replace the file was very short, so this issue would only show itself intermittently, and never when done manually with ProjectWise Explorer.

    As a test, you might consider adding a sleep statement between when you create the new version, and when you try to replace the file and slowly shorten the amount of sleep time to see if that's the trigger.

    Also, I should mention that I got better (but not perfect) results when I changed my code to remove the file first, then add the new version of the file rather than a "replace".

    HTHs

Children