Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Best Practices for using Source Safe with SQL scripts?

Status
Not open for further replies.

jsteph

Technical User
Oct 24, 2002
2,562
0
0
US
Hi all,
Using Visual studio 2008, connecting to an old version of Visual Source Safe (the one that's pre .Net).

In Visual Studio, there's a section where you can add sql scripts to the project, and they'll be tracked in VSS. However, (unless I'm mistaken), you're saving this to source safe but any changes you may make withing sql SMS are not reflected back to source safe, correct?

I know you can edit and even execute these procedures from the Visual Studio environment, but I'm thinking most people like to do their SQL coding in SMS and their .Net coding in Visual Studio--not both in Visual Studio.

So I'm wondering what is a common source-control practice for those who do Visual Studio .Net projects with a lot of SQL code in them? Do you control changes via some separate tool for sql source control? How might this normally be done?

Sorry if it's the wrong forum, I thought this leaned more towards SQL than .Net and didn't want to double-post.
Thanks
--Jim

 
SQL scripts are just a kind of source code, so please try to think of a(ny) reason why you couldn't store and maintain them in VSS? : Just do it!

Only worry I have is that you are using VSS, that's the worst version control system I know. You'd better use SVN, GIT or another more modern and reliable VCS.
 
TonHu,
I am storing them in source safe. The real crux is, for example, Visual Studio 2008 is directly integrated with source safe. As far as I know, Sql-server 2005 is not.

So sure--my .Net code I write, edit, test, change, retest, etc. directly in Visual Studio. The checked-out source files change, and when I check-in, VSS has the changes.

However, that's not so with SQL stored procedures. I'm not comfortable (and part of my question was sort of trying to get a feel for if *anyone* is comfortable) with doing my SQL sp coding from within the Visual Studio environment.

I write stored procs in Sql-Server's SMS, so the stored proc that exists in the actual sql-server database now differs from the checked-out source-save version I see in Visual Studio.

Yes, I can copy/paste changes, but that's tedious and prone to forgetfullness, etc.

So, I do appreciate the advice to store and maintain them in VSS, but I'm wondering if the "typical" .Net developer stores *and* edits their stored procedures from within the VS environment, or does some sort of 'hybrid' like I'm doing (for now)--that is, edit in Sql-Server SMS, then paste to Visual Studio and check-in.
Thanks for any insight on this,
--Jim
 
I don't think that's possible nor supported by any SQL server version. A stored procedure is a part of (read: stored in) the SQL server, and has no direct relation with a sourcefile on your local system.
Maybe it can be done by integrating the VSS provider in/for SMS 2005, so that SMS can (automagically?) upgrade the information in the database?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top