SourceGear Support

Hi Tonya, I think I've realised what happened. The upgrade failed just as it went to upgrade the database, leaving the Vault server dead. While trying to get it back, I uninstalled 10.0.2, and this is probably when the web.config would have been deleted. Once I realised that SQL needs to be run in M...

We didn't lose our databases, but we did lose the Shadow Folder config after the 10.2 upgrade. All of the repositories we are shadowing were removed...

I have a weird error. Somehow, someone has checked in a file with a folder and path that read like an essay. The path length that is way more than Vault can handle, and this has stopped the shadow folders working. I've renamed the folder so that the path length is now 265 characters. However, when I...

Yes, it works fine in 5.1.2. I took an SQL backup, transferred, restored and attached it to the 2012 server, then installed VP6. This is the same way I've tested previous releases. Only the server and SQL versions are new, so it's possibly something to do with this. I get the error as soon as I clic...

Just testing Vault Pro 6 on a VM copy of our server. The live system is Vault Pro 5.1.2, Win2003 R2 with SQL 2005 Standard (both 32-bit). The VM is running trial copies of Windows 2008 R2 SP1, SQL 2012, both 64-bit, fresh from Microsoft. On the web admin pages, going to the Email Settings option giv...

Sorry, I didn't make it clear - the sgvault.log snippet was extracted from the server log file. The timestamp coincides with the ASP.NET error in the server's Application Event log I also can't see anything in the client log file which looks like an error (set enableLogging to "true" and c...

Every time a client (normal Vault Pro client) disconnects, our server throws an ASP.NET error: Event Type: Warning Event Source: ASP.NET 2.0.50727.0 Event Category: Web Event Event ID: 1309 Date: 09/11/2011 Time: 13:29:21 User: N/A Computer: NCLTW-APP0002 Description: Event code: 3005 Event message:...

You should just needs to re-install Vault and let it pick up the restored sgmaster and sgvault databases. The user accounts and Vault settings are stored inside these.

You don't need the old system databases (master, tempdb etc).

Not in 1.1.1

Hi Linda, Yes, it's the same bug but with a different outcome. In 1.0.6 the server would perform the checkout but not notify the client. On a cache reset the client would catch up. In 1.1.0 it comes up with a FailDBFault error but the checkout does not seem to be performed. The only way to undo a ch...

In http://support.sourcegear.com/viewtopic.php?t=8782 I reported that in Fortress 1.0.6 undoing exclusive checkouts which were checked out by the same user on a different machine caused the client to lose sync with the server. The server had done the undo, but the client wasn't told. The result was ...

Don't suppose there's any chance of a "what's fixed" section to the release info, is there..? It would save us poor plebs having to go through all the reported bugs to see if they're still there or not?

Thanks,
--
Marcus

Just reset the cache on the clients.

It appears to be a bug which only appears when you undo the checkouts using a different machine. The server performs the action, but the clients don't seem to get updated with the new unchecked-out state. Resetting the cache downloads the real server status.

Hi Jeff, (Wasn't sure whether to move this to the Fortress forum or not...) Both client and server are 1.0.6, although I've installed the 1.1b2 client to see if that made any difference (it didn't). Tech support info below. The problem appears to be when a file has been checked out by a user on one ...

Seems to have been broken in 4.0.6 (or at least in Fortress 1.0.6) :( We're seeing a lot of these double-checkouts; one developer had to clear the cache 24 times in a day because recently-updated files were being affected. This seems to work every time: Developer A has a file checked out. If they un...