I'm having a strange problem with an MSSQL Query that I'm trying to run in Microsoft SQL Server 2014. It is an update script for my database structure. It should basically rename a Column (from Price to SellingPrice) of a Table after its content was merged to another one.
USE db_meta
GO
DECLARE #BakItemPrices TABLE
(
ItemNum int,
Price int,
CashPrice int
)
-- backup old prices
insert into #BakItemPrices
select ItemNum, Price from dbo.ItemInfo
-- merge into other table
alter table ShopInfo
add column Price int NOT NULL DEFAULT ((0))
update ShopInfo
set ShopInfo.Price = i.Price
from ShopInfo s
inner join #BakItemPrices i
on s.ItemNum = i.ItemNum
GO
-- rename the column
exec sp_rename 'ItemInfo.Price', 'SellingPrice', 'COLUMN' -- The Debugger executes this first
GO
This query always gave me the error
Msg 207, Level 16, State 1, Line 13
Invalid column name 'Price'.
I couldn't understand this error until I debugged the query. I was amazed as I saw that the debugger wont even hit the breakpoint I placed at the backup code and says that "its unreachable because another batch is being executed at the moment".
Looking further down I saw that the debugger instantly starts with the exec sp_rename ... line before it executes the query code that I wrote above. So at the point my backup code is being executed the Column is named SellingPrice and not Price which obviously causes it to fail.
I thought queries get processed from top to bottom? Why is the execute sequence being executed before the code that I wrote above?
Script is sequenced from top to down. But some changes to schema is "visible" after the transaction with script is committed. Split your script into two scripts, it can help.
Related
As part of the company I am working for at the moment I need to create some database upgrade scripts to replace some work of a previous contractor.
The code before the following block runs, creates the new ID column, and then this script looks to populate the values and then drop some columns.
IF EXISTS (
SELECT *
FROM sys.columns
WHERE object_id = OBJECT_ID(N'[Central].[Core.Report].[ReportLessonComp]')
AND name = 'Name')
and
EXISTS (
SELECT *
FROM sys.columns
WHERE object_id = OBJECT_ID(N'[Central].[Core.Report].[ReportLessonComp]')
AND name = 'Code')
BEGIN
UPDATE
[Central].[Core.Report].[ReportLessonComp]
SET
CompetencyId = rc.Id
FROM
[Central].[Core.Report].[ReportLessonComp] rlc
INNER JOIN
[Core.Lookup].ReportCompetency rc
ON
rc.Code = rlc.Code and rc.Name = rlc.Name
ALTER TABLE [Central].[Core.Report].[ReportLessonComp] DROP COLUMN CODE
ALTER TABLE [Central].[Core.Report].[ReportLessonComp] DROP COLUMN [Name]
ALTER TABLE [Central].[Core.Report].[ReportLessonComp] DROP COLUMN [Description]
END
GO
When running the if exists \ not exists checks and then select getdate() this works perfeclty fine and gives me the result I expect.
However, when I run the code block above I get error
Msg 207, Level 16, State 1, Line 23
Invalid column name 'Code'.
Msg 207, Level 16, State 1, Line 23
Invalid column name 'Name'.
This script it part of a larger upgrade script and is used in a system calle RoundHouse https://github.com/chucknorris/roundhouse which is the system chosen by the company.
Prior to the above if exists check,
IF (SELECT COUNT(1) FROM sys.columns
WHERE OBJECT_ID = OBJECT_ID('[Central].[Core.Report].[ReportLessonComp]')
AND Name in ('Name','Code')) = 2
which also gave the same issue. I have five tables that I need to update and this is going to stop the team from working if I cant resolve this at my next PR
What can I do in order to stop this from causing the upgrade scripts to fail?
EDIT -- The reason I am linking on varchar fields also is because the previous developer did not create relationships between tables, and was just inserting strings into tables rather than relating by ID causing the potential for unlinked \ inconsistent data.
The table edit prior to this creates the new id column, and this script is getting the value and dropping columns that are no longer needed
SQL Server will parse the whole of the statement prior to execution, so the exists check does not protect you from the update being parsed. If the column has already been dropped, that makes the statement invalid and you get a parse error. The update statement would have to be executed as dynamic SQL, sp_execute basically so that the varchar of the update is not directly parsed.
For SQL Server 2016 and above the drop column can be protected a bit more as well:
ALTER TABLE [Central].[Core.Report].[ReportLessonComp] DROP COLUMN IF EXISTS CODE
I am getting this error while executing a procedure
Msg 8152, Level 16, State 2, Procedure SP_xxxxx, Line 92 String or
binary data would be truncated.
I have created a temp table which I will load the data from main table once in procedure and I would be using this table not the main table as main table has huge volume of data and many unnecessary columns.
When I run the below code from sql server management studio then there is no error but when I run this code from a procedure then their is the above error message.
Insert into abc_TMP // tmp for procedure with required columns
Select
Item,
Description,
size,
qty,
stock,
Time ,
Measure
from abc // main table has many columns
One way to check this issue, is to see length of each value
Assume you have table like below
create table t
(
col1 varchar(10),
col2 varchar(10)
)
Inserts into the table will fail,if you try to insert more than 10 characters,if you try to insert them in a batch, you will not get offending value.
So you need to check its length like below , prior to insert
;with cte
as
(
select
len(col1) as col1,
len(Col2) as col2
from table
)
select * from cte where col2>10
There has been number of requests raised with Microsoft to enhance error message and they have finally fixed this issue in SQL2019.
Now you can get the exact value causing the issue
References:
https://voiceofthedba.com/2018/09/26/no-more-mysterious-truncation/
I suspect that you are looking at the wrong line of code in the stored proc.
When you open the proc, i.e. ALTER... you have a header on the stored proc that will throw the line number out.
If you run this, replacing proc_name with your procedure name:
sp_helptext proc_name
That will give you the code that the procedure will actually run, with accurate line numbers if you paste it into a new window.
Then you'll see where the actual error is happening.
If you want a simple way to prove this theory, put a bunch of Print 'some sql 1', Print 'some sql 2' lines in around the code you think is causing the error and see what is output when the error is thrown.
I am having problems with some of my SQL scripts on SQL SERVER, indeed I am trying to transfer data from a column A to a column B of the same table and then drop the column B,
However my problem is that I have to check for the existence of A beforehand because the code is meant to be executed on a server where I don't have access (I work as a third party developper on a professionnal app)
Here is my code:
-- Export the data from the column name
-- Drop the column name
USE p_mynacellelocation_db_ChecklistWPF
GO
IF COL_LENGTH('model_trolley_part','name') IS NOT NULL
BEGIN
UPDATE model_trolley_part
SET name_en=[name];
ALTER TABLE model_trolley_part
DROP COLUMN [name];
END
In the case of the column name being non existent I would like not to do anything
However on execution of the code in a database where the column name is non existent SQL Server returns me:
Msg 207, Level 16, State 1, Line 12 Invalid column name 'name'.
Instead of jumping through all these hoops simply rename your original column.
https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-rename-transact-sql?view=sql-server-2017
exec sp_rename 'model_trolley_part.name', 'name_en', 'COLUMN'
You need to use dynamic SQL for this. The reason is that the parser will try to validate your code, even the code that won't be executed because its IF condition wouldn't be met.
The parser is smart enough to see there is no table named name, but it's not smart enough to realize that the code shouldn't get executed because of the IF, so it raises a parsing error.
Using dynamic SQL in the BEGIN..END block after the IF hides this from the parser so it will execute.
Try this:
IF EXISTS(SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'myTableName'
AND COLUMN_NAME = 'ColumnA')
BEGIN
// your update and drop code goes here
END
you might want to check your account privileges if you are modifying table structure etc..
I was wondering if anyone can help me with this issue? I am calling a sproc in SSIS. All I want it to do is create a file if any new records are updated or inserted into a table. That table checks another source table to see if anything changed in that table and then adds it to the copy table, if there are any updates or changes to the source table I want a file to get created and if not we don't want it to do anything.
I have tested the logic and everything seems to work fine but once I try to run the sproc in SSIS it gives the error message, "A rowset based on the SQL command was not returned by the OLE DB provider." Initially I thought this means that it is erroring out because no rows are being returned but even when there are rows being returned I still get the very same error message. I can parse the query and preview the results in SSIS but it still turns red when run and gives that error message.
Below is the code to my sproc. Any help or ideas would be so appreciated!
USE [dev02]
GO
/****** Object: StoredProcedure [dbo].[usp_VoidReasons] Script Date: 8/25/2016 11:54:44 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
/*-------------------------------------------------------------------------- ----
Author: Andrej Friedman
Create date: 07/27/2016
Description: This sproc assists SSIS in creating a file but only when a new row has been added to the VoidReasonsLookup table
that didnt exist there before or if the code or description has changed in that table. The table is compared to the prod1.dbo.miscde
table for diferences and only for the Void Reasons of that table (mcmspf = 'cv').
History:
SampleCall: EXEC [dbo].[usp_VoidReasons]
--truncate table dev02.dbo.VoidReasonsLookup
--select * from dbo.VoidReasonsLookup
--update VoidReasonsLookup set Description = 'BB' where Description = 'BENEFIT CODE ADJUSTMENT'
------------------------------------------------------------------------------*/
ALTER proc [dbo].[usp_VoidReasons]
as
declare #ImportDate as date = CONVERT (date, GETDATE())
insert into VoidReasonsLookup (Code, [Description])
--Change #1 -- New Code and Description
--This will insert a new row in the VoidReasons table where the Code and description doesnt exist there but exists in the source table.
select (M.mcmscd_1 + M.mcmscd_4) as Code, mcmsds as [Description] from prod1.dbo.miscde M
left join VoidReasonsLookup VL
on M.mcmscd_1 + M.mcmscd_4 = VL.Code
where M.mcmspf = 'cv'
and VL.Code is null
--Change #2 -- Code dropped off source table so we need it gone from the VoidReasons table
--This will delete rows where the Code doesnt exists in the source table any longer
delete from VL from VoidReasonsLookup as VL
left join prod1.dbo.miscde as M
on VL.Code = M.mcmscd_1 + M.mcmscd_4
where M.mcmscd_1 + M.mcmscd_4 is null
--Change #3 -- Description has changed for a certain code in the source table.
--This will update the Description to the source table if it is different in the VoidReasons table and update the ImportDate to today when that update took place.
update VL
set VL.[Description] = M.mcmsds,
VL.ImportDate = #ImportDate
from dbo.VoidReasonsLookup as VL
join prod1.dbo.miscde as M
on VL.Code = M.mcmscd_1 + M.mcmscd_4
where VL.[Description] <> M.mcmsds
and M.mcmspf = 'cv'
--This will give back everything in the VoidReasons table but only if todays date is the same as the ImportDate column of the table.
--This will mean that today a record was inserted or updated.
If exists(select ImportDate from VoidReasonsLookup
where ImportDate = #ImportDate)
select * from VoidReasonsLookup
else
print 'no changes detected in VoidReasons table'
Add SET NOCOUNT ON and at the end you are selecting resultset basedon condition, SSIS expects resultset always based on output type which you configured. You can use empty resultset as an output will solve the problem
Comment out everything, rerun and see if you still get the error. Uncomment parts until you get the error. Once you get the error, you know what is causing the issue.
I have a a number of sp's that create a temporary table #TempData with various fields. Within these sp's I call some processing sp that operates on #TempData. Temp data processing depends on sp input parameters. SP code is:
CREATE PROCEDURE [dbo].[tempdata_proc]
#ID int,
#NeedAvg tinyint = 0
AS
BEGIN
SET NOCOUNT ON;
if #NeedAvg = 1
Update #TempData set AvgValue = 1
Update #TempData set Value = -1;
END
Then, this sp is called in outer sp with the following code:
USE [BN]
--GO
--DBCC FREEPROCCACHE;
GO
Create table #TempData
(
tele_time datetime
, Value float
--, AvgValue float
)
Create clustered index IXTemp on #TempData(tele_time);
insert into #TempData(tele_time, Value ) values( GETDATE(), 50 ); --sample data
declare
#ID int,
#UpdAvg int;
select
#ID = 1000,
#UpdAvg = 1
;
Exec dbo.tempdata_proc #ID, #UpdAvg ;
select * from #TempData;
drop table #TempData
This code throws an error: Msg 207, Level 16, State 1, Procedure tempdata_proc, Line 8: Invalid column name "AvgValue".
But if only I uncomment declaration AvgValue float - everything works OK.
The question: is there any workaround letting the stored proc code remain the same and providing a tip to the optimizer - skip this because AvgValue column will not be used by the sp due to params passed.
Dynamic SQL is not a welcomed solution BTW. Using alternative to #TempData tablename is undesireable solution according to existing tsql code (huge modifications necessary for that).
Tried SET FMTONLY, tempdb.tempdb.sys.columns, try-catch wrapping without any success.
The way that stored procedures are processed is split into two parts - one part, checking for syntactical correctness, is performed at the time that the stored procedure is created or altered. The remaining part of compilation is deferred until the point in time at which the store procedure is executed. This is referred to as Deferred Name Resolution and allows a stored procedure to include references to tables (not just limited to temp tables) that do not exist at the point in time that the procedure is created.
Unfortunately, when it comes to the point in time that the procedure is executed, it needs to be able to compile all of the individual statements, and it's at this time that it will discover that the table exists but that the column doesn't - and so at this time, it will generate an error and refuse to run the procedure.
The T-SQL language is unfortunately a very simplistic compiler, and doesn't take runtime control flow into account when attempting to perform the compilation. It doesn't analyse the control flow or attempt to defer the compilation in conditional paths - it just fails the compilation because the column doesn't (at this time) exist.
Unfortunately, there aren't any mechanisms built in to SQL Server to control this behaviour - this is the behaviour you get, and anything that addresses it is going to be perceived as a workaround - as evidenced already by the (valid) suggestions in the comments - the two main ways to deal with it are to use dynamic SQL or to ensure that the temp table always contains all columns required.
One way to workaround your concerns about maintenance if you go down the "all uses of the temp table should have all columns" is to move the column definitions into a separate stored procedure, that can then augment the temporary table with all of the required columns - something like:
create procedure S_TT_Init
as
alter table #TT add Column1 int not null
alter table #TT add Column2 varchar(9) null
go
create procedure S_TT_Consumer
as
insert into #TT(Column1,Column2) values (9,'abc')
go
create procedure S_TT_User
as
create table #TT (tmp int null)
exec S_TT_Init
insert into #TT(Column1) values (8)
exec S_TT_Consumer
select Column1 from #TT
go
exec S_TT_User
Which produces the output 8 and 9. You'd put your temp table definition in S_TT_Init, S_TT_Consumer is the inner query that multiple stored procedures call, and S_TT_User is an example of one such stored procedure.
Create the table with the column initially. If you're populating the TEMP table with SPROC output just make it an IDENTITY INT (1,1) so the columns line up with your output.
Then drop the column and re-add it as the appropriate data type later on in the SPROC.
The only (or maybe best) way i can thing off beyond dynamic SQL is using checks for database structure.
if exists (Select 1 From tempdb.sys.columns Where object_id=OBJECT_ID('tempdb.dbo.#TTT') and name = 'AvgValue')
begin
--do something AvgValue related
end
maybe create a simple function that takes table name and column or only column if its always #TempTable and retursn 1/0 if the column exists, would be useful in the long run i think
if dbo.TempTableHasField('AvgValue')=1
begin
-- do something AvgValue related
end
EDIT1: Dang, you are right, sorry about that, i was sure i had ... this.... :( let me thing a bit more