February 8, 2023 at 9:52 am
hi,
IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME ='abc'
AND COLUMN_NAME IN ('r1'))
BEGIN
EXEC ('ALTER TABLE abc ADD [r1] VARCHAR(2500) NULL')
END
in stmt first, i have checked its existence using "if not exist" then i used "alter table" command to make the col.
What i am searching is, if we have anything in alter table command which checks if columns does not exist, then it should create.
That is a concise way of creating a col.
yours sincerely
February 8, 2023 at 11:44 am
No, there is no syntax to ALTER
a table and ADD
column only if it doesn't exist, and (presumably) ALTER
the column if it does like, for example, CREATE OR ALTER
for a stored procedure.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
February 9, 2023 at 1:16 am
Using your code as a model, you can make it a bit shorter...
IF COL_LENGTH('dbo.abc', 'r1') IS NULL
EXEC ('ALTER TABLE abc ADD [r1] VARCHAR(2500) NULL')
;
--Jeff Moden
Change is inevitable... Change for the better is not.
February 9, 2023 at 4:47 am
i think information schema is better because col_length is a function call and finally it would go to sys.objects or all_objects or information schema it self.
February 9, 2023 at 4:55 am
i think information schema is better because col_length is a function call and finally it would go to sys.objects or all_objects or information schema it self.
This is what I get using SET STATISTICS TIME,IO ON to measure the COL_LENGTH() method...
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
This is what I get using the INFORMATION_SCHEMA.COLUMNS method...
SQL Server parse and compile time:
CPU time = 8 ms, elapsed time = 8 ms.
Table 'syscolpars'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
So, I'm thinking you're wrong and have it perfectly backwards. 😀 But, it's your choice. 😉
Remember that the functions that are native to T-SQL are not the same as User Defined Functions. Remember also that the things in the INFORMATION_SCHEMA schema are actually views.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 9, 2023 at 6:54 am
February 9, 2023 at 6:56 am
February 9, 2023 at 2:12 pm
The time you're seeing in that image is the time it took to actually make the column change. Try making the actual column change with the INFORMATION_SCHEMA method and see how much worse it is.
My measurements weren't including such a column change because the actual column change isn't what I was trying to measure. I was only measuring your claim that an INFORMATION_SCHEMA lookup is better than the COLUMN_LENGTH() function.
Also, you posted a huge amount of white-space in your graphics and that's why no one can read them.
For everyone else, here's what they look like...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 10, 2023 at 11:23 am
informaton schema was taking 0 cpu and 0 time.
February 10, 2023 at 4:32 pm
informaton schema was taking 0 cpu and 0 time.
Uh, huh... It did in my example, as well. You should also do more than one test to see why the COLUMN_LENGTH this took more than zer0 milli-seconds. You should also pay attention to the reads I cited. They're not free and should always be considered along with CPU time and duration.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply