I have installed SQL 2012 and I must create a application compatibility with SQL 2008. Is any way to check that all scripts that I write are compatibility with SQL 2008 without installing SQL 2008?
I believe that there are two thing that you will need to do to ensure that your app is compatible with SQL Server 2008.
First, the easiest way that I have found to find issues caused by deprecation between versions is to use the sql server profiler tool.
http://www.mssqltips.com/sqlservertip/1370/identifying-deprecated-sql-server-code-with-profiler/ is an excellent introduction into that.
Second, you need to change the compatibility level of the database to the level of SQL Server 2008.
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 90 | 100 | 110 }
So for you that would be ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = 100;
Some things to keep in mind. This will not change the underlying way that sql server executes the query internally, new enhancements to the query optimizer or algebrizer will not be excluded because of the compatibility level. From what I understand this functionality mainly disables language constructs that were not introduced in the version that you are interested in. That being said, it shouldn't make any difference in what you are trying to accomplish.
This is a similar question (with a good answer) regarding 2008 and 2005: Using SQL Server Express 2008 with SQL Server 2005 database -how to check for compatibility
You can find here the complete list of compatibility mode changes: ALTER DATABASE Compatibility Level (Transact-SQL)
Related
When I use MSBuild 4 I can target .NET Framework 3.5 and older versions, and all features available only on the version 4 will not be available on that project.
I would like to do a similar thing in SQL Server 2012. Can I configure a database in it to behave similary to a SQL Server 2008 one? Can I make one database to not accept commands only available to SQL Server 2012?
You can set the Compatability Level within the database properties.
Right Click the Database
Click Properties
Select Options
Choose the Compatability Level
110 = SQL 2012
100 = SQL 2008 & 2008 R2
90 = SQL 2005
This option only affects the behaviour of this particular database, not the entire server. It should be regarded only as partial backwards compatibility. If your intention is for SQL Server to treat this database as a SQL 2008 database, then the best way to do this would be to run it within SQL 2008 rather than SQL 2012.
Here is a very detailed explanation: http://technet.microsoft.com/en-us/library/bb510680(v=sql.110).aspx
T-SQL
ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = { 90 | 100 | 110 }
I'm developing an application that needs to operate against SQL server 2003, 2005, and 2008. I'd like to transition from using T-SQL stored procedures to using Linq, as we currently don't have a database programmer, and thus making any fixes or adding any features is a slow, difficult process. In contrast, working with LinqToSql in other projects has been a breeze.
Will a .dbml file generated against SQLServer 2008 work if used against previous versions of SQL Server, assuming the table structures are the same?
As we already have to support three slightly different database schemas, having to generate a DataContext for each SQL version, along with our additional data layer functionality, would be a showstopper.
SQL Server 2005, 2008: No problems.
SQL Server 2000, 2003: Issues with server side paging (.Skip(), .Take()), but other than that, no.
I am developing on a SQL Server 2005 and hosting the live system on a SQL Server 2008 without any hiccups.
You will experience problems with anything earlier than SQL Server 2005 and LINQ to SQL's implementation of .Skip() if you were ever to use it, as LINQ to SQL translates it to ROW_NUMBER in T-SQL - and this is only a part of SQL Server 2005 and onward.
See this related question: Which versions of SQL Server does LINQ to SQL support?
We got some SQL scripts, some of them are using Syntax like :
Create procedure procABC(...)
as
begin
...
...
'ColA'= CONVERT(smalldatetime(10),ColB,103),
...
...
End
Same kind of syntax we also have for INTEGER like
INTEGER(5)
I know that this kind of syntax is used in MySql to set display width of a column or variable. But In any of the SQL Server version starting from SQL 7 to SQL 2008 this syntax fails.So my question is :
We have got this script from a SQL server machine as a backup, is it possible to have some kind of cached scripts, like we have in ORACLE where script may be invalid but still it will be on the server in invalid mode and will give compilation error if there are any syntax errors..
Is there anyway to achieve same kind of functionality in SQL server as we are supposed to re-create these objects (Something other then SUBSTRING) .
If I understand your additional information correctly, you have a SQL Server 2000 database that was created by some scripts, but the only scripts you have are in MySQL syntax and you're not sure how they are related to the SQL Server database. Your goal is to create a set of scripts that can be used to re-create the SQL Server 2000 database on a SQL Server 2008 system.
First, if that understanding is correct then I would completely forget about the MySQL scripts. They might have some value as documentation if there are useful comments in them, but they are not directly necessary for your task.
Second, I would upgrade your SQL 2000 database to SQL 2008. You can back it up and restore it on a SQL 2008 server, or you can upgrade the entire SQL Server itself from 2000 to 2008.
Third, I would generate the SQL scripts for the database objects using SQL Server Management Studio or the SMO API if you prefer. A Visual Studio database project could also be a good way to manage the scripts.
There is plenty of information on all these tasks on this site, in the SQL Server documentation, on MSDN etc. If you need more help, you should ask more precise questions about what you want to do and what you have tried already.
We're eventually migrating an application to SQL Server 2008, but before we do that, we're considering setting the MySQL SQL modes to be stricter so that we can test the "looseness" of the existing application before it's migrated to the stricter SQL Server 2008.
What are some MySQL SQL modes we can set in order to get it to be more at the strictness level of SQL Server 2008 to help better facilitate the migration eventually?
The best place to start would be the mode
MSSQL
This enables: PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS, NO_AUTO_CREATE_USER
Some others that caught my attention while looking through the list of modes where:
PAD_CHAR_TO_FULL_LENGTH and ONLY_FULL_GROUP_BY
I would also try to import the data into SQLServer 2008 and run queries against both while developing in MySQL.
I have a DBPro database project that was created for Sql 2005. I am trying to build this on a different environment, with Sql 2008, and I am getting the following error:
MSBUILD : Build error TSD158: An unsupported target database version was encountered.
I couldn't find much on this error, and I am unclear what is the conflict. I have tried to change the buildversion element in the database project from 9.0.21022.8 to 10.0.0.0 but that didn't make any difference. I am out of ideas. Any thoughts?
To target SQL Server 2008, don't you need some GDR update? See http://blogs.msdn.com/gertd/archive/2008/11/25/visual-studio-team-system-2008-database-edition-gdr-rtm.aspx
Also, it might be easier to take your database, restore it on SQL Server 2008 (and let the database upgrade the database itself). Then just start a new project where you suck down the schema. But I still think you'll need the GDR in order to do that.