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")

  • 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?

  • Kevin,

    Unfortunately, the words "Export", "Import", "Check Out", "Copy Out", etc. have specific meanings in the "ProjectWise world".

    Using ProjectWise Explorer, a user can do any of these actions, but what they mean, and how they are implemented, are likely to be different from their "generic" meanings.

    A "Check Out" will "lock" a ProjectWise document (and its associated file) so that other ProjectWise users cannot check the file out for modification until the user who has the document/file checked out either checks it back into ProjectWise, or Frees it (abandons the check out).

    There are two ways to update the checked out file on the server, either check the document/file back into ProjectWise (Check In) or use the "Update Server Copy" command, which effectively checks the file in, and then immediately checks it back out, but obviously in "one" step without making the document/file available for others to check out during this process.

    A Copy Out does just that, it copies the file to the user's working directory.  The document/file on the server is still available to other ProjectWise users to modify.  If your design is effectively allowing multiple users to copy out a document/file and modify each copy separably, then you are likely to end up with users overwriting each other's work when the update the file on the server.

    Is there a reason why these users are not using ProjectWise to manage these files?  I worked on a customization for a large user that basically wanted to do what you appear to want to do, and that effort took months to define the workflows, rules, etc. and more time to implement, test, and accept.

    Here's what I recommend:

    • Spend some time with ProjectWise Explorer to understand how the various "fetch" commands actually work
      • i.e. Check-Out, Check-In, Copy-Out, Purge, Export, Import, Send to Folder
      • Keep in mind that you can "Export" files with other provided tools, but what "Export" and "Import" mean in each tool's context isn't necessarily the same meaning as what "Export" means for the Document menu command "Export...". 
    • Get familiar with the location functions
      • These are what are behind the "Local Document Organizer.." menu command
      • This information is how ProjectWise "knows" how to manage the various files for each user/machine.
    • Determine if your application needs to Check-Out or Export (ProjectWise meaning) documents, or if your code will manage those actions.
      • If you are copying out files and various users are modifying different copies, then your application will need to manage how those changes are resolved, ProjectWise APIs won't do it for you.
    • Determine what your application needs to do to "update" or "refresh" the files on the server, keeping in mind how ProjectWise Explorer works, and that the PW SDK APIs provide more control over these processes, but your code should not "break" the logic behind these features.
    • Determine what your application needs to do in order to maintain the integrity of your data.
      • Basically, account for how the various functions work, and how to change their default behaviors with appropriate flags
      • User settings are respected by ProjectWise Explorer, but with the PW SDK APIs, you, the developer, can override or ignore these settings, but in most cases the default action ignores the user's settings, your code should take those settings into account, or at least make sure that the flags to the various API functions are appropriate for the behavior that you want.
    • In order to determine what API functions are actually behind each menu command, take a look at my posting from a few years ago known as "HookWatcher".  You will probably need to update the code a bit as new functions have been added to PW, etc., but it can give you better insight into what functions are behind each action.  This is because the menu/action name doesn't always "line up" with the naming of the related functions.  This is another example of "words get in the way" problem!

    I am curious as to why your users are not using ProjectWise Explorer (or other product tools) to manage the files.  What does these tools lack that compels you to to implement your own application?  Another option is that you can customize ProjectWise Explorer with the PW SDK to change the default behavior of various features, or add additional functionality.

    HTHs

  • 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