FailDeltaApply

Beth · Post by **Beth** » Mon Aug 13, 2007 3:49 pm

I'm going to throw in my cents here. Open up your client, connect to your Vault server, and go to Help - Technical Support. Look at the frameworks the client and server are using. Do they match?

I've seen some strange things happen when the .NET frameworks don't match between the client and server and have been recommending to make them match.

Instructions on how to change the .NET framework the client uses can be found here: Change Client .NET Framework.

ICOM · Post by **ICOM** » Tue Sep 04, 2007 3:07 pm

Grr.. We've rebuilt the server in question yet again, and have once again started getting these errors with Vault.

Both client and server are running:
Vault Version: 4.0.1.15780
.Net Framework Version: 2.0.50727.832

More server info:
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 2.0
OS Version: 5.2.3790
Timezone: (GMT-07:00) Mountain Time (US & Canada)
SQL Version: Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86)
Mar 23 2007 16:28:52
Copyright (c) 1988-2005 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

This is currently affecting one repository, and not others.

I had profoundly hoped that v4 would have solved this.

We're willing to run a debug version, or something with more elaborate logging to help you diagnose this issue, but we desperately need this fixed.

Post by **jclausius** » Tue Sep 04, 2007 3:22 pm

How long did you run on the new server before you encountered any of these errors?

Is there any chance a process modified the files in the _sgvault directory? Those baselines must always remain intact otherwise you will encounter a delta apply issue on the server. This usually occurs when a user executes a file system wide grep/replace which also changes the files in the _sgvault folder. Note by default these files will exist in a user's local application data directory, and the files' read-only attributes should be set.

Did you try the "other" working folder I mentioned in my last post? Did that fail as well?

You tried "chunked encoding", so we can eliminate that. Is there possibly a firewall or other network device which may be doing some kind of stateful inspection/manipulation on the network packet data? Since this seems to be affecting files ending in .PHP, I'm wondering if there is some process device finding something it does not like, and modifying the network data. If you try this on the Vault server using the SAME user but connecting to "localhost" or "127.0.0.1", can you re-create the same scenario?

If there is a router involved, another possible explanation could be a mis-configured Max Transmission Unit setting. See Vault Client Can't Connect Through Some Routers (MTU) for more information.

Post by **jclausius** » Tue Sep 04, 2007 3:27 pm

One other issue we encountered in un-explained behavior was actually mis-configured network cards to switch/hub ports. We had the user change their network settings from Full Duplex or Auto-Configure to Half-duplex. This resolved the problem.

FWIW, the user traced things down to a switch or hub which could not handle the NIC configuration.

ICOM · Post by **ICOM** » Tue Sep 04, 2007 3:42 pm

We did a global Get Latest (without overwrite) to ensure there was no _sgvault corruption before attempting to check in, and still got the same error.

We are currently trying a separate working folder, though due to the fact that we were previously seeing this on three separate machines (with different brand/model NICs in each), I don't expect any difference.

I am personally convinced this is not a network issue, especially since we are currently experiencing this issue in only a single repository on the server, while others are still functioning.
We have previously tried changing all manner of NIC settings, including all the different Duplex settings. And again, since we previously saw this on multiple clients, client-specific issues such as NIC settings seem unlikely.

We have no devices or software that should be interfering with network traffic, and we have connected the client to the server with 2 different switches, to try and eliminate any possibility of them being the source of the problem.

Connecting using the client directly on the server itself has not yet thrown this error, though we have not tried it yet with this most recent error. (We will try this next.)

ICOM · Post by **ICOM** » Tue Sep 04, 2007 3:49 pm

Ok, preliminary testing with a new working directory appears to be working.

Is it possible that a Get Latest will not overwrite corrupt _sgvault entries?

If so, what is the proper way to recover from corruptions such as that in the future? Obviously moving the working directory is not ideal.

ICOM · Post by **ICOM** » Tue Sep 04, 2007 4:50 pm

What seems strange about this is that the _sgvault directories are not contained in the working directory, so I find it odd that they would be re-built due to a change of the working directory.

Or is there some other effect involved here?

Post by **jeremy_sg** » Tue Sep 04, 2007 8:42 pm

ICOM,

I investigated this, and found that there are cases where a corrupt baseline was not corrected on a checkin. If you email me using the button below this post, I can send you a pre-release build of 4.0.5 that will correct corrupted baselines. With this fix, as soon as a checkin fails with FailDeltaApply, the client will attempt to correct the busted baseline. Old versions of Vault did that correctly, but that code got bypassed a while ago.