I understood that setting a database to a COMPATIBILITY_LEVEL prior to your native one prevented features from being used. However this doesn't seem to be the case. Witness the following SQL script:
CREATE DATABASE Foo
GO
USE Foo
GO
ALTER DATABASE Foo SET COMPATIBILITY_LEVEL = 80
GO
CREATE TABLE Bar
(
Id UNIQUEIDENTIFIER NOT NULL,
TestNvcMax NVARCHAR (MAX) NOT NULL, -- Arrived in SQL 2005
TestDateTime2 DATETIME2 (7) NOT NULL -- Arrived in SQL 2008
)
GO
But this table creates perfectly - any ideas? I would have thought some kind of an error message or warning would have been appropriate
Here you can read about the differences between compatibility level 80, 90 and 100. ALTER DATABASE Compatibility Level
Apparently new data types is not affected. I think that compatibility level is there to make SQL Server "behave" like the older version, not prevent you from doing new fancy stuff.
BOL says:
Compatibility level provides only
partial backward compatibility with
earlier versions of SQL Server.
Also:
New functionality might work under
older compatibility levels, but SET
options might require adjustments.
I believe that is your case.
I understand this is an old post, but for anyone else who ends up here as I did, more information is always helpful.
It could also be that the new compatibility did not take effect before running the create table statement.
"The new compatibility setting for a database takes effect when a USE Database is issued or a new login is processed with that database as the default database."
(https://msdn.microsoft.com/en-us/library/bb510680.aspx)
Related
I regularly end up developing on projects where either the Central Test server, or Prod server is an older version of SQL Server than my local install.
e.g. Prod is SQL Server 2014. Local install in SQL Server 2019.
Mostly that's fine, it just means I have to remember to only use old syntaxes. (:cry:)
But occasionally I forget which syntaxes are old. Ooops.
Obviously our test environments catch this, but it would be great to be able to tell my Local Server ... "only accept SS2014 syntax", and have these mistakes caught before they're committed/pushed.
I thought this was what CompatibilityLevel was supposed to do. But either it doesn't, or I'm using it wrong. (See below)
How should I achieve this? (other than just installing a different SQL version!)
Attempt so far:
Run ALTER DATABASE MyLocalProjectDB SET COMPATIBILITY_LEVEL = 120; (120 represents SS2014)
Run SELECT name, compatibility_level FROM sys.databases WHERE name = db_name(); to confirm that the previous command "worked".
Run DROP TABLE IF EXISTS [ATableThatDoesExist], to see if the syntax is accepted. It was.
DROP IF EXISTS was new to SS2016:
MSDN: IF EXISTS ... Applies to: SQL Server ( SQL Server 2016 (13.x) through current version).
Additional Source
Why hasn't this worked?
I recently restored a SQL Server 2008 database into an instance of SQL Server 2016. Most of the functionality seems to work fine, but many of my stored procedures that include updates to an application database table called SYS_USER fails with the following error:
Msg 102, Level 15, State 1, Procedure SYS_USERupdate, Line 35 [Batch Start Line 0]
Incorrect Syntax near '#errorNumber'
The database does not have a stored procedure called SYS_Userupdate and none of the procedures' code includes the term #errorNumber. I attempted to run the SQL query from one of the failing procedures directly in SQL Server Management Studio and received the same error message. Here is the SQL query that is failing:
UPDATE SYS_USER
SET SYS_USER_LGF_DT = GETDATE()
WHERE SYS_USER_ID = #SYS_USER_ID
I plugged in a valid value for the #SYS_USER_ID variable. Similar queries in related to other tables run without an issue. All of the stored procedures work on a SQL Server 2008 instance with no errors. Also, the database compatibility_level to 100, which should be acceptable for SQL Server 2016.
This happens when you're not running on a correct version of SQL Server, or if the compatibility level of the database isn't set sufficiently. So change it to 130
To check compatibility level:
select compatibility_level
from sys.databases
where name = '<database name>'
To alter compatibility level:
alter database <database-name>
set compatibility level = 130 -- SQL Server 2016
Compatibility levels list for all SQL versions: ALTER DATABASE (Transact-SQL) Compatibility Level
Reposting the answer since it was proposed in a comment to the question. The solution to the problem was that there were triggers on the affected tables that I did not know were there. Syntax errors on these triggers were causing insert and update queries on the tables to fail.
Credit to Jeroen Mostert https://stackoverflow.com/users/4137916/jeroen-mostert for helping with this!
I am trying to restore a SQL Server 2014 database in SQL Server 2005. I am doing by generating the complete script (with schema and data) from SQL Server 2014.
I get an error saying
'INSERT failed because the following SET options have incorrect settings: 'ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or query notifications and/or xml data type methods.'
and
'Cannot insert explicit value for identity column in table 'T_GASAdminNote' when IDENTITY_INSERT is set to OFF.'
I have searched for solution but have not been able to rectify the problem. I have tried the solution given in this link, but it didn't help me.
Can anyone suggest me some solutions for restoring the database.
Update: sorry - misread your question...
The first error means just that - for some operation you're trying to do, your SET ANSI_PADDING setting is wrong. Read the official documentation on ANSI_PADDING on MSDN to learn more about this setting. Check what your setting is now - obviously, if that error occurs, you need the other setting for that operation you're attempting to do.
The second error means that your table T_GASAdminNote has an identity column, and you're trying to insert values into that column, but without first enabling this by using SET IDENTITY_INSERT T_GASAdminNote ON (and don't forget to disable the option after you're done!)
Ok, i know CONCAT_NULL_YIELDS_NULL will always be set to ON in future versions of SQL (insert MSDN search params(yadda,yadda)) so bear with me.
Boring details: The platform is MSSQL 2000 Enterprise (v8 sp4) AKA Critatious Period Edition.
The following will evaluate to NULL
SELECT 'abc' + NULL;
Understandable. But you can circumvent this with the following:
SET CONCAT_NULL_YIELDS_NULL OFF;
SELECT 'abc' + NULL;
In which case the result is "abc". From here on, future sql statements will allow concatenation with NULL. But is this a 'persistent' runtime setting? Such as, is this setting only applied for my session to the SQL server, or does it apply to statements executed by all users?
As far as i can tell, after setting _YIELDS_NULL to ON, a restart to the MSSQL services will have it default back to OFF (correct me if i'm wrong).
Last thing: I'm not actually planning to put this into practice. A third-party stored procedure failed (looks like they might have updated it, breaking it). Best i can figure is that they implemented it with the assumption that "SET CONCAT_NULL_YIELDS_NULL" was set to ON. And it used to always work.
I'm just looking for a cause: Is there a way to have CONCAT_NULL_YIELDS_NULL set to ON upon SQL server startup?
CONCAT_NULL_YIELDS_NULL can be set:
per connection - when you close connection and open new, it's back to default
per database
open Microsoft SQL Server Management Studio, rightclick your database and select properties. It's in the Miscellaneous section.
or from T-SQL
ALTER DATABASE database_name SET { CONCAT_NULL_YIELDS_NULL OFF }
Note: some clients can issue set concat_null_yields_null on command when opening connection. For example SQL Server Management Studio connecting to SQL 2005 does.
Use SQL Server Profiller to find about your connection.
I do not have SQL 2000 on my notebook to test exactly on that version.
As BOL goes,
If a SET statement is set in a stored
procedure, the value of the SET option
is restored after control is returned
from the stored procedure.
Therefore, the developer has very little to do to ensure correct settings. They could just set them in the beginning of the SP and didn't even have to restore original values afterwards.
I have a weird problem here.
In short to the environment we have:
There is a (newly set up) Win2003 Server with a SQL Server 2005 Express database. I connect to it via a MS Access application.
Since I switched to the new server (restored a backup from the former server on it) all SPROCs (only in Access) have a ;1 after their name, hence cannot be found.
If I try to open a SPROC in Access (dbl click in overview), it asks for the parameter, then says cannot be found.
If I try to open, say, a report based on it, same result. If I change the name of the SPROC the report is based on to the name shown in the overview ( [sprocnam];1 ) it says "cannot be found" (of course, because the names did not change as one can see in Management Studio).
?!?
keep in mind that the Access-application worked fine with the database that I backed up on another server and restored to the newly set up server ...
Your help is greatly appreciated!
edit: I found a thread on SAP.com with someone experiencing the same problem, but without a solution: https://forums.sdn.sap.com/message.jspa?messageID=7947957
I can't tell why you have got this issue, but in In SQL Server you have the ability to create Numbered stored procedures. The procedures have the same name but may contain completely different code, look at this:
CREATE PROCEDURE [dbo].[spTest]
AS
BEGIN
SELECT ##MICROSOFTVERSION
END
GO
CREATE PROCEDURE [dbo].[spTest];2
AS
SELECT ##version
GO
EXEC spTest;1
EXEC spTest;2
I resolved the issue with an update of the clients office-installation to the latest service pack.
The one employee that notified me of the problem and me got new computers last week, and thus did not have the latest updates.