Recently I noticed that a stored proc we are trying to profile failed to appear in the profiling output.
After adding in SP:StmtStarting and SP:StmtCompleted events, I noticed the TextData reported as
-- Encrypted text
.. but the stored procedure is not encrypted.
This has only recently started happening - we used to profile this SP perfectly fine, and I can't figure what has changed.
Any suggestions would be gratefully received.
UPDATE: The SP is definitely not encrypted. I've created new SP's on the box, and I see SP:BatchStarting event with the new SP's name. With the old SP, I don't see the BatchStarting event, but I do see the statements within the SP executing.
However I need to see the values of the parameters the SP is being called with, as they are table types. Originally I could see the table types being instantiated and populated before the SP is called.
So I figured this out in case anyone finds it useful.
I have table type parameters to this stored procedure. One of the parameters is passed a lot of data (i.e. a C# DataTable with >5000 rows). Without this quantity of data the stored proc profiled fine.
I guess there must be some cut-off at which point Profiler does not show all of the data being passed in.
Someone has altered the stored procedure and added the 'WITH ENCRYPTION' hint, which will cause this behavior. Alter the stored procedure and remove that hint and you'll start seeing the text of the proc again.
Also to note, if you don't have the original code, you will not be able to decrypt the text of the proc to issue the ALTER statement, so hopefully you have that handy.
Here's a decent run down of this option: Options for hiding SQL Server code
Moving the Trace Properties from the default of OnlySP(<your database here>)(user,default) to TSQL or TSQL_Replay unveiled the SQL being used for me, ... Go to File|Properties... and change the [Use the template:] drop-down combobox.
Related
I am currently working with a stored procedure that performs some background processes and then returns one of two results tables.
If it works ok I get a one column table that says success, if it doesn't then I get a four column table with various error data.
While this is fine if you just execute the code from .net, I now need to execute this from within another stored procedure. While I don't need the output, I do need the background processes to take place. I'd usually insert the output into a table, but can't in this case as the columns in the output varies dependent on the result, and as such cannot define a table that it can insert into.
Easiest answer would be to rewrite the outputs of the background SP to be consistent but this isn't an option. I've even tried wrapping this inside a UDF but the stored procedure can't be called from with a function.
Whatever solution I finally use it must work on versions from SQL Server 2008 R2 up to 2016.
Does anybody have any suggestions?
Many thanks,
Mat.
I would image you could create a SP that inserts the result of the inner SP into a temporary table using the hack below.
Insert results of a stored procedure into a temporary table
If that blocks the ouput then you can return no data.
We currently have a process that calls SQLCMD in shell script that outputs the results of a stored procedure to a text log file. The stored procedure does multiple Updates, Inserts, and Select statements and we capture all the messages and results to a text file partly for having a Select statement that shows the table before it is updated and after it is updated. Now we are converting to SSIS and would like to capture both the results and messages in a text file.
I have 2 questions: Is there a way to do this without calling SQLCMD in SSIS and possibly use execute sql or data flow task? If not, what is the best practice for capturing changes? (I see that I need enterprise edition for Change Capture via SQL so that doesn't work for us.)
Edit (more explanation):
I have stored procedure that does 10 updates in a row. Before I do the update I want to see what the table looks like for that specific update query by selecting the data out of it with the same parameters as the update query. Now each update does something different but one may do something to a record that I did not expect. This will allow me to pinpoint the exact problem. The best idea suggested is triggers, although it may be slow, it can be set up to capture the changes that I need.
My report is running without a sweat on my dev environment. I was a happy man.
When deployed on another server, I have the following issue (see below) (less happy now )
The error is:
The variable name '#choix_de_l_adresse' has already been declared.
Variable names must be unique within a query batch or stored
procedure.
I've checked the parameters for the dataset adresse1. Nothing substantial came out (see image below).
I thought it may be related to a case issue with my sql (see below) but nothing striking jumps off
DECLARE #choix_de_l_adresse VARCHAR(38)
SELECT JohnJack.Siren,
CASE WHEN JohnJack.Adresse1_Eco IS NULL
THEN '' WHEN JohnJack.Adresse1_Post IS NULL
THEN '' WHEN (JohnJack.Adresse1_Eco IS NOT NULL OR JohnJack.Adresse1_Post IS NOT NULL)
AND #choix_de_l_adresse = 'Adresse Postale'
THEN Adresse1_Post
ELSE Adresse1_Eco END AS adresse1
FROM JohnJack
The only workaround I've been able to find out is to delete the dataset and to recreate it from scratch.
Update: When I'm using ssrs query builder to run the query batch, it is running fine
Do you think using a stored procedure would help? I read somewhere that text was not a good fit and when possible, a stored procedure would be better.
Have you seen the following issue and were you be able to fix it without deleting and recreating your dataset? If the answer is yes, how did you do it?
I managed to solve my issue.
I created a stored procedure, put my sql code inside and ... voilà ! all the rows I was looking for, were retrieved
I have a CR 2008 report reading from SQL Server 2008 R2 that used to contain 3 parameters and worked like a champ. The business requested the addition of a fourth parameter. I added the variable to the stored procedure, tested and got the results I was looking for. I then created the parameter as a static list of values as we do not need all values available. I went to the record select expert and lined up my parameter with the appropriate database field. Ran the report, got an error on an incorrect amount of parameters. Refreshed the database; the report ran but returned no results. Checked my parameter values against the stored procedure. Once again, the stored procedure returned results. Went back to Crystal and viewed the query. Lo and behold, the query is sending in NULL for the new parameter even though a specific value was chosen on the prompt. I even went so far as view a tutorial on adding parameters to be sure I did it correctly. Anyone have any thoughts on why the parameter isn't being read properly?
I think you need to right click on Database fields from Field Explorer > Database expert > see this picture
that will surely work coz sometimes crystal reports stored procedure need to be reset or refresh to reflect any changes on the SQl code
Our team just experienced for the first time the hassle of not having version control for our DB. How can we add stored procedures at the very least to version control? The current system we're developing relies on SPs mainly.
Background: I develop a system that has almost 2000 stored procedures.
The critical thing I have found is to treat the database as an application. You would never open an EXE with a hex editor directly and edit it. The same with a database; just because you can edit the stored procedures from the database does not mean you should.
Treat the copy of the stored procedure in source control as the current version. It is your source code. Check it out, edit it, test it, install it, and check it back in. The next time it has to be changed, follow the same procedure. Just as an application requires a build and deploy process, so should the stored procedures.
The code below is a good stored procedure template for this process. It handles both cases of an update (ALTER) or new install (CREATE).
IF EXISTS(SELECT name
FROM sysobjects
WHERE name = 'MyProc' AND type = 'P' AND uid = '1')
DROP PROCEDURE dbo.MyProc
GO
CREATE PROCEDURE dbo.MyProc
AS
GO
However following sample is better in situations where you control access to the stored procedures. The DROP-CREATE method loses GRANT information.
IF NOT EXISTS(SELECT name
FROM sysobjects
WHERE name = 'MyProc' AND type = 'P' AND uid = '1')
CREATE PROCEDURE dbo.MyProc
AS
PRINT 'No Op'
GO
ALTER PROCEDURE dbo.MyProc
AS
GO
In addition, creating a process to build the database completely from source control can help in keeping things controlled.
Create a new database from source control.
Use a tool like Red Gate SQL Compare to compare the two databases and identify differences.
Reconcile the differences.
A cheaper solution is to simply use the "Script As" functionality of SQL Management Studio and do a text compare. However, this method is real sensitive to the exact method SSMS uses to format the extracted SQL.
I’d definitely recommend some third party tool that integrates into SSMS. Apart from SQL Source Control mentioned above you can also try SQL Version from Apex.
Important thing is to make this really easy for developers if you want them to use it and the best way is to use tool that integrates into SSMS.
2nd solution from #Darryl didn't work as suggested by #Moe. I modified #Darryl's template and I got it working, and thought it would be nice to share it with everybody.
IF NOT EXISTS(SELECT name FROM sysobjects
WHERE name = '<Stored Proc Name>' AND type = 'P' AND uid = '1')
EXEC sp_executesql N'CREATE PROCEDURE dbo.<Stored Proc Name>
AS
BEGIN
select ''Not Implemented''
END
'
GO
ALTER PROCEDURE dbo.<Stored Proc Name>
AS
BEGIN
--Stored Procedure Code
End
This is really nice because I don't lose my stored procedure permissions.
I think it's good to have each stored procedure scripted to a separate .sql file and then just commit those files into source control. Any time a sproc is changed, update the creation script - this gives you full version history on a sproc by sproc basis.
There are SQL Server source control tools that hook into SSMS, but I think they are just scripting the db objects and committing those scripts. Red Gate looks to be due to releasing such a tool this year for example.
We just add the CREATE statement to source control in a .sql file, e.g.:
-- p_my_sp.sql
CREATE PROCEDURE p_my_sp
AS
-- Procedure
Make sure that you only put one SP per file, and that the filename exactly matches the procedure name (it makes things so much easier to find the procedure in source control)
You then just need to be disciplined about not applying a stored procedure to your database that hasn't come from source control.
An alternative would be to save the SP as an ALTER statement instead - this has the advantage of making it easier to update an existing database, but means you need to do some tweaking to create a new empty database.
I've been working on this tool http://timabell.github.com/sqlHawk/ for exactly that purpose.
The way to ensure no-one forgets to check in their updated .sql files is by making your build server force the staging and live environments to match source control ;-) (which this tool will assist you with).