SourceGear Support

I haven't messed with it, but if you could guarantee no one would be using Vault ( or you could temporarily bring down IIS / Vault server ), you could edit your maintenance plan script to turn QUOTED_IDENTIFIER OFF, run the maintenance, and set QUOTED_IDENTIFIER back on. In other words, Vault requi...

Vault 3.0.2 and above will require the change. Okay that's what I was trying to get at (when it changed and/or why it changed), since I had developed a process/strategy based on the settings but had no knowledge into when upgrading to a new version why certain things that I technically relied upon ...

Okay, I just installed Vault 3.0.1 on my machine and checked the quoted identifier value and it is indeed set to off after the Vault install.

Did post-3.0.1 change the Vault to on? Is it a bug in 3.0.1 that caused that value to not be set?

Those options are all indeed set (I double-checked), but I assume those are the same options from 3.0.1 and my maintenance used to work but no longer works. The main reason I don't want to use the SQL scripts provided in the KB article is it's more work for me to make sure everything succeeded. I ge...

No, they've been running successfully since I installed Vault 3.0.1 and setup the maintenance plans (I get emails every night when they run). It wasn't until the 3.0.3 upgrade did they start to fail. There are only 2 people other than myself who would have access to this server and they work on sepa...

Yeah, no reason for me to get 3.0.4 based on what the release notes say.

Thanks, 3.0.3 seriously improved performance with folder security. I can't tell the difference between having it enabled and having it disabled.

I upgraded my server from 3.0.1 to 3.0.3 last night and checked my backups still worked, however I didn't bother to check my nightly maintenance jobs and they're now failing becuase QUOTED_IDENTIFIER has been defaulted to off (and I'd much rather use the SQL2000 maintenance feature rather than doing...

This seemed to happen to myself and my team maybe once out of 20 checkins... When I switched to using CRCs to determine file modification instead of last write time, it went away.

Speaking of upgrading, do you have any sort of notification list you send updates to when a new version is released?

Wow, I disabled folder security and it literally takes no time to do anything. In your estimation, will the 3.0.3 speed improvements be similar to the speed without folder security?

Also, when it comes out can I safely upgrade the server and let the clients stay on 3.0.1?

I have both actually. Some groups have no access, some have read access and some have full access (and all vary by repository location).

You assume correctly. And on the repository that's faster, there is no folder security.

If I temporarily disable my folder security, does it delete the assignments I've already made?

When performing a checkout and subsequently a checkin of a single file without much history (one of our assemblyinfo.cs files for instance), the checkout can take as long as 12 seconds and the checkin (revert) can take 5 or 6 seconds (GUI client). This happens both from a client machine as well as d...

Thanks, as a rule here we don't specify working folders other than the root (we have a strict working directory structure) so it's no big deal to do that.