Incorrect syntax near the keyword ''WHERE''

Hello,
I'm receiving this error: Msg 156, Level 15, State 1, Procedure pnpcart_GetCustomer_Details, Line 50
Incorrect syntax near the keyword 'WHERE'.

Code Snippet

ALTER PROCEDURE [dbo].[pnpcart_GetCustomer_Details]
-- Add the parameters for the stored procedure here
@.inSearchBy varchar(20),
@.inSearchFor varchar(100)

AS

BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;

DECLARE @.SQL varchar(500)
if (@.inSearchBy='Email' or @.inSearchBy='HomePhone')
begin
set @.SQL = 'SELECT * FROM dbo.pnpcart_Customer_Details WHERE ' + @.inSearchBy + ' = ''' + @.inSearchFor + ''''
exec ( @.SQL )
end
else
begin
SELECT
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
FROM
dbo.pnpcart_Customer_Details INNER JOIN dbo.aspnet_Users
ON
dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName
GROUP BY
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
WHERE dbo.aspnet_Users.UserName = ''+@.inSearchFor+''
end
END

My logic behind this code is utilize .NET membership database tables with one of my tables called pnpcart_Customer_Details. Instead of recreating the wheel I decided to INNER JOIN the columns dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName, and do a search for the value of @.inSearchFor. Every time I want to search for a value of a variable I always end up creating dynamic sql code. I'm trying to stay away from dynamic sql. Any help with my error and how to stay away from dynamic sql is greatly appreciated. Thanks!

-Rich

The where clause should present before the Group By clause,

Code Snippet

SELECT

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

FROM

dbo.pnpcart_Customer_Details

INNER JOIN dbo.aspnet_Users

ON dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE

dbo.aspnet_Users.UserName = @.inSearchFor

GROUP BY

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

Or

Code Snippet

Set @.SQL = 'SELECT

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

FROM

dbo.pnpcart_Customer_Details

INNER JOIN dbo.aspnet_Users

ON dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE

dbo.aspnet_Users.UserName in (' +@.inSearchFor + ')

GROUP BY

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName'

|||

You can do this:

Code Snippet

ALTER PROCEDURE [dbo].[pnpcart_GetCustomer_Details]
-- Add the parameters for the stored procedure here
@.inSearchBy varchar(20),
@.inSearchFor varchar(100)

AS

BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;

DECLARE @.SQL nvarchar(500)
if (@.inSearchBy='Email' or @.inSearchBy='HomePhone')
begin
set @.SQL = 'SELECT * FROM dbo.pnpcart_Customer_Details

WHERE ' + @.inSearchBy + ' = @.inSearchFor'

exec sp_executesql @.SQL, N'@.inSearchFor varchar(100)', @.inSearchFor

end
else
begin
SELECT
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
FROM
dbo.pnpcart_Customer_Details INNER JOIN dbo.aspnet_Users
ON
dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE dbo.aspnet_Users.UserName = @.inSearchFor
GROUP BY
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
end
END

sql

Incorrect syntax near the keyword ''WHERE''

Hello,
I'm receiving this error: Msg 156, Level 15, State 1, Procedure pnpcart_GetCustomer_Details, Line 50
Incorrect syntax near the keyword 'WHERE'.

Code Snippet

ALTER PROCEDURE [dbo].[pnpcart_GetCustomer_Details]
-- Add the parameters for the stored procedure here
@.inSearchBy varchar(20),
@.inSearchFor varchar(100)

AS

BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;

DECLARE @.SQL varchar(500)
if (@.inSearchBy='Email' or @.inSearchBy='HomePhone')
begin
set @.SQL = 'SELECT * FROM dbo.pnpcart_Customer_Details WHERE ' + @.inSearchBy + ' = ''' + @.inSearchFor + ''''
exec ( @.SQL )
end
else
begin
SELECT
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
FROM
dbo.pnpcart_Customer_Details INNER JOIN dbo.aspnet_Users
ON
dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName
GROUP BY
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
WHERE dbo.aspnet_Users.UserName = ''+@.inSearchFor+''
end
END

My logic behind this code is utilize .NET membership database tables with one of my tables called pnpcart_Customer_Details. Instead of recreating the wheel I decided to INNER JOIN the columns dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName, and do a search for the value of @.inSearchFor. Every time I want to search for a value of a variable I always end up creating dynamic sql code. I'm trying to stay away from dynamic sql. Any help with my error and how to stay away from dynamic sql is greatly appreciated. Thanks!

-Rich

The where clause should present before the Group By clause,

Code Snippet

SELECT

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

FROM

dbo.pnpcart_Customer_Details

INNER JOIN dbo.aspnet_Users

ON dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE

dbo.aspnet_Users.UserName = @.inSearchFor

GROUP BY

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

Or

Code Snippet

Set @.SQL = 'SELECT

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

FROM

dbo.pnpcart_Customer_Details

INNER JOIN dbo.aspnet_Users

ON dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE

dbo.aspnet_Users.UserName in (' +@.inSearchFor + ')

GROUP BY

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName'

|||

You can do this:

Code Snippet

ALTER PROCEDURE [dbo].[pnpcart_GetCustomer_Details]
-- Add the parameters for the stored procedure here
@.inSearchBy varchar(20),
@.inSearchFor varchar(100)

AS

BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;

DECLARE @.SQL nvarchar(500)
if (@.inSearchBy='Email' or @.inSearchBy='HomePhone')
begin
set @.SQL = 'SELECT * FROM dbo.pnpcart_Customer_Details

WHERE ' + @.inSearchBy + ' = @.inSearchFor'

exec sp_executesql @.SQL, N'@.inSearchFor varchar(100)', @.inSearchFor

end
else
begin
SELECT
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
FROM
dbo.pnpcart_Customer_Details INNER JOIN dbo.aspnet_Users
ON
dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE dbo.aspnet_Users.UserName = @.inSearchFor
GROUP BY
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
end
END

Incorrect syntax near the keyword ''WHERE''

Hello,
I'm receiving this error: Msg 156, Level 15, State 1, Procedure pnpcart_GetCustomer_Details, Line 50
Incorrect syntax near the keyword 'WHERE'.

Code Snippet

ALTER PROCEDURE [dbo].[pnpcart_GetCustomer_Details]
-- Add the parameters for the stored procedure here
@.inSearchBy varchar(20),
@.inSearchFor varchar(100)

AS

BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;

DECLARE @.SQL varchar(500)
if (@.inSearchBy='Email' or @.inSearchBy='HomePhone')
begin
set @.SQL = 'SELECT * FROM dbo.pnpcart_Customer_Details WHERE ' + @.inSearchBy + ' = ''' + @.inSearchFor + ''''
exec ( @.SQL )
end
else
begin
SELECT
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
FROM
dbo.pnpcart_Customer_Details INNER JOIN dbo.aspnet_Users
ON
dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName
GROUP BY
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
WHERE dbo.aspnet_Users.UserName = ''+@.inSearchFor+''
end
END

My logic behind this code is utilize .NET membership database tables with one of my tables called pnpcart_Customer_Details. Instead of recreating the wheel I decided to INNER JOIN the columns dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName, and do a search for the value of @.inSearchFor. Every time I want to search for a value of a variable I always end up creating dynamic sql code. I'm trying to stay away from dynamic sql. Any help with my error and how to stay away from dynamic sql is greatly appreciated. Thanks!

-Rich

The where clause should present before the Group By clause,

Code Snippet

SELECT

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

FROM

dbo.pnpcart_Customer_Details

INNER JOIN dbo.aspnet_Users

ON dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE

dbo.aspnet_Users.UserName = @.inSearchFor

GROUP BY

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

Or

Code Snippet

Set @.SQL = 'SELECT

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName

FROM

dbo.pnpcart_Customer_Details

INNER JOIN dbo.aspnet_Users

ON dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE

dbo.aspnet_Users.UserName in (' +@.inSearchFor + ')

GROUP BY

dbo.pnpcart_Customer_Details.UserID

, dbo.aspnet_Users.UserName'

|||

You can do this:

Code Snippet

ALTER PROCEDURE [dbo].[pnpcart_GetCustomer_Details]
-- Add the parameters for the stored procedure here
@.inSearchBy varchar(20),
@.inSearchFor varchar(100)

AS

BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;

DECLARE @.SQL nvarchar(500)
if (@.inSearchBy='Email' or @.inSearchBy='HomePhone')
begin
set @.SQL = 'SELECT * FROM dbo.pnpcart_Customer_Details

WHERE ' + @.inSearchBy + ' = @.inSearchFor'

exec sp_executesql @.SQL, N'@.inSearchFor varchar(100)', @.inSearchFor

end
else
begin
SELECT
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
FROM
dbo.pnpcart_Customer_Details INNER JOIN dbo.aspnet_Users
ON
dbo.pnpcart_Customer_Details.UserID = dbo.aspnet_Users.UserName

WHERE dbo.aspnet_Users.UserName = @.inSearchFor
GROUP BY
dbo.pnpcart_Customer_Details.UserID, dbo.aspnet_Users.UserName
end
END

Incorrect syntax near '@Sites'.

I have the following code but it keeps erroring on the last line and I'm unsure as to why it is doing it?

Here is the error message

Msg 102, Level 15, State 1, Line 42

Incorrect syntax near '@.Sites'.

declare @.Sites varchar(50)

declare @.Kit_No char(20)

declare @.Location char(2)

set @.Location = 'Ho'

set @.Kit_No = 'mo1k'

if (SELECT sitetype from gss.dbo.kup_regions where region_code = @.Location) = 10

begin

set @.Sites = '''Pe'',''Hg'',''Vo'',''' + @.Location + ''''

end

select

KR.Region_Code,

KR.Region_Name,

Z.Qty,

Z.Kit_Description,

Z.BookedOutToDate as Usage,

Z.Local_Cost,

(select overstock from gss.dbo.vGss_overstock where region_code = Z.region_code and kit_no = 'm01k' )as Rolling_Avg,

C.Symbol,

Z.FOB,

(SELECT

Price

FROM

gss.dbo.FedEx_Rates Fed

WHERE

SourceRegion = (SELECT Region_Code FROM gss.dbo.KUP_Regions WHERE Region_Name = 'penistone')

AND Weight = (SELECT MAX (Weight) FROM gss.dbo.FedEx_Rates WHERE Weight < (SELECT Packed_Unit_Weight From gss.dbo.KUP_Kits WHERE Kit_Code = (select Kit_Code from gss.dbo.GSS_Kits where Kit_No = 'm01k' ))+0.5)

AND Fed.DestRegion=KR.Region_Code) as Fedex_Price

from

(gss.dbo.kup_regions KR with (nolock)

left outer join

(select KRD.Qty,KRD.BookedOutToDate,KRD.Local_Cost,KRD.FOB,GK.Kit_Description,KRD.Region_code,KRD.Archive_Date

from gss.dbo.kup_region_data KRD with (nolock) inner join gss.dbo.gss_kits GK

on KRD.kit_code = GK.kit_code where GK.kit_no =@.Kit_No and KRD.archive_date is not null )Z

on KR.region_code = Z.region_code)

inner join gss.dbo.Currency C with (nolock) on C.Country_Code = KR.Country_Code

where KR.ExpectExtract = 1 and KR.Designation = 'p' and KR.Region_code in @.Sites

Many thanks for any help

The IN keyword requires a parenthesis, modify the last line as follows:

where KR.ExpectExtract = 1 and KR.Designation = 'p' and KR.Region_code in (@.Sites)

|||

Simon:

If @.sites is a simple 1-item variable then what carlop says is correct.

However, I assume that @.sites is a "string list" -- that is, it is a list of region codes such as @.Sites = 'rg1,rg2,rg3'. If that is the case there are a couple of solutions. A good read is at website:

http://www.sommarskog.se/arrays-in-sql.html

The "cheap" solution here is to convert your huge select statement into a string and then execute the converted string. This is in fact a simplified overview, but you will also need change this:

KR.Region_code in @.Sites

into this:

' ... KR.Region_code in ( ' + @.Sites + ') '

However, this solution might leave you vulnerable to SQL injection and this is not what I would do.

I would either create a function to list out your string list or I would just process your "string list" and load each separate entry into a table variable and change your IN portion into selecting the region codes out of the list.

(BLEAH my comments sound like a bunch of mumbo-jumbo. Let me find an example.)

Dave

|||

-- --
-- Use a "stringList" function to enumerate the parts of the "@.sites" string
-- --

declare @.sites varchar (20) set @.sites = 'N,A'

declare @.kup_regions table (Region_code char (1), Region_Name varchar (25))
insert into @.kup_regions values ('N', 'Northern Region')
insert into @.kup_regions values ('E', 'Eastern Region')
insert into @.kup_regions values ('W', 'West Region')
insert into @.kup_regions values ('S', 'South Region')
insert into @.kup_regions values ('A', 'A non-conforming Region')

-- An example using an inner join -
select a.region_code,
a.region_name
from @.kup_regions a
inner join stringList (',', @.sites) b
on b.entry = left (a.region_code,1)

-- An example using an "IN" clause
select a.region_code,
a.region_name
from @.kup_regions a
where a.region_code in
(select entry from stringList (',', @.sites) )

-- -
-- Sample Output
-- -

-- region_code region_name
-- -- -
-- N Northern Region
-- A A non-conforming Region

Incorrect PageAudit Property

Hello, after a fatal server crash (with no backups!!) I have tried to re-attach a database but I get the following message;

"Msg 5172, Level 16, State 15, Line 1

The header for file 'E:\Database.mdf' is not a valid database file header. The PageAudit property is incorrect."

The database files ( both mdf & ldf ) where recovered from a file system copy which was made while SQL Server 2005 was still running. The files where copied with Symantec Backup Exec (10d).

Is there any way that the database can be recovered from these files?

(I have tried a few 3rd party tools ie, Apex SQL Log & Recovery for SQL Server, but none of these where successful )

Would Miscorsoft Product Support be able to recover any data or does anyone know of any 3rd party companies that could help?

Any help would be greatly appreciated.

Roy

It could help... or maybe couldn't...

http://support.microsoft.com/default.aspx?scid=kb;en-us;268481

|||

The file header page is corrupt, which means the file cannot be attached. Product Support will not attempt data recovery for you - I advise you to contact a 3rd party to try it (and get a SQL backup strategy so this doesn't happen again).

Thanks

|||

Not all backup products are able to save the contents of a file while that file is open. Others do only if you enable (purchase) an extra option. If that were the case here (I can't speak directly to Backup Exec), what you have backed up is an empty file. This should be easy to see if you just open it in a hex editor.

I wish I had better news, but it doesn't look good.

|||

Roy,

If you email me directly at kfarlee@.microsoft.com , I'll put you in touch with a Backup Exec engineer who may be able to help figure out what happened.

Incorrect PageAudit Property

Hello, after a fatal server crash (with no backups!!) I have tried to re-attach a database but I get the following message;

"Msg 5172, Level 16, State 15, Line 1

The header for file 'E:\Database.mdf' is not a valid database file header. The PageAudit property is incorrect."

The database files ( both mdf & ldf ) where recovered from a file system copy which was made while SQL Server 2005 was still running. The files where copied with Symantec Backup Exec (10d).

Is there any way that the database can be recovered from these files?

(I have tried a few 3rd party tools ie, Apex SQL Log & Recovery for SQL Server, but none of these where successful )

Would Miscorsoft Product Support be able to recover any data or does anyone know of any 3rd party companies that could help?

Any help would be greatly appreciated.

Roy

It could help... or maybe couldn't...

http://support.microsoft.com/default.aspx?scid=kb;en-us;268481

|||

The file header page is corrupt, which means the file cannot be attached. Product Support will not attempt data recovery for you - I advise you to contact a 3rd party to try it (and get a SQL backup strategy so this doesn't happen again).

Thanks

|||

Not all backup products are able to save the contents of a file while that file is open. Others do only if you enable (purchase) an extra option. If that were the case here (I can't speak directly to Backup Exec), what you have backed up is an empty file. This should be easy to see if you just open it in a hex editor.

I wish I had better news, but it doesn't look good.

|||

Roy,

If you email me directly at kfarlee@.microsoft.com , I'll put you in touch with a Backup Exec engineer who may be able to help figure out what happened.

sql

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksPlease ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:

> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Sorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:

> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:

>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Please ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:

> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:

> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:

>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is i
n
>8.0 compatability, but you get an error message when running the query whic
h
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>

Incorrect Compatibility level Error 15414:

John,
I ran the indexed views query and indexed computed columns
query on the database that has the compatability level set
to 70. Only one table returned from the indexed computed
columns query.
Output from indexed computed columns query
Object_Name Column_Name
AccountDetail AcctDtlSrceTble
__________________________________________________________
DROP INDEX AccountDetail.AcctDtlSrceTble
How do I obtain a sql script to regenerate the
AccountDetail.AcctDtlSrceTble indexed computed column?
What are the steps that I need to take to change the
compatiblity level 80 to 70?
Thank You,
John
This suggests you are using some capabilities available in
SQL2000 that were
not previously available in down level versions. To check
for indexed views
or indexes on computed columns run the following query in
Query Analyzer.
These indexes will need to be dropped in order to
downgrade the database
compatability
-- indexed views
select name from sysobjects where xtype = 'V'
and objectproperty(id,'IsMSShipped')=0
and objectproperty(id,'IsIndexed')=1
-- indexed computed columns
select object_name(c.id),c.name
from syscolumns c join sysindexkeys k
on c.colid = k.colid and c.id=k.id
where columnproperty(c.id,c.name,'IsComputed')=1
and objectproperty(c.id,'IsMSShipped')=0
and objectproperty(c.id,'IsIndexed')=1
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in
message
news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
I have a SQL Server 2000 Enterprise Edition along with
SP3A with several databases. These databases are 20 GB in
size. On one of the databases the Compatibility level was
changed from 70 to 80. I need to change the compatiblity
level 80 to 70.
When tried to change the compatibilty level I received the
following error:
Error 15414: Cannot set compatibilty level because
database has a view or computed column is indexed. These
indexes require a SQL Server compatible database.
Please help me resolve this problem.
John
name
---
---
-- ---
---
--
AccountDetail
AcctDtlSrceTble
(1 row(s) affected)The easiest way is to use the Query Analyzer Object Browser and expand the
node for the table and then the underlying one for Indexes. You can then
select the relavent index, right click on it and choose Script Object to New
Window As > Create.You can do the same to generate the script to drop it.
You can use the system stored procedure dbcmptlevel to change the
compatability mode e.g.
EXEC sp_dbcmptlevel 'pubs', 70
However, I'm not clear on why you need to do this ?
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:257801c427d3$568d9ac0$a101280a@.phx.gbl...
> John,
> I ran the indexed views query and indexed computed columns
> query on the database that has the compatability level set
> to 70. Only one table returned from the indexed computed
> columns query.
> Output from indexed computed columns query
> Object_Name Column_Name
> AccountDetail AcctDtlSrceTble
> __________________________________________________________
> DROP INDEX AccountDetail.AcctDtlSrceTble
> How do I obtain a sql script to regenerate the
> AccountDetail.AcctDtlSrceTble indexed computed column?
> What are the steps that I need to take to change the
> compatiblity level 80 to 70?
> Thank You,
> John
>
> This suggests you are using some capabilities available in
> SQL2000 that were
> not previously available in down level versions. To check
> for indexed views
> or indexes on computed columns run the following query in
> Query Analyzer.
> These indexes will need to be dropped in order to
> downgrade the database
> compatability
> -- indexed views
> select name from sysobjects where xtype = 'V'
> and objectproperty(id,'IsMSShipped')=0
> and objectproperty(id,'IsIndexed')=1
> -- indexed computed columns
> select object_name(c.id),c.name
> from syscolumns c join sysindexkeys k
> on c.colid = k.colid and c.id=k.id
> where columnproperty(c.id,c.name,'IsComputed')=1
> and objectproperty(c.id,'IsMSShipped')=0
> and objectproperty(c.id,'IsIndexed')=1
> --
> HTH
> Jasper Smith (SQL Server MVP)
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
>
> "John" <anonymous@.discussions.microsoft.com> wrote in
> message
> news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
> I have a SQL Server 2000 Enterprise Edition along with
> SP3A with several databases. These databases are 20 GB in
> size. On one of the databases the Compatibility level was
> changed from 70 to 80. I need to change the compatiblity
> level 80 to 70.
> When tried to change the compatibilty level I received the
> following error:
> Error 15414: Cannot set compatibilty level because
> database has a view or computed column is indexed. These
> indexes require a SQL Server compatible database.
> Please help me resolve this problem.
> John
>
>
> name
>
> ---
> ---
> -- ---
> ---
> --
> AccountDetail
> AcctDtlSrceTble
> (1 row(s) affected)

Incorrect Compatibility level Error 15414:

John,
I ran the indexed views query and indexed computed columns
query on the database that has the compatability level set
to 70. Only one table returned from the indexed computed
columns query.
Output from indexed computed columns query
Object_Name Column_Name
AccountDetail AcctDtlSrceTble
__________________________________________________ ________
DROP INDEX AccountDetail.AcctDtlSrceTble
How do I obtain a sql script to regenerate the
AccountDetail.AcctDtlSrceTble indexed computed column?
What are the steps that I need to take to change the
compatiblity level 80 to 70?
Thank You,
John
This suggests you are using some capabilities available in
SQL2000 that were
not previously available in down level versions. To check
for indexed views
or indexes on computed columns run the following query in
Query Analyzer.
These indexes will need to be dropped in order to
downgrade the database
compatability
-- indexed views
select name from sysobjects where xtype = 'V'
and objectproperty(id,'IsMSShipped')=0
and objectproperty(id,'IsIndexed')=1
-- indexed computed columns
select object_name(c.id),c.name
from syscolumns c join sysindexkeys k
on c.colid = k.colid and c.id=k.id
where columnproperty(c.id,c.name,'IsComputed')=1
and objectproperty(c.id,'IsMSShipped')=0
and objectproperty(c.id,'IsIndexed')=1
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in
message
news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
I have a SQL Server 2000 Enterprise Edition along with
SP3A with several databases. These databases are 20 GB in
size. On one of the databases the Compatibility level was
changed from 70 to 80. I need to change the compatiblity
level 80 to 70.
When tried to change the compatibilty level I received the
following error:
Error 15414: Cannot set compatibilty level because
database has a view or computed column is indexed. These
indexes require a SQL Server compatible database.
Please help me resolve this problem.
John
name
---
-- ---
AccountDetail
AcctDtlSrceTble
(1 row(s) affected)
The easiest way is to use the Query Analyzer Object Browser and expand the
node for the table and then the underlying one for Indexes. You can then
select the relavent index, right click on it and choose Script Object to New
Window As > Create.You can do the same to generate the script to drop it.
You can use the system stored procedure dbcmptlevel to change the
compatability mode e.g.
EXEC sp_dbcmptlevel 'pubs', 70
However, I'm not clear on why you need to do this ?
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:257801c427d3$568d9ac0$a101280a@.phx.gbl...
> John,
> I ran the indexed views query and indexed computed columns
> query on the database that has the compatability level set
> to 70. Only one table returned from the indexed computed
> columns query.
> Output from indexed computed columns query
> Object_Name Column_Name
> AccountDetail AcctDtlSrceTble
> __________________________________________________ ________
> DROP INDEX AccountDetail.AcctDtlSrceTble
> How do I obtain a sql script to regenerate the
> AccountDetail.AcctDtlSrceTble indexed computed column?
> What are the steps that I need to take to change the
> compatiblity level 80 to 70?
> Thank You,
> John
>
> This suggests you are using some capabilities available in
> SQL2000 that were
> not previously available in down level versions. To check
> for indexed views
> or indexes on computed columns run the following query in
> Query Analyzer.
> These indexes will need to be dropped in order to
> downgrade the database
> compatability
> -- indexed views
> select name from sysobjects where xtype = 'V'
> and objectproperty(id,'IsMSShipped')=0
> and objectproperty(id,'IsIndexed')=1
> -- indexed computed columns
> select object_name(c.id),c.name
> from syscolumns c join sysindexkeys k
> on c.colid = k.colid and c.id=k.id
> where columnproperty(c.id,c.name,'IsComputed')=1
> and objectproperty(c.id,'IsMSShipped')=0
> and objectproperty(c.id,'IsIndexed')=1
> --
> HTH
> Jasper Smith (SQL Server MVP)
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
>
> "John" <anonymous@.discussions.microsoft.com> wrote in
> message
> news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
> I have a SQL Server 2000 Enterprise Edition along with
> SP3A with several databases. These databases are 20 GB in
> size. On one of the databases the Compatibility level was
> changed from 70 to 80. I need to change the compatiblity
> level 80 to 70.
> When tried to change the compatibilty level I received the
> following error:
> Error 15414: Cannot set compatibilty level because
> database has a view or computed column is indexed. These
> indexes require a SQL Server compatible database.
> Please help me resolve this problem.
> John
>
>
> name
>
> -- ---
> --
> AccountDetail
> AcctDtlSrceTble
> (1 row(s) affected)

Incorrect Compatibility level Error 15414:

I have a SQL Server 2000 Enterprise Edition along with
SP3A with several databases. These databases are 20 GB in
size. On one of the databases the Compatibility level was
changed from 70 to 80. I need to change the compatiblity
level 80 to 70.
When tried to change the compatibilty level I received the
following error:
Error 15414: Cannot set compatibilty level because
database has a view or computed column is indexed. These
indexes require a SQL Server compatible database.
Please help me resolve this problem.
John
This suggests you are using some capabilities available in SQL2000 that were
not previously available in down level versions. To check for indexed views
or indexes on computed columns run the following query in Query Analyzer.
These indexes will need to be dropped in order to downgrade the database
compatability
-- indexed views
select name from sysobjects where xtype = 'V'
and objectproperty(id,'IsMSShipped')=0
and objectproperty(id,'IsIndexed')=1
-- indexed computed columns
select object_name(c.id),c.name
from syscolumns c join sysindexkeys k
on c.colid = k.colid and c.id=k.id
where columnproperty(c.id,c.name,'IsComputed')=1
and objectproperty(c.id,'IsMSShipped')=0
and objectproperty(c.id,'IsIndexed')=1
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
> I have a SQL Server 2000 Enterprise Edition along with
> SP3A with several databases. These databases are 20 GB in
> size. On one of the databases the Compatibility level was
> changed from 70 to 80. I need to change the compatiblity
> level 80 to 70.
> When tried to change the compatibilty level I received the
> following error:
> Error 15414: Cannot set compatibilty level because
> database has a view or computed column is indexed. These
> indexes require a SQL Server compatible database.
> Please help me resolve this problem.
> John

Incorrect Compatibility level Error 15414:

I have a SQL Server 2000 Enterprise Edition along with
SP3A with several databases. These databases are 20 GB in
size. On one of the databases the Compatibility level was
changed from 70 to 80. I need to change the compatiblity
level 80 to 70.
When tried to change the compatibilty level I received the
following error:
Error 15414: Cannot set compatibilty level because
database has a view or computed column is indexed. These
indexes require a SQL Server compatible database.
Please help me resolve this problem.
JohnThis suggests you are using some capabilities available in SQL2000 that were
not previously available in down level versions. To check for indexed views
or indexes on computed columns run the following query in Query Analyzer.
These indexes will need to be dropped in order to downgrade the database
compatability
-- indexed views
select name from sysobjects where xtype = 'V'
and objectproperty(id,'IsMSShipped')=0
and objectproperty(id,'IsIndexed')=1
-- indexed computed columns
select object_name(c.id),c.name
from syscolumns c join sysindexkeys k
on c.colid = k.colid and c.id=k.id
where columnproperty(c.id,c.name,'IsComputed')=1
and objectproperty(c.id,'IsMSShipped')=0
and objectproperty(c.id,'IsIndexed')=1
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
> I have a SQL Server 2000 Enterprise Edition along with
> SP3A with several databases. These databases are 20 GB in
> size. On one of the databases the Compatibility level was
> changed from 70 to 80. I need to change the compatiblity
> level 80 to 70.
> When tried to change the compatibilty level I received the
> following error:
> Error 15414: Cannot set compatibilty level because
> database has a view or computed column is indexed. These
> indexes require a SQL Server compatible database.
> Please help me resolve this problem.
> John

Incorrect Compatibility level Error 15414:

I have a SQL Server 2000 Enterprise Edition along with
SP3A with several databases. These databases are 20 GB in
size. On one of the databases the Compatibility level was
changed from 70 to 80. I need to change the compatiblity
level 80 to 70.
When tried to change the compatibilty level I received the
following error:
Error 15414: Cannot set compatibilty level because
database has a view or computed column is indexed. These
indexes require a SQL Server compatible database.
Please help me resolve this problem.
JohnThis suggests you are using some capabilities available in SQL2000 that were
not previously available in down level versions. To check for indexed views
or indexes on computed columns run the following query in Query Analyzer.
These indexes will need to be dropped in order to downgrade the database
compatability
-- indexed views
select name from sysobjects where xtype = 'V'
and objectproperty(id,'IsMSShipped')=0
and objectproperty(id,'IsIndexed')=1
-- indexed computed columns
select object_name(c.id),c.name
from syscolumns c join sysindexkeys k
on c.colid = k.colid and c.id=k.id
where columnproperty(c.id,c.name,'IsComputed')=1
and objectproperty(c.id,'IsMSShipped')=0
and objectproperty(c.id,'IsIndexed')=1
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
> I have a SQL Server 2000 Enterprise Edition along with
> SP3A with several databases. These databases are 20 GB in
> size. On one of the databases the Compatibility level was
> changed from 70 to 80. I need to change the compatiblity
> level 80 to 70.
> When tried to change the compatibilty level I received the
> following error:
> Error 15414: Cannot set compatibilty level because
> database has a view or computed column is indexed. These
> indexes require a SQL Server compatible database.
> Please help me resolve this problem.
> John

Incorrect Compatibility level Error 15414:

John,
I ran the indexed views query and indexed computed columns
query on the database that has the compatability level set
to 70. Only one table returned from the indexed computed
columns query.
Output from indexed computed columns query
Object_Name Column_Name
AccountDetail AcctDtlSrceTble
________________________________________
__________________
DROP INDEX AccountDetail.AcctDtlSrceTble
How do I obtain a sql script to regenerate the
AccountDetail.AcctDtlSrceTble indexed computed column?
What are the steps that I need to take to change the
compatiblity level 80 to 70?
Thank You,
John
This suggests you are using some capabilities available in
SQL2000 that were
not previously available in down level versions. To check
for indexed views
or indexes on computed columns run the following query in
Query Analyzer.
These indexes will need to be dropped in order to
downgrade the database
compatability
-- indexed views
select name from sysobjects where xtype = 'V'
and objectproperty(id,'IsMSShipped')=0
and objectproperty(id,'IsIndexed')=1
-- indexed computed columns
select object_name(c.id),c.name
from syscolumns c join sysindexkeys k
on c.colid = k.colid and c.id=k.id
where columnproperty(c.id,c.name,'IsComputed')=1
and objectproperty(c.id,'IsMSShipped')=0
and objectproperty(c.id,'IsIndexed')=1
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in
message
news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
I have a SQL Server 2000 Enterprise Edition along with
SP3A with several databases. These databases are 20 GB in
size. On one of the databases the Compatibility level was
changed from 70 to 80. I need to change the compatiblity
level 80 to 70.
When tried to change the compatibilty level I received the
following error:
Error 15414: Cannot set compatibilty level because
database has a view or computed column is indexed. These
indexes require a SQL Server compatible database.
Please help me resolve this problem.
John
name
---
---
-- ---
---
--
AccountDetail
AcctDtlSrceTble
(1 row(s) affected)The easiest way is to use the Query Analyzer Object Browser and expand the
node for the table and then the underlying one for Indexes. You can then
select the relavent index, right click on it and choose Script Object to New
Window As > Create.You can do the same to generate the script to drop it.
You can use the system stored procedure dbcmptlevel to change the
compatability mode e.g.
EXEC sp_dbcmptlevel 'pubs', 70
However, I'm not clear on why you need to do this ?
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:257801c427d3$568d9ac0$a101280a@.phx.gbl...
> John,
> I ran the indexed views query and indexed computed columns
> query on the database that has the compatability level set
> to 70. Only one table returned from the indexed computed
> columns query.
> Output from indexed computed columns query
> Object_Name Column_Name
> AccountDetail AcctDtlSrceTble
> ________________________________________
__________________
> DROP INDEX AccountDetail.AcctDtlSrceTble
> How do I obtain a sql script to regenerate the
> AccountDetail.AcctDtlSrceTble indexed computed column?
> What are the steps that I need to take to change the
> compatiblity level 80 to 70?
> Thank You,
> John
>
> This suggests you are using some capabilities available in
> SQL2000 that were
> not previously available in down level versions. To check
> for indexed views
> or indexes on computed columns run the following query in
> Query Analyzer.
> These indexes will need to be dropped in order to
> downgrade the database
> compatability
> -- indexed views
> select name from sysobjects where xtype = 'V'
> and objectproperty(id,'IsMSShipped')=0
> and objectproperty(id,'IsIndexed')=1
> -- indexed computed columns
> select object_name(c.id),c.name
> from syscolumns c join sysindexkeys k
> on c.colid = k.colid and c.id=k.id
> where columnproperty(c.id,c.name,'IsComputed')=1
> and objectproperty(c.id,'IsMSShipped')=0
> and objectproperty(c.id,'IsIndexed')=1
> --
> HTH
> Jasper Smith (SQL Server MVP)
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
>
> "John" <anonymous@.discussions.microsoft.com> wrote in
> message
> news:239601c427b6$d93c5f00$a101280a@.phx.gbl...
> I have a SQL Server 2000 Enterprise Edition along with
> SP3A with several databases. These databases are 20 GB in
> size. On one of the databases the Compatibility level was
> changed from 70 to 80. I need to change the compatiblity
> level 80 to 70.
> When tried to change the compatibilty level I received the
> following error:
> Error 15414: Cannot set compatibilty level because
> database has a view or computed column is indexed. These
> indexes require a SQL Server compatible database.
> Please help me resolve this problem.
> John
>
>
> name
>
> ---
> ---
> -- ---
> ---
> --
> AccountDetail
> AcctDtlSrceTble
> (1 row(s) affected)