I need to dump a software to a clients server. The problem is that my software is using SQL server 2008 and the client is using SQL Server 2000. So could anyone please suggest how I can make the clients SQL server 2000 compatible with my queries of SQL server 2008?
Thanks for the suggestion
But my concern is that software is already developed with SQL server 2008, then is there any way to use it with SQL server 2000?
You should have developed your software against SQL 2000, or demanded your client upgrade to at least 2005. Did
you ask the client which version you would deploy to before starting development? That is part of standard requirements gathering.
SQL 2008 queries may or may not be compatible with SQL 2000 due to
many new features in 2005 and 2008. There is no shortcut.
At best, make sure to use SQL 2000 documentation from MSDN when writing queries. Use the lowest common denominator.
If you are supporting a product that must deploy to multiple SQL Server versions, you may consider using an ORM that supports SQL 2000. Checkout the Nuget gallery of ORMs: http://staging.nuget.org/packages?q=Tags%3A%22ORM%22 - I believe something simple like Dapper supports 2000.
At minimum you should set your SQL 2008 compatibility level down to 2000 during development.
http://msdn.microsoft.com/en-us/library/bb510680.aspx
ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = 80
I recommend you setup a virtual machine, install the older OS that your client uses as well as SQL Server 2000. Otherwise there are unforeseeable differences.
Related
During our development cycle we create migration-scripts that will be executed on multiple Microsoft SQL Server instances (on different servers).
Since these servers are being maintained by multiple third parties, we can't guarantee that all of them are using the latest Microsoft SQL Server version. For example, some of them are still stuck on 2008 R2.
Unfortunatly, this means that our SQL scripts must at least be compatible with 2008 R2 (and higher).
We would like to add an extra step to our build process (currently driven by MSbuild), which should check if all scripts are compatible with all versions of SQL Server that we should support (2008 R2 and higher). Both in terms of their syntax, but also in terms of built in functions (as an example, the CONCAT-function was only added in 2012).
However, we want to avoid having to install each supported SQL Server version and instead use only SQL Server 2017.
Note:
I've had a look at compatibility modes in SQL Server, but when I set the compatibility level to 100, I seem to still be able to use SQL Server 2012 features like the CONCAT-function. Which doesn't surprise me, as I expect this to be intended for backward compatibility, rather than blocking features.
These similar questions didn't really help either: Using SQL Server Express 2008 with SQL Server 2005 database -how to check for compatibility, How to check sql script compatibility agains SQL 2008
Are there any other options?
I want to setup mirroring between 2 copies of SQL server. The primary box is SQL server enterprise edition.
Can I mirror it to a SQL server standard edition? The purpose is to save a metric ton of money.
From Books Online:
The two partners, that is the principal server and mirror server, must be running the same edition of SQL Server. The witness, if any, can run on any edition of SQL Server that supports database mirroring.
That being said, it is possible to set it up as long as you use TSQL commands and not the GUI. I would never recommend it, but it is possible, as long as you guarantee you're not using any Enterprise features. More warnings HERE and HERE.
Last edit - apparently this has been completely blocked in SQL 2012. Looks like you're out of luck.
Does the current iteration of fluentmigrator work with SQL Server 2012? Its not listed under the supported databases.
There is no official support for Sql Server 2012 yet. But it should work if you specify SqlServer2008 as the database type. The differences between Sql Server 2005, 2008 and 2012 are not so significant when using FluentMigrator (Sql Server 2000 is a different story). Some features like the new sequence object have no support so in the meantime will have to be run using Execute.Sql.
UPDATE: I tested FluentMigrator against Sql Server 2012 Express with database type specified as SqlServer2008 and it worked fine.
UPDATE: FluentMigrator now officially supports Sql Server 2012 and Sequences.
A database that was originally from SQL Server 2008, was restored into SQL Server 2012. A backup from SQL Server 2012 was made and I am trying to restore it on my local SQL Server 2008 Express. However I get an error 'Specified cast is not valid' (SQLManagerUI).
I have generated an SQL Script from 2012 and set it so that it will generate with compatibility to SQL Server 2008. However it is a large sql file, around 700mb.
I recall before that I had tried to run a script of that size before on my local SQLExpress and also got an error.
Is there a way I can get a "large" database from SQL Server 2012 into SQL Server 2008 Express?
Thanks to Marc and Aaron for providing the answers.
The quick answer is no, it's not possible to restore a backup file from a higher version to a lower version of SQL Server.
A work around would be to generate the scripts to create the database.
You can target the script generation to a lower version.
Please see comments above for more information.
Links:
Why an SQL Server Database from a higher version cannot be restored onto a lower version of SQL Server?
Create Database in SQL Server 2012, Script and Use in 2008?
Couple things to add that might be helpful to folks
When scripting large databases using scripting wizard in SSMS it’s really important to check the execution order and be willing to re arrange it manually. Older versions of SSMS had this problem because they (probably) relied on sp_depends that has a bug.
What I’ve found really useful in such cases are tools like ApexSQL Diff that you can use to read database backups and generate scripts that are in correct execution order.
SQL Server database backup restore on lower version
One thing that none of the methods will catch is the thing Aaron mentioned about using functions specific to higher version.
A better option than using the SSMS scripting wizard is to use a similar tool available on Codeplex called SQL Database Migration Wizard - http://sqlazuremw.codeplex.com/releases/view/32334. You want the latest version v4.x to work with SQL Server 2012.
The tool is originally intended to be used for migrating databases between SQL Server and Azure. However the tool works just as well as between SQL Server and SQL Server. The trick is to set SQL Server rather than Azure as the target in the advanced options.
The reason this is a better option than the SSMS scripting wizard is that it uses BCP for the data transfer rather than TSQL and so is much more efficient.
I'll be starting a new project (asp.net) and I'll be using sql server express. Is there a reason NOT to use sql server 2008?
P.S: I was considering Postgres 8.3 until I did some benchmarking and found out that sql server 2005 express is much faster for my needs (better integration I guess).
If the choice is between SQL Server 2005 and SQL Server 2008 with no legacy compatibility issues, you should probably go with SQL Server 2008. The jump from 2005-2008 is much smaller than the jump from 2000-2005 was and you get three years extra lifespan for your application for free. A similar question was asked in this Stackoverflow post, with a more in-depth discussion of the subject.
A reason you might not have considered: will the production hosting location support SQL Server 2008?
Otherwise there's no reason. In fact, if your still stuck using SQL Server 2005, you should be using the 2008 version of management studio! which still works against older db's
I'd prefer Sql Server 2008 because there are too many "killer" enhancements like table valued parameters, merge statement, on the fly encryption, new datetime parameters etc. Table valued parameter is a life saver improvement. If you ever had to deal with multi row insert operations, you know how painful is to do it with xml nodes or openxml methods. On the other hand, you can pass your recursive datatable as a parameter ( SqlDbType.Structured ) and the pain is gone. It's so obvious that the most exciting feature for me is new table valued parameter.
As a sidenote: DiscountASP is selling, for the same price, 300Mb on SQL2005 and 500Mb on SQL2008. So it turns out that SQL2005 is on a statup path to be considered "old legacy" software.
And it is always good to skip future migrations.
I would go with SQL2008.
I am currently using SQL Server 2008 Express for my dev machine. You could use the new T-SQL and save some good time writing those stored procedures. I have this version of SQL Server 2008 Express installed.
It depends on a lot of factors:
Will you sell installable copies to customers? If so, what kind of database engines does your customer demography have? 2000? 2005? 2008?
Are you going to host it yourself? If so, use whatever you'd like
Are you going to use a 3rd party hosting company? If so, what do they support, and how much does it cost?
Unless you're explicitly going to use 2008 features, I wouldn't worry too much about it since generic T-SQL works on all the versions. It's when you start using the new features you might get into trouble.
Update: It seems that they DO allow sql server 2008 (sales people aren't very good at technical stuff) so I'll be using sql server 2008.
Well I asked my host (I have a vps) and they allow only sql server 2005 express, not sql server 2008 express (which is kinda strange). So I'll go with 2005 for now... Thank you all for your opinions.