Is there any way of keeping all of a solution in one script project?

We do not have a source code control plug in for Visual Studio 2005 and I am trying to establish an efficient way of controlling versions of a solution I have created in BIDS, which includes SSAS objects plus an SSIS package.

As there are so many individual files for the dimensions, cubes, database, etc., it does not seem feasible to have them all checked in to our source control application and I was thinking of creating an Analysis Services Scripts project via SQL Server Mgt Studio where I could simply script out the SSAS database and the package and use these via the Deployment Wizard to deploy.

However -

a) according to BOL, an Analysis Services Scripts project has Connections, Scripts and Miscellaneous folders - when I create one, it has Queries instead of Scripts and when I script out the database I cannot see the xmla file in the project. Am I getting hold of the wrong end of the stick here?!

b) An SSIS package cannoy, I think, be scripted as such; when you deploy it creates the dtsx file and the SSIS DeploymentManifest file that installs the package, so is the best idea to keep these two files in source control?

Any advice gratefully received! Thank you

Rachel

I am a little bit surprised that your source control system has a limitation on number of files that affects you. In typical project you might have couple of dozen files, let's say up to a hundrend in a big solution - but modern source control systems can handle hundrends of thousands of files. Is there something here that I miss ?|||

In Visual Source Safe, part of Visual Studio, you do not check in and out individual files, only objects like dimensions and cubes.

Are you trying to build your own version control system? Visual Source Safe should be enough for projects with 1-5 developers?

Regards

Thomas Ivarsson

|||

Sorry, I was not making myself clear; we use MKS Source Integrity (a rather old version that does not integrate with VS) and there is no limit to the number of files it can deal with, but when I started checking in all the dim, cube, dsv, database, ds, dwproj, sln files etc it became apparent that it would be difficult to manage in that you would need to know which files would be affected by a change before you made it - I ended up checking everything out every time (a waste of time and effort!).

So I thought one script file for the database plus whatever the relevant files for the SSIS package are might be a better way forward, but would appreciate advice.

|||If only we had VSS! (see my response to Mosha above)|||So...any further advice from anyone?