As per title I want to return the full path of all documents on the server. I found that the "dms_doc" table has everything I need for a specific task except the full path for each document. Any ideas which table I can look at that will contain the fully qualified path of each folder?
Hopefully once I know which table contains the full path it will also have either project GUID / project number; then I can relate that back to those columns in dms_doc to expand it to include a full path to each file.
If I remember correctly, dms_doc has a guid of the folder it's in, then you have to jump to another table (I think it's called dms_vault or project, but I'm not on my work computer and can't look it up). In that table each folder lists its parent folder, so then you have to jump up to the parent and check it's parent, and so on until you find the root folder. Basically you have to walk the tree backwards to build it.
Why not use one of the PWPS_DAB cmdlets to do what you wan?. When I want to build a report with a large number of items I typically break it down a bit so I'll get all the folders at the root level then process each of those folders independently. That way I don't need gigabytes of local memory to hold all the objects.
I believe Get-PWFolders and Get-PWDocumentsBySearch can both return full paths.
Answer Verified By: Edward Ashbolt
You can get the o_projguid value for each document and pass that to the Get-PWFoldersByGUIDs cmdlet.
Out of curiousity do you happen to know the process that ProjectWise Explorer uses to map the URI address path for folders / files? For example how does it determine the full folder tree and the path in the address bar; is that through recursion after each click to a new folder location?
If you paste the URL, that has the path in it and it can just walk down the tree. If you paste a urn that uses a guid, it'll have to start at the guid and walk up the tree (this is why urn's still work if the document/folder they are for move)
I suspect they have a saved procedure or something that produces them very quickly.
makes sense. I guess the reason a full path is not included in the database is due to the performance overheads of allocating / querying a path that could potentially be >200 chars in a table which might have hundreds of thousands of entries, text comparison would be very time consuming with that much data.