I'm using a VBA wrapper to call the aaApi_FetchDocumentFromServer function, and either recieve the "Error checking out a file of document..." for most files I'm attempting to get a local copy of, or the program crashes all together.
Here's the declaration of the wrapper, the call I'm using, and the types I'm using that fails:
Public Declare Function aaApi_FetchDocumentFromServer Lib "DMSCLI.dll" (ByVal ulFlags As Long, ByVal lngProjectID As Long, ByVal lngDocumentID As Long, ByVal lpctstrWorkdir As Long, ByRef lptstrFileName As String, ByVal buffSize As Long) As Boolean
Public Const AADMS_DOCFETCH_MASTER_AS_SET As Long = &H10000000
Dim CopyLocally As Boolean, Dim strDocumentName As String
ByVal SourceProject As Long, ByVal SourceDoumentID As Long
CopyLocally = aaApi_FetchDocumentFromServer(AADMS_DOCFETCH_MASTER_AS_SET, SourceProject, SourceDoumentID, 0, strDocumentName, MAX_STRINGLEN)
Any suggestions? I just want to specify single files to copy locally (no refs) independant of whether the file is checked out or not. My goal is to "refresh" my local copy of files on the server so I can then copy them out to a different server.
Dear Chris,
aaApi_FetchDocumentFromServer(AADMS_DOCFETCH_COPYOUT, lProjectID, lDocumentID, NULL, NULL, 0);
this is what I use in C++ to do the same thing
may be AADMS_DOCFETCH_MASTER_AS_SET is not a correct choice ?
Best Regards,
Ian Emery
Thanks for your reply, Ian.
The reason I am pursuing AADMS_DOCFETCH_MASTER_AS_SET instead of AADMS_DOCFETCH_COPYOUT is because I'm trying to only fetch the one single document I'm specifying, not any of its references.
BUT, the flag you suggested would be a fine workaround if only I was able to alway copy out all the documents I'm attempting to. I haven't figured out the pattern yet, but I'm only able to copy out a handful of the files I've attempted so far. The rest result in 0 from that function (not 1 telling me it was successful).
Jeff, can you provide an example or test case where the return value from the AAAPI document fetch function is unreliable ? That's obviously something that should be fixed, and our own internal tests are quite rigorous about checking those values.
Mike
Yes - I am looking in the working directory and most files are just not copying out. This is frustrating. Does anyone have any suggestions for how I can get files to copy out consistently? I'm at a loss and I've tried several work-arounds already.
The fact that it works sometimes says to me that the function is capable of working within your VBA.
If you can, look at your sample of data, and start comparing the differences between the files that copied out successfully vs those that did not. Are they different file types? Are any of them versions? Do you have adequate rights to access the files? Are there any special characters in the string arguments that might be throwing off the VBA?
Barring that, you might try to go over to the C++ side and build a small test app that runs through the same data set doing the same copyout, and see if you get the same results. If you do, you can dig into the last error codes to see what is happening (not sure if you can do the same from VBA).
What does it tell you that I'm able to get a successful programmatic copy out on my company laptop when I run it, but not on the client machine that I need it to work on?
If by "company laptop", you mean your development machine, I would check for dependencies and make sure that the "client machine" has those DLLs, etc. as well. Also check the versions of the software involved including ProjectWise. Ideally, you should compile and link your code to a specific version of ProjectWise. And of course make sure that the OS user running ProjectWise has whatever access that is required such as write access to their working directory, etc.
HTHs