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
Related
Problem: Junior SQL dev here, working with a SQL Server database where we have many functions that use temp tables to pull data from various tables to populate Crystal reports etc. We had an issue where a user action in our client caused a string to overflow the defined NVARCHAR(100) character limit of the column. As a quick fix, one of our seniors decided on a schema change to set the column definition to NVARCHAR(255), instead of fixing the issue of the the string getting too long. Now, we have lots of these table based functions that are using temp tables referencing the column in question but the temp table variable is defined as 100 instead of 255.
Question: Is there an easy way to find and update all of these functions? Some functions might not reference the table/column in question at all, but some heavily rely on this data to feed reports etc. I know I can right click a table and select "View Dependencies" in SQL Server Management Studio, but this seems very tedious to have to go through all of them and then update our master schema before deploying it to all customers.
I thought about a find and replace if there is a way to script or export the functions but I fear a problem I will run into is one variable in one function might be declared as TransItemDescription NVARCHAR(100) and one might be TransItemDesc NVARCHAR (100). I've heard of people avoiding temp tables maybe because of these issues so maybe there is just bad database design here?
Thus far I've been going through them one at a time using "View Dependencies" in SSMS.
I think the best solution would be to script out the whole database into a single script from SSMS. Then use Notepad++ (or equivalent) to either find:
All occurrences of NVARCHAR(100)
All occurrences of the variable name, e.g. TransItemDescription, TransItemDesc.
Once you have found all occurrences then make a list of all of the functions to be fixed. Then you would still need to do a manual fix to all functions, but once complete the issue should be totally resolved.
Looking for some help with this as me and my 'Mentor' are having some issues with resolving the problem
I have a stored procedure in SQL Server 2016 that works fine when dates are entered. However I need an Excel sheet to execute the stored procedure, which currently is also working fine.
The issue is when I'm trying to use a parameter with Excel to pass through the dates to the SQL query/stored procedure that I need to bring back. I'm struggling to link the two up to each other
The second answer here by mono código > how to pass parameters to query in SQL (Excel) - should work for me, however when I get to the part which explains 'The code in the next section assumes that you already have a parameter in your query (Connection Properties->Definition->Command Text) in the form “WHERE (DB_TABLE_NAME.Field_Name = ‘Default Query Parameter')” (including the parentheses). Clearly “DB_TABLE_NAME.Field_Name” and “Default Query Parameter” will need to be different in your code'
I'm unsure if this is due I just simply do not know how to write this part, or it's to do with how I'm trying to link up the cells within excel to the parameters within SQL
For some more context, the parameters are dates - to and from, which will be in an excel sheet, which will then feed through to a query, which is where the execute code for the stored procedure is.
If any help or guides or walkthrough's could be given I'd very much appreciate them!
Thanks,
Wil-Liam
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.
I had created a new stored procedure from an existing one. all I did was copy the old one and changed the name.
Now when i run both in the query analyzer, i get data from the original but the new one does not return any data.
It could be with permissions but both are set to public. Any thoughts?
check ansi-nulls value? they can casuse a headach. hard to tell without seeing the code but as a general debug rule; break it apart into its basic queryies and see where the issue is introduced or where it starts to diferentiate from results of the original stored sprocedure
Sorry if my question appears naïve, but... how did you actually make the copy?
I have only used SSMS to work with DBs so far and am oblivious of other interactive tools, if there are any. As to SSMS, a mere replicating is often done in this scenario: sp_helptext [proc name], then copying the output into a new query window, changing the name and voila (i.e. 'executing the script'). The permissions are peeked at in the original proc's properties and usually added using the same or a new script.
It seems so trivial that I feel a bit guilty to put it here. Anyway, that method has never failed me so far. What is yours then?
Sorry, this of course doesn't answer your particular problem with the already copied SP. I just thought maybe you wanted some help in the more fundamental problem of its replicating.
Creating script and re-replicating the sp worked. it could have been the proc's owner or permissions related. dont feel like debugging any more after I got that working.
I'm using ADO in a JScript (Microsoft JavaScript dialect) Windows Scripting Host script to update a SQL Server table. I'd like to get the number of rows affected by the update in the script, but JavaScript doesn't have pass-by-reference and so I can't do the usual thing where I receive the records affected from the Command#Execute function's RecordsAffected argument. So I'm looking for the best way to get that info.
For reasons not related directly to this query, I want to avoid using a stored procedure for this although I realize that that would work (I'd just return ##rowcount out of the SP). I'm trying to find a reliable but simple non-SP means of doing it.
I looked around and found this syntax for the statement:
UPDATE MyTable
SET MyColumn = (blah blah blah)
WHERE (blah blah blah) ;
SELECT ##rowcount as 'RowsAffected'
...which sends me back a one-row ResultSet containing the count. That does seem to work, and in my limited testing seems to work correctly (I don't get the wrong count when other operations are also happening, etc.), but it seems...kludgy for some reason.
Is that the best way to do it, given the perhaps-unreasonable constraints I've listed? Cross-platform solutions are not required (welcome, though, as always), it can be Microsoft SQL Server-specific (2005+).
Thanks in advance.
Not sure why you think it's kludgy. Nothing wrong with this approach.