Showing posts with label ctp. Show all posts
Showing posts with label ctp. Show all posts

Sunday, March 11, 2012

BUG in SQL Server Manager - Default Schema

Hallo,
June CTP of SQL Server 2005 (NOT SQL Express)
########
Everything deleted from this post by Alle since it has no relevance to the RTM.
Unfortunately I can not delete the thread.
###########
Alle

There is now an invisible comment that has been added by a moderator (I hate that too, why isn't the comment / edit visible in the thread?) :

=== Edited by Paul Mestemaker - MSFT @. 28 Oct 2006 1:59 AM UTC===
This is a comment not a question. This bug has been fixed.

Paul,

you are absolutely right, it was fixed ages ago and in addition we are well over the CTP stage of SQL Server 2005 which was RTM one year ago.

Wouldn't it make much more sense to delete this entire thread since it now longer has ANY revelance?

I can't although I am the author (I tried).

Thanks,
Alle

BUG in SQL Server Manager - Default Schema

Hallo,
June CTP of SQL Server 2005 (NOT SQL Express)
########
Everything deleted from this post by Alle since it has no relevance to the RTM.
Unfortunately I can not delete the thread.
###########
Alle

There is now an invisible comment that has been added by a moderator (I hate that too, why isn't the comment / edit visible in the thread?) :

=== Edited by Paul Mestemaker - MSFT @. 28 Oct 2006 1:59 AM UTC===
This is a comment not a question. This bug has been fixed.

Paul,

you are absolutely right, it was fixed ages ago and in addition we are well over the CTP stage of SQL Server 2005 which was RTM one year ago.

Wouldn't it make much more sense to delete this entire thread since it now longer has ANY revelance?

I can't although I am the author (I tried).

Thanks,
Alle

Wednesday, March 7, 2012

Bug (?) in SQL2005 x64 SP1 CTP

We're testing the same DB (~ 5GB, ~ 500 tables) with
Server32 (Win2003 Standard 32 bit, SQL2005 Developer 32 bit SP1 CTP, 1gb Memory) and with
Server64 (Win2003 x64 Standard 64 bit, SQL2005 Developer 64 bit SP1 CTP, 6gb Memory).

exec sp_MSforeachtable @.command1="SET QUOTED_IDENTIFIER ON DBCC DBREINDEX ('?', '', 90)"

On Server32 the SQL above runs without errors. On Server64 there comes the following error message:
Msg 8621, Level 17, State 1, Line 1
The query processor ran out of stack space during query optimization. Please simplify the query.

A 64bit server with 6gb memory has less stack space than a 32bit server with 1gb memory?

Regards
Peter

PS: I know sp_MSforeachtable is not an official stored procedure, but I don't thinkt there's the problem. I got the same error on Server64, when I run the following cursor:
DECLARE tablename CURSOR
READ_ONLY
FOR select [name] from sys.tables where type = 'U'

DECLARE @.name varchar(80)
OPEN tablename

FETCH NEXT FROM tablename INTO @.name
WHILE (@.@.fetch_status <> -1)
BEGIN
IF (@.@.fetch_status <> -2)
BEGIN
DECLARE @.message varchar(800)
SELECT @.message = 'SET QUOTED_IDENTIFIER ON DBCC DBREINDEX (''' + @.name + ''', '''', 90)'
EXEC (@.message)
END
FETCH NEXT FROM tablename INTO @.name
END

CLOSE tablename
DEALLOCATE tablename
GO
Please file a bug using the MSDN Product Feedback Center. And mention the OS platform, server versions, number of tables in the database etc.|||Bug report created

Thanks
Peter