|
George_George wrote: @@ERROR is enough for us to track the exact error
That's true.
George_George wrote: who returns -4 --
This is something I don't understand. If I create your procedure, run it twice, I get the following result:
Msg 2627, Level 14, State 1, Procedure prc_AddABC, Line 3
Violation of UNIQUE KEY constraint 'UQ__ABC__3BD0198F4316F928'.
Cannot insert duplicate key in object 'dbo.ABC'.
The statement has been terminated.
(1 row(s) affected)
And that's expected. However, no -4 anywhere. Can you post the whole result of your test.
|
|
|
|
|
Hi Mika!
-4 is found from the results window and what you posted is found from message window. I have a screen snapshots, but how could I post here? 
BTW: in the message window, I got the same result. But my confusion is the information in the results window -- there are two tabs, one for results window and one for message window.
Could you see the same content in result window?
regards,
George
|
|
|
|
|
Yes that info was from messages window. My result window has this (on the grid, right click / select all / copy with headers):
ABCERROR
2627
So it prints out @@ERROR which is exactly what your procedure does. No -4.
Are you sure the procedure is like in your post? No modifications done? Use the scripting ability and script it to for example query window to see if you do something after the SELECT @@ERROR AS ABCERROR;
About the question of scripting several procedures at the same tame, use the wizard for the database. Select db, right click then Tasks / Generate Scripts... From there on it's simple. Select what you want.
|
|
|
|
|
Hi Mika,
I checked again the code I posted is the same as what I executed. I have some screen snapshots, how could I post here? If we can not post screen snapshot, do you have any email?
regards,
George
|
|
|
|
|
If you're getting -4 on the result tab and the column header is ABCERROR, I have no idea what could be the cause. Since you're selecting @@error it should return the same as the messages tab.
|
|
|
|
|
Thanks Mika!
In the Results Tab, there are two tables,
- One is ABCERROR and content is 2627;
- The other is Return Value and content is -4.
Could you reproduce my issue?
regards,
George
|
|
|
|
|
George_George wrote: Could you reproduce my issue?
Nobody will reproduce this from what you've described. You must have something else in your SP, or the window where you ran it.
Try scripting the stored procedure in management studio and pasting that here.
|
|
|
|
|
Thanks J4amieC,
I have tried that I could reproduce it again. Here is the scripting result from Management Studio. Any ideas?
BTW: -4 is in Results Window, not Message Window.
I could also post screen snapshots here, but how (I did not find upload attachment function here)?
USE [TestDB]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[prc_AddABC]
AS
BEGIN
INSERT INTO [dbo].[ABC]
values ('a');
SELECT @@ERROR AS ABCERROR;
END -- end of store procedure
regards,
George
|
|
|
|
|
Hello everyone,
Any ideas to find where is the physical location of store procedures showed under Programmability --> Store Procedures of Management Studio?
(sorry for my naive question again) 
1.
I have a source control system and I want to check-in the store procedure code (I think they should be in the form of .sql) so that all developers could work on them in a synchronous way?
2.
And I also want to merge the store procedure code outside Management Studio using other diff tools and let Management Studio reflect the changes -- e.g. if I merge/change the code from outside, when I press refresh button in Management Studio, I can see the new merged code of store procedures.
thanks in advance,
George
|
|
|
|
|
Um, what you see in management studio is the list of stored procedures available in the database - there's no real concept of a 'physical location'.
I think what you're probably looking for the the sql scripts used to create these procedures - that depends on how you created them in the first place...
|
|
|
|
|
Thanks Paddy,
"that depends on how you created them in the first place" -- I created them using Management Studio. Any solutions or ideas to solve my problems in my original post (to integrate with source control system)?
regards,
George
|
|
|
|
|
There may be a faster way to do this, but as per the post below, you can use management studio to script a creation script for your stored procedure.
We have a .sql file for each stored procedure that drops it if it exists and then creates it - we use these when deploying/updating our application. I imagine that this is what you need.
I don't know if there is a tool out there that will reverse engineer your DB and create these scripts for you (I'm sure there probably is)... Somebody else clever here might suggest one that they've used.
|
|
|
|
|
Thanks Paddy!
I am intersted in using the scripting feature as you mentioned to export code into sql text files and check into source control system. Could you let me know which menu do you mean please (some more steps)? I never did this before.
regards,
George
|
|
|
|
|
Right click on object in the object browser within management studio (can be SP, function, table), Script As, Create To, New file.
|
|
|
|
|
Thanks Paddy!
1.
I find I could only export one store procedure at one time? No quick export command from menu to export all store procedures from a database?
2.
I think half of my question is solved, i.e. how to get the text sql form of store procedure. My second half question is, how to sync code with source control system. I think the solution should be merging the code manually and paste the code into Management Studio, then execute alter store procedure to take effect the new changes? Is that working? Or you have better ideas?
regards,
George
|
|
|
|
|
re point 2:
Depends on your circumstances - if it's a standalone system and you only have one instance of it, then that sounds fine.
If you need to install this in a number of places, having a little installer application that runs through and executes each of the SQL files is probably a good idea - means you can always be sure that the latest of everything is on the machine.
Also, if you have the definitive version in source control, you can check that nobody's been f*cking around with it.
|
|
|
|
|
Thanks Paddy,
1.
How about your answer to my question #1?
2.
I am interested in the installer solution. But how could I invoke SQL statements (e.g. the statements used to create table/store procedures) from an installer application? My confusion is the instlaler application should only be able to call binaries, but how to call sql statements (text, not binary)?
regards,
George
|
|
|
|
|
George_George wrote: Any ideas to find where is the physical location of store procedures
All information concerning a stored procedure is located in system tables. These tables reside in the primary file group of the database. However, the physical location isn't normally relevant for these tables (unless you're interested in complex backup/restore scenarios etc.).
One place you can look at is sys.sql_modules. From that view you can see for example your current procedures and their implementation.
George_George wrote: I have a source control system and I want to check-in the store procedure code
You can use Management Studio's ability to script a procedure. Using it, you'll get an initial version for your source control. After that, modify the script as you like and check-out/check-in when you make modifications. I'm not aware that Management Studio supports any source control system so you may have to do this using file system operations (meaning you checkout to a file and then open it in Management Studio etc)
George_George wrote: And I also want to merge the store procedure code outside Management Studio using other diff tools and let Management Studio reflect the changes
As previously use whetever tools you need and open the result into Management Studio.
George_George wrote: merge/change the code from outside, when I press refresh button in Management Studio, I can see the new merged code of store procedures
You first have to execute the script in order to get the procedure to the database. After that, you'll see the change.
|
|
|
|
|
Thanks Mika!
So many comprehensive comments.
Forgive me that I am a newbie and after reading and following your comments I have some further questions.
1.
"One place you can look at is sys.sql_modules." -- from Management Studio under System Database, I only see 4 database -- master, model, msdb and tempdb. Where could I find the sys.sql_modules as you mentioned?
2.
"You can use Management Studio's ability to script a procedure." -- good point to start! Could you let me know which menu do you mean please (some more steps)? I never did this before.
3.
"As previously use whetever tools you need and open the result into Management Studio."
"You first have to execute the script in order to get the procedure to the database. After that, you'll see the change."
Just confirm your points. My understanding is, I merge the code manually and past the code into Management Studio, then execute alter store procedure to take effect the new changes? Is that what you mean?
regards,
George
|
|
|
|
|
George_George wrote: could I find the sys.sql_modules as you mentioned?
It depends on the version of your Management Studio, but most likely if you expand the following tree path, you'll find them: YourDatabase/Views/System Views. There's a bunch of views including sys.sql_modules.
Or another way is simply to execute a select statement:
select * from sys.sql_modules
George_George wrote: You can use Management Studio's ability to script a procedure
Right click on the procedure and select Script Stored Procedure as/Create To/File... (or some other target). If you want to script everything in the database select the database, right click and Tasks/Generate Scripts...
Try to play around with the Management Studio. It has many helfpul features.
George_George wrote: My understanding is, I merge the code manually and past the code into Management Studio, then execute alter store procedure to take effect the new changes
Exactly. That replaces the information in the system tables and then you can use your new version of the procedure.
|
|
|
|
|
Thanks Mika,
I have found the store procedures from sys.sql_modules! Cool! But I think using Script Stored Procedure as/Create To/File should be more convenient than using sys.sql_modules to achieve my goal of sync with source control system. Any comments or ideas?
regards,
George
|
|
|
|
|
Absolutely use scripting abilities provided by Management Studio.
The reason I explained the sys.sql_modules was to give you a basic understanding how SQL Server stores information about database objects in the system tables. This was based on your question "where is the physical location of stored procedures".
System tables are very handy in several situtations but in this particular case scripting using Management Studio is both easier and more reliable.
|
|
|
|
|
Thanks Mika!
I find I could only export one store procedure at one time? No quick export command from menu to export all store procedures from a database?
regards,
George
|
|
|
|
|
Have a look at my article here[^], it explains the System Management Object and gives you examples of how to generate scripts for all database objects - you may have to tweak it to do exactly what you want, but its a good starting point.
Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP
|
|
|
|
|
Thanks Bob!
Good start point!
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
