Once your databases are converted from SQL Server 2000 to SQL Server 2005, is there any way to compare DTSs on two servers to see if they are still essentially the same? I need to see if my dev and prod are the same, and comparing them manually is really time consuming.
If they were still in 2000, I could use the Red-Gate tool DTS Compare, but that doesn't work in 2005. I can save each as a Visual Basic file, and then compare those (and that kind of works), but the steps may be output in a different order. Is there something out there that is better?
I would say, don't use DTS jobs in SQL Server 2005.
There are a complete new and reworked method to do those things: SSIS.
Here you find an introduction:
http://www.accelebrate.com/sql_training/ssis_tutorial.htm
Yes, maybe you can't compare it perfectly, but DTS Jobs are run out of support since SQL 2005 (remember, we are in 2009 :) )
Related
I cannot believe this is so difficult. Backup / Restore fails. Import and Export both fail with a variety of silly errors.
Is there a way to do this that works?
Try scripting out the schema and data, with the SQL Server Management Studio
Article explaining how to use SQL Server Management Studio
If that doesn't work, you'll have to use a more advanced third party tool. Like, for instance, Red Gate's Sql Toolbelt, where:
SQL Compare allows you to compare and merge schema between 2 databases
Data Compare allows you to compare and merge data between 2 databases
I have a code which is up and running but the problem that I have is that it includes a lot of MERGE clauses as it was intended to be run from SQL Server 2008 and forward. But the problem is that a new customer is running SQL Server 2005 and as you know the Merge clause is not available till SQL Server 2008, so my question is if there is not a way to parse the this clauses automatically or if there is another solution (apart from rewriting all the clauses in clasical clauses ) as the customer is not willing to upgrade the DB.
Thanks a lot in advance.
I am afraid that you will need to re-write all of your MERGE clauses for SQL Server 2005.
You can use the 2005 friendly output clause to achieve the same functionality but with more verbose SQL. This approach will also work on SQL Server 2008.
http://sqlserver-tips.blogspot.co.uk/2006/09/mimicking-merge-statement-in-sql.html
You could put together a C# (or whatever) app to parse the merge statements and create insert/update statements from them. I mean, that's a horrible idea, but you can do it...
You'd have to pull out the "ON" part, add it to a check IF EXISTS and the update part, then add the column list to the insert part. You could even programmatically (sic?) create SP params and everything.
Heh. Good luck.
I'm about to write my first procedure to check if yesterdays data exists in one database, and if it select some of the data, use a count and insert that data into another database. If the data doesn't exist, then send me an email.
I'm using SQL Server 2005 and I'd like to ask the community for tips or good starting knowledge on smart procedure coding.
Thanks!
Here is an article on MSDN about stored procedures on SQL Serve 2005 that should help.
I'm working with a client who had a SQL Server 2008 converted from a SQL Server 2000 DB and one of the queries has quite dramatically increased in time since it was on SQL Server 2000.
However, if I change the compatibility level to 2008 in the DB, the query goes like a rocket (40-50 times faster).
The query does use a number of UDFs.
My questions:
- are there issues with running SQL2000 compatibility in SQL Server 2008
- has SQL Server 2008 improved the performance when using UDFs?
There are some other things you might want to do after upgrading. See the "After upgrading..." section here: http://msdn.microsoft.com/en-us/library/bb933942.aspx
how can I transform database from sql server 2005 to 2000
Use SSIS to export the database directly to SQL Server 2000.
First make sure that you aren't using any native 2005 features like included columns on indexes, XML features, etc. Then you can script the schema out using SSMS, and export the data using BCP or SSIS to SQL 2000. Some vendor tools exist like RedGate SQL Compare and Data Compare that make doing this a whole lot easier if you have primary keys defined on your tables.