Compatibility Levels
From: Richard J (RichardJ_at_discussions.microsoft.com)
Date: 09/01/04
- Next message: Michael: "Re: Deadlock on an identity field table"
- Previous message: Stephen: "select statment help required please"
- Next in thread: Dan Guzman: "Re: Compatibility Levels"
- Reply: Dan Guzman: "Re: Compatibility Levels"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 1 Sep 2004 08:55:04 -0700
Hi group,
Pardon me if this is not the appropriate forum for this question.
Our product uses a mix of SQL Server 6.5 and SQL Server 2000. Some clients
use one or the other. Some of these clients upgraded to SQL Server 2000. In
these instances, the compatibility level of the database remains at 65.
We are now trying to update the database to include primary keys (don't get
me started on why it has taken so long), but running into problems because
many of the fields that would be used were defined as NULL.
And despite being on SQL Server 2000, the compatibility level of 65
prohibits us from executing the ALTER COLUMN statement.
I know I can use the sp_dbcmptlevel stored procedure to update the
compatibility level, but cannot do so in a stored procedure or ISQL query
process. If I try, the command does not execute and I get a message about
how sp_dbcmptlevel can only be run at the ad-hoc level. I get a similar
message if I try to update the database table directly, which doesn't really
surprise me.
So, are we stuck to manually updating each compatibility level to 80 through
either the Enterprise Manager or Query Analyzer? Is there no way to change
it on the fly, so to speak?
Sorry for the length, but thanks for reading this far and for any input you
can give.
Richard
- Next message: Michael: "Re: Deadlock on an identity field table"
- Previous message: Stephen: "select statment help required please"
- Next in thread: Dan Guzman: "Re: Compatibility Levels"
- Reply: Dan Guzman: "Re: Compatibility Levels"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|