Welcome to EMC Consulting Blogs Sign in | Join | Help

SSIS Junkie

Once upon a time this blog was a hive of activity. Now however its pretty lifeless as you can probably tell so if are pining for more of the same you can find me over at http://sqlblog.com/blogs/jamie_thomson. I look forward to seeing you there!

SSIS: Be wary of using SourceSafe

On my current project we're making extensive use of SourceSafe to store our packages. We're using it directly from within BIDS and on the surface it works very nicely but we have had the odd problem here and there.

The main one being that we get a periodic failure when trying to check stuff in. The error is:

Windows was unable to save all the data for the file "...". The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere

We haven't yet identified the exact cause -though network latency is a prime candidate- but what we HAVE identified is that there is a correlation between the size of a .dtsx file and the frequency of this occurring. Our ASP.Net developers who are using the same solution never have this problem because their files are alot smaller. Our .dtsx files range in size from 500K to 5MB and it is definately these bigger ones with which we have the most problems.

At the heart of the matter is the relative flakiness of SourceSafe and the limitations of the product are pretty much accepted in development circles. This post is a heads-up to those of you thinking of using SourceSafe in conjunction with SSIS - don't expect it to fly as you would hope.

So some tips based on my experience:

  1. Keep your packages as small as can be. A modular approach to development can be of real benefit here.
  2. Backup your SourceSafe on a nightly basis. In the worst cases SourceSafe becomes corrupted and you lose history for certain files.

 

-Jamie

Published 17 January 2006 08:48 by jamie.thomson

Comments

 

Axehandle said:

Are you using VSS 2005 with LAN enhancements?
January 24, 2006 03:58
 

jamie.thomson said:

No, unfortunately we're using VSS 6.0d.

Thanks anyway.
January 24, 2006 08:33
 

Neal Meier said:

Have you used the Deployment Utility at all? I was considering using this mechanism to store packages for backup until Team Foundation Server became available.
February 9, 2006 16:17
 

TomJames said:

Jamie,

So far we have been developing SSIS packages along a single development stream and therefore have managed to avoid parallel development of our packages.

However, due to business pressures we will soon have multiple project streams running in parallel, and therefore multiple code branches, as part of that we will definitely need to redevelop the same SSIS packages in parallel. Judging from your post above and some testing we have done this is going to be a nightmare as we cannot merge the code. We can put in place processes to try and mitigate this but there are bound to be issues along the way.

Do you know whether this problem is going to be fixed? We are now using Team Foundation Server but presumably the merge algorythm used is same/similar to that of VSS and therefore very flaky?

However, not only are we having problems with the merging of the XML files, but we also use script tasks within the packages which are precompiled, as the DTSX files contain the binary objects associated with the script source code, if two developers change the same script task in isolated branches the binary is not recompiled as the merge software does not recognise this object.

Do you know whether these issues have been raised with MS?

Many thanks.

June 29, 2007 09:14
New Comments to this post are disabled

This Blog

Syndication

Powered by Community Server (Personal Edition), by Telligent Systems