DateTime is a simple concept as long as you don't think about it. I guess that's true for most things, but I don't want to get too off topic here. When it comes to DateTime mixed with thinking, some annoying questions come up. Such as...
"What happens when the Vault server is in a different time zone as the client?"
"How do cultural settings affect the DateTime value? (Example: 01/31/2010 versus 31.01.2010)"
There are basically two ways that Vault handles DateTime values. Which way is used depends on how the information is being passed to or from the server.
Mechanism 1: DateTime objects
If you are dealing with a DateTime object, life is simple. The object will always reflect the local time. Things like leap year and daylight savings time are automatically taken into account. If the client and server are in different time zones, the web services framework automatically converts things for you.
Example: File.CreateDate. This value will always be the time in your local time zone. Even if somebody from another time zone created the File, you will see the CreateDate as if the File was created from your time zone.
Mechanism 2: DateTime strings
Sometimes the DateTime value needs to be passed as a string. In this case, the web services framework will not help you. The Vault solution is to convert to Universal Time then write out the value in a specific format. Specifically, "MM/dd/yyyy HH:mm:ss" is the time format. It's OK if this format doesn't match your current culture's format. The point is for the Vault client and server to use a common format.
Example: When doing a search on a DateTime value, you need to call ToUniversalTime().ToString("MM/dd/yyyy HH:mm:ss") on the DateTime object you are using. PartialMirrorCommand.cs in the Vault Mirror sample has an example of this search.
The Problem: Through the API, you download a file and place it in the local workspace. But when you open up Vault Explorer, it says that the file has been edited out of turn.
The Solution: After downloading the file, you need to set it to read-only (unless you have it checked out to you) and you need to set the create date of the local file to match the create date of the File object.
PublicSub DownloadFile(ByVal file As File, ByVal localPath AsString) Dim buffer AsByte() docSvc.DownloadFile(file.Id, True, buffer) System.IO.File.WriteAllBytes(localPath, buffer) Dim info As System.IO.FileInfo = New FileInfo(localPath) info.CreationTime = file.CreateDate info.Attributes = info.Attributes Or FileAttributes.[ReadOnly] EndSub
Technical Details: The problem isn't that the file was downloaded wrong. The problem is that Vault Explorer expects things in a certain way. If you want to "play nice" with the Autodesk clients, then you need to perform a few extra steps.
Introduction: I've had a few requests for this one. Since it was a pretty cool idea and not too hard to write, I decided to go for it. Don't ever say that I never did anything for you.
Under the hood, this is just a re-write of Vault Mirror. Just like with Vault Mirror, this utility can be run from the task manager. And this utility also has 2 ways of running. There is a "quick mode" that only works on new files and a "slow mode" that scans every file in the Vault. The recommendation is to create a Windows scheduled task that runs every 10 minutes or so to keep things mostly in sync.
The Folder Property is not as reliable as Vault Mirror. Because locked files can't be edited, you will find that several files won't have the property set. Another difference is that The Folder Property edits data, so it consumes a license while it is running. To mitigate the impact, the utility only consumes a license during the actual file editing. When scanning for files, no license is consumed. Once all the edits are made, the utility frees up the license.
See the readme file for additional instructions and command line parameters.
Shares is a feature that dates all the way to Vault 1 and maybe even earlier. It's still around in Vault 2010, but mainly for legacy purposes. If you are new to Vault, odds are you never even heard of shares. Even though the feature isn't used often, the fact that it's there affects other parts of the system.
This article isn't about whether shares are good or bad, and I'm not going to advocate use or non-use. I'm just going to go over the purely technical details.
Concept: A share is the idea that a file can live in multiple folders equally. The word "equally" is what makes things unique. It's not like Windows where a file lives in only 1 location and you can create shortcuts. With Vault, the file truly lives in multiple locations. There is no shortcut, there is no primary folder, there is no folder prioritization. The file lives in each folder equally. A file has to live in at least one folder, but there is no upper limit.
Likewise, a shared file is the exact same file in all locations. The file is not copied to different folders or anything like that. They are truly the same object. Change anything about the file in one location, and you change it for all locations.
Effects: Here are some of the ways that shares impact other Vault features:
It's harder to get the folder that a file lives in or to "jump to" a file. Even if the file lives in only 1 folder, it could live in multiple folders.
There's no Folder property on a File object.
When you delete a file you are really just deleting it from the share. The file will still be around if it lives in other shares. To truly delete a file, you need to delete it from every folder that it lives in.
When you move a file, you are just changing the location of one of the shares.
If you set security on a folder, all files in the folder get updated with the folder's security settings. This is still true even if the file is shared. So it's a "last one wins model" where the file has the security settings of the parent folder that updated security last.
On a user's local folder, a shared file gets downloaded to multiple locations as separate Windows files. However, on the Vault Server's file store, there is only 1 copy.
At the API level, you can find all the file shares with GetFoldersByFileMasterId. The Folders are not returned in any order, so don't assume any sort of prioritization. In fact, the order my change from call to call.