September 10, 2001 at 3:29 am
Hi,
I am trying to place a SQL Server 2000 database under source code control.
1. Create a Data Project under Visual Interdev to connect to this database, following which I can see all the tables/views/stored procs, etc.
2. Place the Data Project under Source Code Control by right clicking on the Connection in the Data View window and then clicking on Add to Source Control...
3. Something appears to be hapenning for a few minutes, and I geta success msgbox; the SourceSafe database also shows the entries for all the Strored Procs.
4. However, none of the Stored Procs show the LOCK icon in the Data View window, which signifies that the SPs are not under source control.
5. If i right click on any one SP and click on Add to source control, an error occurs saying that it's already under source control..
No amount of refreshing etc. seems to be rectifying this problem.
Any ideas, anyone?
The setup(this is the m/c on which i have been trying):
Windows 2000 Advanced Server
IIS 5
Visual Studio SP 5
SQL Server 2000
September 10, 2001 at 8:33 am
Where I work we don't use Visual Studio to check in and out our stored procs. What we do is save off any stored procs to files and then put the files into SourceSafe. I've seen one other newsgroup where someone is having problem between Visual SourceSafe and SQL Server 2000 in the manner which you are trying to use them together, but there wasn't any answer there, either.
I know I real a while back an article about using Visual Studio's capability to put stored procs under source control and some issues concerning that, but I can't recall where I saw the article. I'll see if I can find it.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
September 10, 2001 at 2:36 pm
This may be of interest to you -
there is a free utility in the SQL Server Resource Kit that allows you to automatically compile all of the files in VSS that end in a specified extension (.sql, .txt, etc.) recursively from a designated parent folder by label. So, if you label your stored procedures in VSS at some point - like v1.01, v1.02, etc, you can easily control your test environment and keep a better handle on "versioning" for SQL too.
I have used VSS quite a bit with SQL, and have never had ANY luck using Visual InterDev. We always do as Brian was saying, save the file out of Query Analyzer or whatever (Visual Studio) as a .sql file and then put check back into VSS.
Some places where I have worked, this was easy to get everyone tod o, other places, I have had a difficult time getting developers to not just double click on a stored procedure right in the server and change it through the Enterprise Manager GUI. I wish MS had never provided that functionality, or just made it view only. Oh well.
Good Luck!
Mindy
September 10, 2001 at 4:07 pm
I use the same method Mindy outlines. Have not tried it in Interdev - I'll ask Leon, I know he has explored how Interdev and SourceSafe interact some. Looking through google/dejanews, I saw a couple posts with the same problem, but no solution.
You may have already looked at these, but figured I would post anyway - maybe that one nugget you need will be in there somewhere! If you do find an answer, please post it - you won't be the last person trying to figure it out Im sure.
Here is the article about using VSS and VB and stored procs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql7/html/sql7storprocvers.asp
Found this about SQL 6.5 and Interdev:
And here is one about SQL 7 and Interdev:
http://support.microsoft.com/support/kb/articles/Q199/2/04.ASP
Andy
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply