Trouble Exporting and Importing documents

I am using VB.NET to Export and import documents to a folder. I have a feeling that there's a setting on ProjectWise that I'm missing and it's overriding the behavior.

How do I export files while skipping files that are more up to date on local drive?

How do I import files back while updating changed files and keep copy on local drive?

This is the code I am currently using:

This Exports the files but doesn't check if the existing files are current. When I tested aaApi_CopyOutDocument it seemed to only copy over older files.

Dim fetchFlags As UInteger = CUInt(FetchDocumentFlags.Export Or FetchDocumentFlags.NoAuditTrail Or FetchDocumentFlags.UseUpToDateCopy)

aaApi_FetchDocumentFromServer(fetchFlags, iProjectId, iDocumentId, sWorkingDir, Nothing, 1024)

Import is a problem as well. The files are deleted locally.

Dim ServerFlags As UInteger = CUInt(PushDocumentFlags.Import)

aaApi_PushDocumentToServer(ServerFlags, iProjectId, iDocumentId, "12dPW update")

Parents
  • Kevin,  Sounds like "words get in the way" type of problem.  "Import" and "Export" mean different things in different contexts.  It sounds to me that you want to essentially "roll your own" check-in and check-out.

    There would be various ways to do this, but it would be helpful to first define what you are trying to accomplish.  If you fetch a file from ProjectWise, be it "export", "check-out" or "copy-out", you are going to get the version of the file stored in the associated storage area.  There are flags that will skip the fetch if ProjectWise has a record (location functions) that the destination already has a copy of the file and will only fetch the file from the server if it has CHANGED on the server, otherwise the call will always fetch the file from the server and overwrite the local copy if there is one.

    So, if you don't want to override the file on the local drive because they are "newer" than the copy on the server, YOUR code needs to check that condition and behave accordingly.  Be aware that comparing timestamps isn't as straight forward as you might think for a number of reasons including that the timestamp on the file depends upon the file system type, as well as timestamps stored by ProjectWise in the underlying database are limited by the db data type.  For SQL Server, timestamps are rounded to the nearest third of a second, while file systems typically record timestamps to the nearest "tick" of the local machine's clock, so your compare will need some sort of "delta" time allowance to consider the two times "equal".  Also, timestamps in the PW database are in UTC format, while the file system might be in a different format (timezone), so your code will need to account for this.  The typical solution is to always convert timestamps to UTC before a compare.

    As for deleting the local files on "import", you can control that with a flag.  Depending upon what API call you use, you should look for something like AADMS_DOCPUSH_LEAVECOPY or AADMS_DOCPUSH_UPDATE_SERVER.  But to update a file in ProjectWise, I'm pretty sure that you first have to check it out, but you probably have already accounted for that.

  • Dan, I am aware of the different methods and I am trying to "Export" and then "Import" files to a specified folder.
    I tested with "copy-out" but need to be able to "Import" the files back.

    Files need to be "Export" to a specific folder, then when required "Import" while updating server with any changed files.
    When the same user needs to "Export" these files again, the files need to be skipped unless modified on the server by another user.

    I need to fetch files with the flag that skips the fetch unless it's changed on the server.
    Date stamps is how I was going to handle this doing as you say and converting to UTC, however I was getting some strange timestamps from the Server.
    But is date stamps necessary when there's a flag that handles the process?

    The functions I have been using are aaApi_FetchDocumentFromServer and aaApi_PushDocumentToServer.
    For aaApi_FetchDocumentFromServer I have already tried using AADMS_DOCFETCH_EXPORT and AADMS_DOCFETCH_USE_UPTODATECOPY together, then AADMS_DOCFETCH_EXPORT by itself.
    For aaApi_PushDocumentToServer I have already tried using AADMS_DOCPUSH_LEAVECOPY and AADMS_DOCPUSH_IMPORT together, then AADMS_DOCPUSH_IMPORT by itself.

    This isn't working though, so what have I missed?

  • Dan,

    I have written a vb.net program to integrate non-integrated software into ProjectWise. The software is 12d Model.
    12d Model uses a folder tree and cannont work in a flat folder structure provided by default from ProjectWise with dms folders.
    I am building something like 12d Synergy, which is a Synergy addon to handle 12d Model, except I'm trying to do it with ProjectWise.

    I have been a ProjectWise Explorer user for over 7 years so I fully understand how the file transfer behaviour works.
    To avoid further confusion I'll just call it Fetch and Push.

    I need to fetch and lock files to a specified folder. Then I need to push the files when required to update the Server copy.
    At some point I need to push and unlock the files. Then later, I need to fetch the files.
    Only one user should have the ability to access these files, due to them being locked.
    During the fetch, ProjectWise should only fetch files that are newer than the local copy.
    During the push, ProjectWise should push files that newer on the local copy and leave the local copy.

    I will test a few flags again and try a different ProjectWise api function, then my fall back is the timestamp option.

  • Export will always override local files and import will always delete local files. I was hoping there was a way to override that behaviour but there's not, so I'll use checkout and checkin instead.

    Answer Verified By: Kevin Cox 

  • Kevin,

    I apologize, I didn't mean to "talk down" to you.  My intention was to try to clarify the various behaviors of the options for fetching and posting files with ProjectWise.

    As you have discovered, each "flavor" of fetch/post have some specific behaviors. As for overriding those behaviors, you are pretty much limited to what is available either via specific API functions or to the behavior defined by the use of flags in other more "generic" fetch/post functions.

    In that customization I mentioned, because the user also wanted to place files in specific locations (among other requirements), and if I remember correctly, the files in the datasource were always the most recent "official" version and were never "checked out".  The customization would  copy out files to be modified, but to get them back into the datasource, there was a separate approval process that eventually placed the approved file into a queue (Azure based), that then would replace the official file with the newly approved file, as well as updating some specific metadata.

    The copy out process required that the customization needed to determine if the file already existed in the desired location, and if it did exist, the application needed to determine if it needed to overwrite the file or not.  That's when the timestamps became important.  For this customization, it was agreed that timestamps were to be the key, not the contents as that would take too much time to process.

    So, you might consider a similar approach if you can't make the Check-out/Check-in approach work for you because of the way ProjectWise organizes files in working directories, etc.  i.e., have your application(s) manage the files and design a method of determining who has access, what kind of access, how files are posted back into the datasource, when they are posted back, etc.

    Good luck!

  • Dan,

    Thanks for your help.

    I didn't think you were talking down to me, I was just trying to give some background to what experience I already have and clarify what the problem was. Intentions get lost in text, where a 5 minute call could have solved this problem straight away.

    I will be using timestamps for speed as well as version control.

  • Kevin,

    Thanks for the followup.  I'm glad to hear that you have a plan and are making progress.  Yes, certainly a phone call would have been a faster way to exchange information as well as well as cutting down on the "back and forth".

    Take care and good luck!

Reply Children
No Data