Anytime I'm editing and debugging a SQL Server stored procedure, I'll make the changes, then refresh all along the line. I'll refresh folders: Stored Procedures, Programmability, the DB itself, all the way up to the server.
Regardless of how far up I refresh, when I click on the changed procedure, and no, I don't need to post examples of 'which' stored procedure or the code, it does this every time on any changes regardless of type.
But, when I right click on the stored procedure and say, 'Execute Stored Procedure', it always runs on the 'unchanged' code.
It takes 3 or 4 clicks on the 'Debug' button and a check of the code before the 'changed' code suddenly appears.
There seems no rhyme or reason for when the app refreshes with the edited changes, usually 3 or 4 reruns of 'Debug'.
This isn't a huge issue, just a very time consuming one.
Does anyone know how to make the dang thing refresh the 1st time? Without having to re-debug over and over and check the content for changes each time before I know they 'took'?
I try to use the option with recompile in the SP, and some time works,
ALTER PROCEDURE [dbo].[xx] (
#pC_IDLEGAJO char(9),
....
#P_MensajeError VarChar(500) output
)
WITH RECOMPILE
But, finally a drop it
IF exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[NombreStored]')
and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[NombreStored];
Create procedure NombreStored ....
Related
relatively new to this.
I have a stored procedure that should run when a job is triggered. It all worked fine with the files containing test data that I used for import and testing (excel sheets). I got a new file to test with my solution before deploying, but after having executed the job given the new file the stored procedure just keeps loading without having anything done.
I tried to delete the (excel)file and start again, but it says it's open in another program (it isn't). I then noticed that anytime I try to perform a simple select on one of the tables that are used in the stored procedure, it just keeps loading and never finishes. None of the simple commands work.
I've tried this:
SELECT * FROM Cleaned_Rebate
SELECT TOP 1 * FROM Cleaned_Rebate
TRUNCATE TABLE Cleaned_Rebate
DELETE FROM Cleaned_Rebate
SELECT COUNT(*) FROM Cleaned_Rebate
I also tried to create a new stored procedure identical to the original one, but it just never executes the create query. it keeps on loading. It only creates the new one if I remove 90% of the code.
I can't even execute the stored procedure for the sake of saving it (f5) with just an added comment...
I don't know what is wrong, why, or what I should do to fix this. Does anyone have an idea of what could be wrong? any advice is appreciated!
I want to add that these aren't any big tables - some of them should be empty even. the data sets aren't large either (about 100-300 rows?)
We have recently encountered a strange problem on our staging and production environments. We have run an update script to a stored procedure on SQL Server 2005, verified the new change, and started using it on our products. After sometime the same stored procedure has gone missing from the DB. This stored procedure is not being used by any other tasks except the one we are intending to use. We have checked every bit of code and deployment script, but cannot find a trace for just dropping the stored procedure.
This issue doesn't occur on our DEV and QA environments, but on Staging and Production only.
Could anybody help on this?
Kind Regards,
Mafaz
If you've ruled out the obvious (e.g. deliberate sabotage), then I would suggest having a look through sys.sql_modules for a reference to the procedure - possibly there is an accidental slip like:
IF NOT EXISTS (SELECT 1 FROM SYS.PROCEDURES WHERE NAME = 'Proc1')
DROP PROCEDURE Proc1
GO
CREATE PROC dbo.Proc1
AS
...
<< MISSING GO!
IF NOT EXISTS (SELECT 1 FROM SYS.PROCEDURES WHERE NAME = 'Proc2')
DROP PROCEDURE Proc2
GO
CREATE PROC dbo.Proc2
AS
...
i.e. in the Above, the DROP PROCEDURE Proc2 code gets appended INTO the definition of the unrelated Proc1 because of a missing GO at the end of the Proc1 definition. Every time Proc1 is run, it will drop proc Proc2 (and the if exists will inconveniently hide an error if Proc2 is already dropped).
Similarly, another common issue is leaving GRANT EXEC at the bottom of the PROC - if permissions are lax, this can destroy the performance of a procedure.
The best advice here is to execute applications with minimal permissions, so that it is not able to execute DDL such as DROP or GRANT. This way, the app will break when Proc1 is executed, allowing you to quickly track down the offending code.
I have an user defined table type (UDTT) that is already bound with a stored procedure which uses it as a input parameter. I have made a mistake in UDTT structure but I cannot alter UDTT so when I tried to delete it, SSMS complaints that its bound to store procedure so it cannot be deleted. Is there away to delete my UDTT?
thanks
It is required on the drop, and what I normally do is set myself a template script that follows this execution:
-- Table builds or the type
if object_id(N'dbo.<tablename>') is null
begin <create table chunk> end
-- Proc Drops
-- UDTT Drops
-- UDTT Adds
-- Proc Adds
Then if you ever need to Alter a proc, you just seek it on that script and execute the script again. Since there is no saved data in a procedure, this solves type overlooks as well as recompile options needing processed. I found it to make development as well as testing much more conducive.
There is an easy work around here. I use SSMS, and select
SCRIPT AS > CREATE TO > NEW QUERY EDITOR WINDOW.
This gives a script to create. I then rename the existing data type rather than deleting it. Make whatever changes are needed to the recreate script, and execute.
You can then drop the renamed data type.
Its a bit of a work around, and an alter command would be better, but this does the job.
I have a stored procedure that is updating a very large table (with over 100 million records). The stored procedure is updating records in this table.
The steps are as follows:
Store record IDs to be updated in a recordset (not all records will be updated - only about 20000)
Loop through the recordset and call the stored procedure for each record ID in the recordset
Each time the stored procedure has finished (for each record in the recordset mentioned in part 1), update a flag in a table to say that the update completed.
I am finding some strange behaviour. It appears that the stored procedure is passing control back to VB6 before it has completed its updates and is continuing processing the next record. The stored procedure is then timing out later on (on another record ID). Therefore there are flags that say updated (step 3), even though the stored procedure has not run (because it timed out). Is this normal behaviour i.e. for the stored procedure to pass control back to VB6 before it has finished the work?
I have Googled this and I have discovered that it could be because of the way the stored procedure is optimised by SQL Server. I would expect control only to be passed back to VB6 after the updates have completed. Is this not the case?
Please note that I realise there may be better ways of approaching this. My question specifically relates to SQL Server passing control back to VB6 before it has finished the work (update).
The following article proved to be the solution to this problem: http://weblogs.sqlteam.com/dang/archive/2007/10/20/Use-Caution-with-Explicit-Transactions-in-Stored-Procedures.aspx. It appears that the following behaviour was happening:
1) Record 1. Run stored procedure and create transaction. Timeout on SQL Command object occurrs.
2) Record 2. Run stored procedure successfully. Return constrol to VB6 to update flag in database.
3) Record 3. Run stored procedure successfully. Return constrol to VB6 to update flag in database.
4) Record 4. Run stored procedure successfully. Return constrol to VB6 to update flag in database.
5) Program ends. Stored procedure rolls back transaction (transaction now encompasses records 1-4). Therefore records 1-4 are not deleted.
Can you...
run the code in sql management studio and see what happens and report back? if so i will update this answer as that will help us understand if its the code / connection or sql.
other things to investigate, given we dont not what cases you have tested for...
use the same code path in ur vb application and change only the sql in the stored procedure to something very simple but has the same signature as far as what its doing (ie/ basica reading if there is reading, basic deleting if there is deleting, and same for updating and adding) to see what happens.
Also, some other thoughts...
if you are using MSSQL, it's as simple as someone leaving a query window open and it ties up the database. This is easily tested. I've had the same trouble before. I've run stored procedures before that had no timeout, that normally would run immediately but would sit overnight and not run. Only to realize another person left their query window open. Close their window and poof it finally runs. Check this out, it could be a table lock. Whether it be the application doing it, or it is being done by another user making queries to the DB. Check to make sure your application is closing connections to the DB each time their being used.
what is the best way of troubleshoot a stored procedure in SQL Server, i mean from where do you start etc..?
Test each SELECT statements (if any) outside of your stored procedure to see whether it returns the expected results;
Make INSERT and UPDATE statements as simple as possible;
Try to test Inserts and Updates outside of your SP so that you can check it gives the expected results;
Use the debugger provided with SSMS Express 2008.
Visual Studio 2008 / 2010 has a debug facility. Simply connect to to your SQL Server instance in 'Server Explorer' and browse to your stored procedure.
Visual Studio 'Test Edition' also can generate Unit Tests around your stored procedures.
Troubleshooting a complex stored proc is far more than just determining if you can get it to run or not and finding the step which won't run. What is most critical is whether it actually returns the corect results or performs the correct actions.
There are two kinds of stored procs that need extensive abilites to troublshoot. First the the proc which creates dynamic SQL. I never create one of these without an input parameter of #debug. When this parameter is set, I have the proc print the SQl statment as it would have run and not run it. Almost everytime, this leads you right away to the problem as you can then see the syntax error in the generated SQL code. You also can run this sql code to see if it is returning the records you expect.
Now with complex procs that have many steps that affect data, I always use an #test input parameter. There are two things I do with the #test parameter, first I make it rollback the actions so that a mistake in development won't mess up the data. Second, I have it display the data before it rollsback to see what the results would have been. (These actually appear in the reverse order in the proc; I just think of them in this order.)
Now I can see what would have gone into the table or been deleted from the tables without affecting the data permananently. Sometimes, I might start with a select of the data as it was before any actions and then compare it to a select run afterwards.
Finally, I often want to log actions of a complex proc and see exactly what steps happened. I don't want those logs to get rolled back if the proc hits an error, so I set up a table variable for the logging information I want at the start of the proc. After each step (or after an error depending on what I want to log), I insert to this table variable. After the rollback or commit statement, I select the results of the table variable or use those results to log to a permanent logging table. This can be especially nice if you are using dynamic SQL because you can log the SQL that was run and then when something strange fails on prod, you have a record of which statement was run when it failed. You do this in a table variable because those do not go out of scope in a rollback.
In SSMS, you can simply start by opening the proc., and clicking on the check mark button (Parse) next to the Execute button on the menu bar. It reports any errors it finds.
If there are no errors there and you're stored procedure is harmless to run (you're not inserting into tables, just creating a temp table for example), then comment out the CREATE PROCEDURE x (or ALTER PROCEDURE x) and declare all the parameters by copying that part, then define them with valid values. Then run it to see what happens.
Maybe this is simple, but it's a place to start.