December 17, 2007 at 2:47 pm
Hi All,
As a company policy we have migrated all sql server 2000 to sql server 2005 except one. Application vendor is adamant that his application is compatible to 2000 version (its hard coded. I don't know where and how) only.
I know we can restore a 2000 database with backup on 2005 and not change to compatibility level to 90 instead of 80 would still have features of 2000 server/database.
My question now is, if I do this, is it a problem? Would there be any issues as this database had a full text index/catalog? Would full text index performance would be same as before or it can have isue?
Any response is appriciated. Thanks in Adv.
SQL DBA.
December 17, 2007 at 2:55 pm
Full text catalogs cannot be backed up on 2000. You'll have to recreate it after you have restored the database. Make sure you test everything first, though.
December 20, 2007 at 3:02 pm
If your vendor says his app is only 2000 compatible, I wouldn't mess with putting it on 2005, even if that DB is in 2000 compatablity mode. Even if it does work, you'll likely lose support from them.
Also keep in mind that once you restore it on SQL 2005, you won't be able to go back to 2000 using backup/restore again.
The Redneck DBA
December 21, 2007 at 12:33 am
Yes u r right , we 've face the same problem.
December 21, 2007 at 1:39 am
Jason Shadonix (12/20/2007)
If your vendor says his app is only 2000 compatible, I wouldn't mess with putting it on 2005, even if that DB is in 2000 compatablity mode. Even if it does work, you'll likely lose support from them.Also keep in mind that once you restore it on SQL 2005, you won't be able to go back to 2000 using backup/restore again.
And thereby hangs the crux of the matter. Jason's right; this is a supplier relationship problem, not a technical one.
We've even hit this problem with regard to an application produced by our own company! If I can't convince one of my own business divisions that their app works fine on its underlying db when hosted on a newer version of SQL Server, but running in a particular compatibility mode, even when I demonstrate it, I doubt you'll have more luck with a third party supplier. App vendors are paranoid about any change, however innocuous, that they feel may introduce the possibility of increasing support calls. The db migration you're talking about may well make literally no difference, but how right you are will be absolutely irrelevant.
Semper in excretia, suus solum profundum variat
December 21, 2007 at 7:41 am
If an application has embedded SQL statements and they are referencing system tables directly that may be the case of application being compatible only with a particular SQL Server version (and if it is true then your vendor is right).
We had this situation with one of 3rd party application we are using and solution for us was upgrading to the next version of that application which supports SQL Server 2005.
December 21, 2007 at 7:46 am
leokarp (12/21/2007)
If an application has embedded SQL statements and they are referencing system tables directly that may be the case of application being compatible only with a particular SQL Server version (and if it is true then your vendor is right).We had this situation with one of 3rd party application we are using and solution for us was upgrading to the next version of that application which supports SQL Server 2005.
That wouldn't be Quest's otherwise excellent ActiveRoles software, would it? We're currently facing exactly that problem, and it's a pain.
Semper in excretia, suus solum profundum variat
December 21, 2007 at 8:00 am
leokarp (12/21/2007)
If an application has embedded SQL statements and they are referencing system tables directly that may be the case of application being compatible only with a particular SQL Server version (and if it is true then your vendor is right).We had this situation with one of 3rd party application we are using and solution for us was upgrading to the next version of that application which supports SQL Server 2005.
That exactly what the vendor is probably afraid of.
I.E. sp_who and RESTORE HEADERONLY return different results on 2000 and 2005. I'm sure there are several others...those are just the two I've learned about the hard way.
The Redneck DBA
December 21, 2007 at 8:15 am
majorbloodnock (12/21/2007)
That wouldn't be Quest's otherwise excellent ActiveRoles software, would it? We're currently facing exactly that problem, and it's a pain.
In our case it was Lyris ListManager which had direct queries from system tables in SQL Server 2000 and those tables' names don't exist in SQL Server 2005.
December 21, 2007 at 9:31 am
The compatibility views in SQL 2005 make it almost 100% backward compatible even if you reference objects like sysusers and syscolumns. Check it out in books online.
I found that my applications use these views with no code changes. The only thing I've found that did did not work is the Order By clause stored in a view when you use Top 100 percent. There is a work around, that I can explain if you want to try it.
Otherwise, I'd recommend, giving it a try in a test environment after looking at the views in the database. If they don't have views, it should work just fine.
I bet the vendor knows exactly what is broken in their application, But they won't upgrade until they start taking some heat on that. So, I'd say crank up the heat.
I find it strange that Microsoft changed the behavior of views, but went to great lengths to create compatibility views for system objects.
December 21, 2007 at 9:50 am
the big compatibility problems i've always had was backup software
Veritas Netbackup will only work with the SQL server it is designed for. we had to upgrade before we moved to SQL 2005
December 21, 2007 at 9:53 am
majorbloodnock (12/21/2007)
Jason Shadonix (12/20/2007)
If your vendor says his app is only 2000 compatible, I wouldn't mess with putting it on 2005, even if that DB is in 2000 compatablity mode. Even if it does work, you'll likely lose support from them.Also keep in mind that once you restore it on SQL 2005, you won't be able to go back to 2000 using backup/restore again.
And thereby hangs the crux of the matter. Jason's right; this is a supplier relationship problem, not a technical one.
We've even hit this problem with regard to an application produced by our own company! If I can't convince one of my own business divisions that their app works fine on its underlying db when hosted on a newer version of SQL Server, but running in a particular compatibility mode, even when I demonstrate it, I doubt you'll have more luck with a third party supplier. App vendors are paranoid about any change, however innocuous, that they feel may introduce the possibility of increasing support calls. The db migration you're talking about may well make literally no difference, but how right you are will be absolutely irrelevant.
it's also a matter of properly testing an old version on a new db and training their support people
why do it when you can just sell a newer version of your software?
December 21, 2007 at 10:04 am
Steve, If you're monitoring this. What do you think of starting a new forum to list all the things that are NOT backward compatible in sql 2005?
(Be sure to note that the DB compatibity setting must be set for SQL2000 compatibility?)
What do you think?
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply