Archive
SQL Error – Logical file ‘XYZ_Log2’ is not part of database ‘XYZ’. Use RESTORE FILELISTONLY to list the logical file names.
I was restoring Databases as a routine monthly job. Suddenly in between I came across an error which didn’t let me restore a Database. I restored other Databases and left this one to do at the end. Finally I picked it up again and saw that some new kind of error I was facing. The error message says to use “RESTORE FILELISTONLY”, I check the syntax on MSDN and found that this Database had two log files (LDF) earlier, but now configured for only one. And as I was using the same old script to Restore it, I was getting this error.
Let’s try to reproduce it in a standalone box:
–> I took a backup of AdventureWorks2012 Database on my machine.
I created the RESTORE script and added another line of log file at line 8 below:
USE [master] GO RESTORE DATABASE [AdventureWorks2012] FROM DISK = N'E:\Softwares\MS_bits\AdventureWorks2012.bak' WITH FILE = 1, MOVE N'AdventureWorks2012_Data' TO N'E:\MSSQL11\DATA\AdventureWorks2012_Data.mdf', MOVE N'AdventureWorks2012_Log' TO N'E:\MSSQL11\Log\AdventureWorks2012_Log.ldf', MOVE N'AdventureWorks2012_Log2' TO N'E:\MSSQL11\Log\AdventureWorks2012_Log2.ldf', NOUNLOAD, REPLACE, NOUNLOAD, STATS = 5 GO
On executing I got an error as expected, shown below:
Msg 3234, Level 16, State 2, Line 1
Logical file ‘AdventureWorks2012_Log2’ is not part of database ‘AdventureWorks2012’. Use RESTORE FILELISTONLY to list the logical file names.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
As suggested in the Error Message, I used the “RESTORE FILELISTONLY” command to check what all files this Database is using:
RESTORE FILELISTONLY from disk=N'E:\Softwares\MS_bits\AdventureWorks2012.bak'
And I could see only two, one MDF & one LDF, as shown below:
LogicalName PhysicalName Type FileGroupName AdventureWorks2012_Data E:\MSSQL11\DATA\AdventureWorks2012_Data.mdf D PRIMARY AdventureWorks2012_Log E:\MSSQL11\Log\AdventureWorks2012_log.ldf L NULL
So, I removed the extra LDF log file option from the RESTORE script, as shown below:
RESTORE DATABASE [AdventureWorks2012x] FROM DISK = N'E:\Softwares\MS_bits\AdventureWorks2012.bak' WITH FILE = 1, MOVE N'AdventureWorks2012_Data' TO N'E:\MSSQL11\DATA\AdventureWorks2012_Data.mdf', MOVE N'AdventureWorks2012_Log' TO N'E:\MSSQL11\Log\AdventureWorks2012_Log.ldf', --MOVE N'AdventureWorks2012_Log2' TO N'E:\MSSQL11\Log\AdventureWorks2012_Log2.ldf', NOUNLOAD, REPLACE, NOUNLOAD, STATS = 5 GO
The above statement executed fine and the Database restored successfully.
So, I learnt a new thing here about the “RESTORE FILELISTONLY” command. This command tell us what all Database files (MDF, NDF, LDF) a Backup file contains without actually Restoring the Database.
SQL Server 2012 | Temp Tables are created with negative Object IDs
These days I’m working on SQL Server upgrade from 2008 R2 to 2012 for one of our project module.
Today while working on it I got blocked while installing a Build. The build was failing with following error:
Error SQL72014: .Net SqlClient Data Provider: Msg 2714, Level 16, State 6, Line 115 There is already an object named ‘#temp’ in the database.
I checked the code and found the line where it was failing:
IF object_id('tempdb.dbo.#temp') > 0
DROP TABLE #temp
I checked this code with SQL Server 2008 R2 and it was working perfectly.
So to check and validate this I created a temp-table on SQL Server 2012 and found that it is created by negative Object ID, check this:

This is a new change done with SQL 2012 version, but this is not mentioned anywhere in MSDN BOL.
So, to make this legacy code work we have to re-factor all such cases, by:
IF object_id('tempdb.dbo.#temp') IS NOT NULL
DROP TABLE #temp
Confirmation form Microsoft SQL team blog [CSS SQL Server Engineers]:
“in SQL Server 2012, we made a conscious change to the algorithm so that objectids for user-defined temporary tables would be a particular range of values. Most of the time we use hex arithmetic to define these ranges and for this new algorithm these hex values spill into a specific set of negative numbers for object_id, which is a signed integer or LONG type. So in SQL Server 2012, you will now always see object_id values < 0 for user-defined temp tables when looking at a catalog view like sys.objects.”
More Info on: http://blogs.msdn.com/b/psssql/archive/2012/09/09/revisiting-inside-tempdb.aspx
SQL Error – Heterogeneous queries require the ANSI_NULLS and ANSI_WARNINGS…
Msg 7405, Level 16, State 1, Line 1
Heterogeneous queries require the ANSI_NULLS and ANSI_WARNINGS options to be set for the connection. This ensures consistent query semantics. Enable these options and then reissue your query.
I came through this strange and new error message while our team was deploying build on one of the servers. After debugging and reviewing the code we find the problem which was in one of the hundreds of stored procedures.
The scenario was:
– A stored procedure that uses Linked Server to pull record-set from another SQL Server database.
– Pull records and load this result set on a temp-table.
– For implementing the business logic and to do some calculations the query uses some aggregate functions, like SUM(), MIN(), MAX() on a few columns in that temp table.
Here if any of these aggregated column contain NULL values, it results in an obvious Warning message (not Error), i.e.: Warning: Null value is eliminated by an aggregate or other SET operation.
We could ignore this warning message, but when used in SSIS packages it causes the package to fail. So to avoid this Warning message, “SET ANSI_WARNINGS OFF” option was set at the beginning of the stored procedure.
The stored procedure compiled fine, but when we executed it, it resulted into this strange error: “Heterogeneous queries require the ANSI_NULLS and ANSI_WARNINGS…”.
We observed that this error is due to setting ANSI_WARNINGS to OFF just before the linked server call. So the workaround was to shift the “SET ANSI_WARNINGS OFF” statement just below the linked server call. And to be on the safer side applied the “SET ANSI_WARNINGS ON” statement at the end of the stored procedure.
MSDN Forum links:
http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/1d501b57-fc58-4fbe-9bec-6c38ad158a62
http://social.msdn.microsoft.com/Forums/en-US/vstsdb/thread/03cab0c7-9e2b-459a-8ffd-21616ac5c465/
http://social.msdn.microsoft.com/Forums/en-IE/vstsdb/thread/67d2b3d2-e0fd-4669-a2e9-ca79c894b8d2
MS KB article regarding this issue: http://support.microsoft.com/kb/296769
SQL Error – UPDATE statement conflicted with the FOREIGN KEY/REFERENCE constraint
Just replied on MSDN forum’s following post: http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/289c4ca5-6ab2-4ed6-b446-0300f5c7dc88
When tables are referenced by Foreign Key constraints it gets difficult to UPDATE the key columns.
An example shows this issue and how one can perform UPDATE on FK columns.
USE [tempdb] GO -- CREATE test tables CREATE TABLE dept (d_id INT PRIMARY KEY, dept VARCHAR(50)) CREATE TABLE emp (sn INT PRIMARY KEY, ename VARCHAR(50), d_fk INT CONSTRAINT fk_dept_d_fk FOREIGN KEY (d_fk) REFERENCES dept(d_id)) -- INSERT test data INSERT INTO dept SELECT 1, 'finance' UNION SELECT 2, 'hr' INSERT INTO emp SELECT 1, 'Manoj', 1 UNION SELECT 2, 'Saurabh', 2 UNION SELECT 3, 'Kanchan', 1 UNION SELECT 4, 'Pooja', 2 -- SELECT the INSERTed data SELECT * from dept
d_id dept
1 finance
2 hr -- DeptID needs to be updated to 3
SELECT * from emp
sn ename d_fk
1 Manoj 1
2 Saurabh 2 -- DeptID should also be updated here to 3
3 Kanchan 1
4 Pooja 2 -- DeptID should also be updated here to 3
-- Now lets UPDATE the FK column values UPDATE dept SET d_id=3 WHERE d_id=2
Error Message:
Msg 547, Level 16, State 0, Line 1
The UPDATE statement conflicted with the REFERENCE constraint "fk_dept_d_fk".
The conflict occurred in database "tempdb", table "dbo.emp", column 'd_fk'.
The statement has been terminated.
UPDATE emp SET d_fk=3 WHERE d_fk=2
Error Message:
Msg 547, Level 16, State 0, Line 1
The UPDATE statement conflicted with the FOREIGN KEY constraint "fk_dept_d_fk".
The conflict occurred in database "tempdb", table "dbo.dept", column 'd_id'.
The statement has been terminated.
We can disable the FK constraints by ALTER statement before the UPDATE and enable them after the UPDATE, like:
-- Disable FK Constraint ALTER TABLE emp NOCHECK CONSTRAINT fk_dept_d_fk -- Perform UPDATE UPDATE dept SET d_id=3 WHERE d_id=2 UPDATE emp SET d_fk=3 WHERE d_fk=2 -- Enable FK Constraint ALTER TABLE emp WITH CHECK CHECK CONSTRAINT fk_dept_d_fk -- Following SELECTS will show the new values in updated records: SELECT * from dept
d_id dept
1 finance
3 hr -- Updated record
SELECT * from emp
sn ename d_fk
1 Manoj 1
2 Saurabh 3 -- Updated record
3 Kanchan 1
4 Pooja 3 -- Updated record
-- Final Cleanup, DROP the tables. DROP TABLE emp DROP TABLE dept
MSDN BOL: http://msdn.microsoft.com/en-us/library/10cetyt6(v=VS.80).aspx





