Reading official docs about STRING_SPLIT function, at the begining of the doc there is a note:
Note
The STRING_SPLIT function is available only under compatibility level
130 and above. If your database compatibility level is lower than 130,
SQL Server will not be able to find and execute STRING_SPLIT function.
To change the compatibility level of a database, refer to View or
Change the Compatibility Level of a Database. Note that compatibility
level 120 might be default even in new Azure SQL Database.
So, what does compatibility level mean?
Compatibility Level refers to the way SQL Server operates in relation to a specific version of SQL Server.
Let's say for example, you have an application running well on SQL Server 2012, but you need to upgrade to SQL Server 2019 because support is ending soon. Everything runs great on SQL Server 2012 and the application has not been updated in many years. So, it's unclear how it might perform running on SQL Server 2019, or if it'll even work at all.
To ease the transition when you migrate to SQL Server 2019, you could consider leaving the database in SQL Server 2012 compatibility level, to avoid any unforeseen performance issues that may be introduced by the way the SQL engine and optimizer work in SQL Server 2019. Essentially, to the application, it's as if you're still running SQL Server 2012.
Now, the downside is that you can also not take advantage of the newer features that have been introduced since SQL Server 2012, such as STRING_SPLIT.
Related
We are updating several SQL Server 2008R2 instances to SQL Server 2012 SP3 CU2. I know that the database versions will be changed from 100 to 110 during this process (e.g. once finished, the databases can no longer be moved back to a 2008R2 instance).
Does this change to the databases occur during the upgrade itself or the first time that the databases are brought online when the server restarts?
SQL server keeps track of version in two ways. First, your SQL Server instance has a version (for example SQL Server 2008 R2 is 10, followed by some decimals to keep track of patches).
Your databases are a separate version, known as a Compatibility Level. If you upgrade your instance, your databases will not be upgraded until you choose to do so. That does not mean there will not be an impact, however it does mean those databases can remain in their old version. Your example of 100 and 110 are both Compatibility Level.
Please see changing Compatibility on MSDN here: https://msdn.microsoft.com/en-us/library/bb510680.aspx
Has anyone here moved the database underlying a SP 2010 install from one database instance to another (same data, just hosted in another instance)?
For example. we just want to move the database to a diffrerent machine.
In addition, has anyone moved SP 2010 from using SQL Express to a higher version of SQL Server? I would like to run some proof of concept tests with SQL Express, and if all goes well, then move to SQL Standard or Enterprise.
Cheers,
Daniel
Check out the following article:
http://technet.microsoft.com/en-us/library/cc512725.aspx
I don't think you'll run into any problems, just make sure you aren't going backwards in versions between databases. Backing up a database in SQL Server 2008 and restoring in 2005 isn't easy.
I've never done this with SharePoint, but I believe it lets you specify the location of the configuration database. Then you just need to match the user permissions.
The TechNet article "Move All Databases (SharePoint 2010)" is your main guide.
Note that this article contains the following warning:
The new database server must be running the same version of Windows
Server and Microsoft SQL Server as the existing database server.
This in NOT true!
Both from my own experience in migrating SharePoint databases and talks I've had with Microsoft Primary Field Engineering, I can say this method also works when SQL Server versions differ. But only if you upgrade to higher SQL Server versions (i.e. SQL Server 2005 to SQL Server 2008 R2). I was told this scenario is also fully supported by Microsoft.
Also, don't forget to update the database compatibility level for the migrated databases. This should future-proof your databases and enable advanced SQL Server optimization.
I have a database which was upgraded from 2000 to 2005. Is there any issue using sp_dbcmptlevel to change compatibility level to 90. Will this cause any issues with old queries or stored procedures
Did you run the SQL Server upgrade adviser on the old database? It will tell you if there is any obvious problems. Be sure to test on a development database.
Here is the tool
http://www.microsoft.com/downloads/details.aspx?FamilyID=1470e86b-7e05-4322-a677-95ab44f12d75&displaylang=en
I recently changed my compatibility mode of my sql server 2005 form 2000 to 2005.
Is there a utility that can scan my sp and functions and tell me if I have any compatibility issues?
I am not sure if it works from inside sql 2005; but if you still have a sql 2000 server then MS have an upgrade advisor that will report on your code. If you don't scripting out all the objects and trying to run them back into a new database set as sql 2005 mode is a fairly good way to test the migration.
Depending on your application be careful just switching there are syntax differences and connection options that changed between 2000/5 beyond just stored procedure changes. If your application runs sql queries natively (not sp's) then the application may have compatibility issues beyond just the internal database code.
I am using SQL Server 2008 express edition but I want to make my databases still in 2005. How can I set it up to only show features that a 2005 database can use?
Like for instance I don't remember there being a "date" type. I only remember "dateTime".
I don't want to be using features that 2005 can't support and I later on upload my db to the my hosting site that uses 2005 still and find out I am using things not supported by it.
You won't be able to upload the database, just a script of it. Even when in 90 compatibility mode, the physical structure of the database will be the 2008 one and the hosting site won't be able to load it.
Note that the compatibility level does not necessarily mean that the new features of SQL 2008 are not available, but instead it simply means that (some) features that existed in 2005 will work the same way in 2008. The complete list of compatibility mode changes is on MSDN. In particular there is nothing to prevent the usage of a datetime2, date, time or any new time in a database set at compatibility level 90. In fact such would be impossible simply because the the compatibility level can be changed after a table is created.
You are going to either develop against a SQL 2k5 instance, or read the product manual and learn what features are available in what version.