Is it possible to call a variable for the length of a field (varchar). Typically I always use nvarchar(max) for most things other than when I need a numeric field for math purposes. This is okay until the tables are big and performance takes a big hit.
Is it possible to create a column using varchar(max), then run a length query to create the highest number of characters (this example is just one record, so I'm not truly filtering on a max value. I understand that). Then store that number into a variable and call that variable into creating a new varchar column?
Other uses would be maybe be storing that output/result as a variable for other statements.
Is this possible?
Thanks.
CREATE TABLE Test (
MyCol nvarchar(max)
);
INSERT INTO Test (MyCol)
VALUES ('asdfasdfasdfasdfasdfasdfasdfasdfadfsasdfadfs');
SELECT LEN(MyCol) FROM Test
--44 characters. Store this as output as variable
ALTER TABLE TEST ADD NewMyCol varchar(VARIABLE_HERE?) --LEN from above
UPDATE TEST SET NewMyCol = MyCol FROM test
Comments are accurate, it seems quite dangerous to me to add a column based on the current length stored in the table, and I don't really see the benefit.
However, since people will want to do it regardless of how many people pile on saying it's a bad idea:
DECLARE #len int;
SELECT #len = MAX(LEN(MyCol)) FROM dbo.Test;
DECLARE #sql nvarchar(max) = N'
ALTER TABLE TEST ADD NewMyCol varchar($l$);';
SET #sql = REPLACE(#sql, N'$l$', RTRIM(#len));
EXEC sys.sp_executesql #sql;
Working example in this fiddle.
Related
Is it possible in SQL to use a variable to store query.
For example to save time when subquery is used multiple times inside the main query.
Example:
DECLARE #my_query as varchar(250) = select x from my_table where my_table = y.your_table
SELECT
a,b,c,(#my_query),d,e,f
FROM my_table_1
Is it possible in SQL to use a variable to store query.
Depend on your definition of "query". If you mean store the text which we use to execute the command, then the answer is YES. If you mean an object type query, then the answer is not - since there is no data type that fit this.
What I mean is that a variable can store a value which is string. The string can be any query command that you want. Therefore, you can store for example the text "select col1,col2 from table1".
Next you need to ask how can we use this text in order to execute it as part of a query, which is done using dynamic query.
We can execute a text of a query using the build-in stored procedure sp_executesql, which is build for such needs.
For example:
-- DECLARE VARIABLE
DECLARE #MyQuery NVARCHAR(MAX)
-- SET the value of the variable
SET #MyQuery = 'SELECT ''Yes I can'''
-- Executing a dynamic query
EXECUTE sp_executesql #MyQuery
Here is another example which look more close to your question:
-- First let's create a table
CREATE TABLE T(ID INT)
INSERT T(ID) VALUES (1),(2)
GO
-- And here is what you sked about:
-- DECLARE VARIABLE
DECLARE #MyQuery NVARCHAR(MAX)
-- SET the value of the variable
SET #MyQuery = 'select ID from T where ID = ''1'''
-- Let's combine the text to a full query now
DECLARE #FullQuery NVARCHAR(MAX)
SET #FullQuery = '
SELECT
ID,(' + #MyQuery + ')
FROM T
'
PRINT #FullQuery
-- Executing a dynamic query
EXECUTE sp_executesql #FullQuery
NOTE! Your specific sample of query will return error, which is not related to the question "Is it possible in SQL to use a variable to store query". This is a result of the "query" is not well formatted.
Important! It is HIGHLY recommended to read the document about this stored procedure and learn a bit more of the options it provides us.
https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-executesql-transact-sql?view=sql-server-ver15
I have a stored procedure that can get the number of records in a table, in which the #tableName is the parameter of the stored procedure. Let's call it FastCount:
SELECT OBJECT_NAME(object_id), SUM(row_count) AS rows
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID(#tableName)
AND index_id < 2
GROUP BY OBJECT_NAME(object_id);
Now, let's say I have 50 tables, like data_1950, data_1951, .....data_2000. I wrote a batch, query each table's records count, and put them into a temporary table. It works like a charm
CREATE TABLE #Temp
(
TableName varchar(30),
RecordsCount int
)
DECLARE #sql as varchar(max)
DECLARE #yearN as int = 1950
DECLARE #tbName as sysname
WHILE #yearN <= 2000
BEGIN
SET #tbName = QUOTEName(N'[dbo].data_' + Convert(varchar,#yearN))
SET #sql = N'Exec [dbo].FastCount #tableName=' + #tbName
INSERT INTO #Temp
EXEC (#sql)
SET #yearN = #yearN + 1
END
SELECT * FROM #Temp
DROP TABLE #Temp
However, if I replace the dynamic SQL string part
SET #sql = N'Exec [dbo].FastCount #tableName=' + #tbName
INSERT INTO #Temp
EXEC (#sql)
with a straightforward call
INSERT INTO #Temp
EXEC [dbo].FastCount #tableName = #tbName
Then the whole batch just not work...
So I don't understand why... Should I always use dynamic SQL string and exec(#sql) when programmatically using the stored procedure. A big thanks for taking the time to look.
OK, here is what is happening in the two scenarios that you posed in your original question. (Yes, the reality is that there are probably better ways to achieve your end result, but let's look at the actual problem that you posed .... why is the behaviour of your INSERT / EXEC different, depending on how you made the call).
First, you have your variable declared, that will contain your table name:
DECLARE #tbName as sysname
Then you have your looping block that incrementally increases the year number, to generate the different table names. There's nothing inherently wrong with the looping block, so let's just look at an example using one of the table names, to see what's happening within the WHILE block. Take the first table name as the example, which would be [dbo].data_1950.
Your statement:
set #tbName = QUOTEName(N'[dbo].data_' + Convert(varchar,#yearN))
ultimately takes the string "[dbo].data_1950" - which comes from concatenating '[dbo].data_' with the year number (in this case, 1950) converted to a string (varchar) - and passes it to the QUOTENAME() function. The QUOTENAME() function takes its input and a second parameter, which is the character that the input should be quoted with (if the 2nd parameter is not passed, then the default is []). Thus, if we then converted the #tbName variable to a string, it would appear like this:
[[dbo].data_1950]
Now we get to see the funky way that SQL deals with "sysname" data-types. (In fact, as you read further down, maybe the issue is not primarily tied to the "sysname" data-type, but anyhow, take away from this what you will). To be honest, "sysname" is, in itself, a little bit of a funky data-type anyway, which I tend to steer away from, unless absolutely necessary. But anyhow, on to the details of the issue that you were seeing.
Step 1 - I created a version of your stored proc, but I included a statement that would output the value of the #tableName parameter that was passed in. This gives us an opportunity to see what SQL is doing in the two different scenarios, and then explain why the results are different.
CREATE PROC [dbo].FastCount
(
#tableName varchar(100)
)
AS
BEGIN
PRINT #tableName;
SELECT OBJECT_NAME(object_id), SUM(row_count) AS rows
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID(#tableName)
AND index_id < 2
GROUP BY OBJECT_NAME(object_id);
END
Step 2 - our first scenario is executing the dynamic SQL.
set #tbName = QUOTEName(N'[dbo].data_' + Convert(varchar,#yearN))
set #sql = N'Exec [dbo].FastCount #tableName=' + #tbName
Insert Into #Temp Exec(#sql)
Now, we know that the #tbName variable contains
[[dbo].data_1950]
and therefore we can then infer that the #sql variable contains
Exec [dbo].FastCount #tableName=[[dbo].data_1950]
so that is effectively the statement that is executed by the Exec(#sql) command.
When this runs, and we look at the output of the PRINT command, we see
[dbo].data_1950
and we see a result from our query (the table name and row count). This makes sense, of course, because our table name is "data_1950", and the schema of the table is "dbo", so the SELECT statement to get the row count is going to work as expected.
Step 3 - run the EXEC command directly, without the use of the #sql variable, ie.
Insert Into #Temp Exec [dbo].FastCount #tableName = #tbName
Now, when we look at the output of the PRINT command for this execution of the "FastCount" stored procedure, we see
[[dbo].data_1950]
Of course, this is now NOT going to produce the results that we expect, because we're telling SQL to find the row count for a table named "[dbo].data_1950" (in the absence of the specific schema, SQL will just assume the default schema. In this case, with a schema of [dbo], we'd be telling SQL to get the row count from a table named [dbo].[[dbo].data_1950] - which is clearly NOT the table name).
You should see the obvious difference - in one scenario, the parameter value that is passed into the stored is the "correct" reference to the table name, and in the other scenario it is not.
As a final step, let's look at how the "non-dynamic" SQL would be executed, to achieve the results that we need. In this instance, there's no need for the QUOTENAME() function:
set #tbName = N'[dbo].data_' + Convert(nvarchar,#yearN)
Insert Into #Temp Exec [dbo].FastCount #tableName = #tbName
When we run it in this way, we see the expected output ([dbo].data_1950) from the PRINT command, and we see the expected query results (containing the table name and row count).
Can I explain this behaviour, exactly? Errr, not necessarily ... maybe someone else will be able to explain specifically what is happening, and why. My only interpretation is that when the EXEC() statement is passed the dynamic sql (ie. #sql variable) it is first interpreting the entire string and stripping out identifiers (in the case, the surrounding [] ... on what basis is it making that decision, I don't know). As opposed to the non-dynamic execution, where the #tbName value ([[dbo].data_1950]) is just being passed straight in as the parameter, with no modification (and thus causing the unexpected end result that we saw).
Hopefully this information is useful to you (or, at least, to someone else in the future!).
In general you should avoid dynamic SQL, and you should avoid granting rights to execute dynamic SQL, unless absolutely necessary. This is for performance and security reasons.
The typical way to deal with this situation is to use a partitioned view:
CREATE VIEW DataView
AS
SELECT '1950' TableName, * FROM Data_1950
UNION ALL
SELECT '1951' TableName, * FROM Data_1951
UNION ALL
SELECT '1952' TableName, * FROM Data_1952
UNION ALL
SELECT '1953' TableName, * FROM Data_1953
UNION ALL
SELECT '1954' TableName, * FROM Data_1954
UNION ALL
SELECT '1955' TableName, * FROM Data_1955
(Keep adding select statements until you have covered all of your tables.)
Now to get your table counts all you need to do is execute this:
SELECT TableName, COUNT(*) RecordCount
FROM DataView
GROUP BY TableName
Isn't that much easier?
I am trying to pass column-list and table name as arguments to statement (query) mentioned in sp_executesql.
For column names it is displaying the column names n numbers of times and not the data corresponding to that column. And for table name, it is not allowing it as input all together.
Is there a way?
declare #query nvarchar(max) = N'select #c from #t';
declare #col nchar(1) = 'x';
declare #table nchar(5) = 'sch.a'
exec sp_executesql #query, N'#c nchar(1)', N'#t nchar(5)', #c=#col, #t=#table;
You can only parameterize constant values in SQL queries. This means that you cannot parameterize column names, table names, schema names, database names, functions, and operators.
Hence, you cannot do what you want using parameters. You have to munge the query string:
declare #query nvarchar(max) = N'select #c from #t';
declare #col nchar(1) = 'x';
declare #table nchar(5) = 'sch.a'
set #query = replace(replace(#query, '#c', #col), '#t', #table);
exec sp_executesql #query;
Note: You should really use quotename() on the identifiers, to handle unexpected characters. Also, there is no reason to declare the variables as nchar(). Just use nvarchar(255) or something like that.
This may seem like an arcane restriction, but there is a pretty good reason. One benefit of using dynamic SQL is that the query plan is cached. This allows the same plan to be used each time the query is compiled, saving on the compilation time. Clearly, the table needs to be known for the query to be compiled. It may be less clear that the columns need to be known, but they are also used for index selection.
This question already has answers here:
Programmatically set identity seed in a table variable
(3 answers)
Closed 9 years ago.
I'm using this, but I can't figure out why this doesn't work. SSMS won't give me a useful message other than syntax incorrect:
DECLARE #columnSeed DECIMAL
SELECT #columnSeed = MAX([seeded_column]) + 1 FROM [table] (nolock) WHERE [conditions]
DECLARE #Temp_Table TABLE ([seeded_column] varchar(35) IDENTITY(#columnSeed, 1), [more columns])
I want to take the maximum value from a column in one table and create a temporary table variable with an identity column seeded with that previous maximum value.
Edit: OK, after digging around for into about dynamic SQL I think I've got what should work, but it still isn't:
DECLARE #columnSeed DECIMAL
[#columnSeed set properly]
EXECUTE sp_executesql
N'DECLARE #Temp TABLE (seeded_column decimal IDENTITY(#seed, 1) NOT NULL [more columns])',
N'#seed decimal',
#seed = #columnSeed;
All the info I get now is that I've incorrect syntax near '#seed'
You can't use a variable as a seed. It is invalid syntax. The table variable is already implicitly created before the batch is executed and the variable assigned anyway.
The only way of doing this would be to concatenate the desired query and execute it. All usages of the table variable would need to be in the child scope.
DECLARE #columnSeed DECIMAL(18,0) = 10
DECLARE #sql NVARCHAR(MAX) = N'DECLARE #Temp TABLE (seeded_column decimal IDENTITY(' + CAST(#columnSeed AS NVARCHAR(19)) +', 1) NOT NULL)
INSERT INTO #Temp DEFAULT VALUES;
SELECT * FROM #Temp;'
EXECUTE sp_executesql
#sql,
N'#seed decimal',
#seed = #columnSeed;
I'm sure there is a better way of doing whatever it is you are doing anyway though.
You could just declare the table variable in the outer scope with a seed of 0 and add the desired offset to your SELECT queries from it for example.
DECLARE #columnSeed DECIMAL(18,0) = 10
DECLARE #Temp TABLE (seeded_column decimal(18,0) IDENTITY(0, 1) NOT NULL)
INSERT INTO #Temp DEFAULT VALUES;
INSERT INTO #Temp DEFAULT VALUES;
SELECT #columnSeed + seeded_column AS psuedo_seeded_column
FROM #Temp;
Though the whole need for this seems suspect. You shouldn't normally care what the IDENTITY values are. If this is to prepare data that later is inserted into the table you are calculating #columnSeed from maybe just inserting it and using the OUTPUT clause to get the ID values inserted might be more appropriate and less at risk of concurrency issues.
I think you can't use parameters in DDL. In other words, you won't be able to use #seed in the IDENTITY clause. Convert the seed to a string and shove it into your DDL manually. Something like this should work. (I don't have a SQL Server instance handy, so my apologies if there are any additional errors. The point is: Don't use parameters in DDL statements.)
DECLARE #columnSeed DECIMAL
DECLARE #sql NVARCHAR(1024)
[#columnSeed set properly]
SET #sql = N'DECLARE #Temp TABLE (seeded_column decimal IDENTITY(' || CONVERT(NVARCHAR, #seed) || N', 1) NOT NULL [more columns])';
EXECUTE sp_executesql #sql
please help me with writing this search sql stored procedure
procedure may have different number of parameters at different time
so could any body help me with writing this query. I don't know how to concatenate parameters.
i am new to stored procedure
CREATE PROCEDURE searchStudent
-- Add the parameters for the stored procedure here
#course int=null,
#branch int=null,
#admissionYear varchar(max)=null,
#passingYear varchar(max)=null,
#userName varchar(max)=null,
#sex varchar(max)=null,
#studyGap varchar(max)=null,
#firstName varchar(max)=null,
#lastName varchar(max)=null
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
DECLARE query STR DEFAULT null
IF #course IS NOT NULL
THEN query=
SELECT * FROM [tbl_students] WHERE
END
GO
please complete the query so that it can have parameters which are having values and can search from database on the basis of parameters value. But parameter may vary every time depends on search criteria.
You would probably need to use Dynamic SQL to achieve this. First of all I would highly recommend reading this excellent article. http://www.sommarskog.se/dynamic_sql.html
You're dynamic sql would be something like this;
Declare #query varchar(max)
Set #query = 'Select * From dbo.MyTable Where '
If #Course Is Not Null
Begin
Set #query = #query + 'Course = ' + Convert(varchar(10), #Course)
end
If #Branch Is Not Null
Begin
Set #query = #query + ' and Branch = ' + Convert(varchar(10), #Branch )
end
This is only an example! You will need to build in some checks to ensure that you have one (and only one) Where clause, you must ensure that the integer values are converted to string values correctly. You must also check that the parameters don't have any special characters that could break the dynamic sql - like an apostrophe (')
Using dynamic SQL can be painful and very difficult to get right.
Good luck!
The key with a dynamic search conditions is to make sure an index is used, instead of how can I easily reuse code, eliminate duplications in a query, or try to do everything with the same query. Here is a very comprehensive article on how to handle this topic:
Dynamic Search Conditions in T-SQL by Erland Sommarskog
It covers all the issues and methods of trying to write queries with multiple optional search conditions. This main thing you need to be concerned with is not the duplication of code, but the use of an index. If your query fails to use an index, it will preform poorly. There are several techniques that can be used, which may or may not allow an index to be used.
here is the table of contents:
Introduction
The Case Study: Searching Orders
The Northgale Database
Dynamic SQL
Introduction
Using sp_executesql
Using the CLR
Using EXEC()
When Caching Is Not Really What You Want
Static SQL
Introduction
x = #x OR #x IS NULL
Using IF statements
Umachandar's Bag of Tricks
Using Temp Tables
x = #x AND #x IS NOT NULL
Handling Complex Conditions
Hybrid Solutions – Using both Static and Dynamic SQL
Using Views
Using Inline Table Functions
Conclusion
Feedback and Acknowledgements
Revision History
Sorry, I am having trouble understanding what you are asking. Do you mean the consumer of the sproc may specify some arbitrary subset of the parameters and you want to filter on those?
Assuming the above you have 2 options.
1.
use a where clause something like this:
WHERE ([tbl_students].firstName = ISNULL(#firstname,firstName)
AND ([tbl_students].lastName = ISNULL(#lastName ,lastName )
etc.
What this does is check if your parameter has a value, and, if so, it will compare it to the column. If the param is null, then it will compare the column to itself, which will never filter anything out.
use dynamic sql in your sproc and just include the line of the where clause you want if the param is not null.