Showing posts with label upgrading. Show all posts
Showing posts with label upgrading. Show all posts

Friday, February 24, 2012

after upgrading to sept ctp 2005 reports with subreports fail

I just installed September 2005 CTP and all reports with subreports
getting an error:
Error occured during local report processing. An internal error occured
on the report server.
If i delete subreports everything is fine. The error log says
following:
09/15/05 07:55:10, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
AdjustTokenPrivileges () failed (00000514)
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
4 supplied
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 3444
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
= 0x0
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x47405858
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
ExceptionRecordPtr = 0x00000000
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
= <NULL>
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
not used
09/15/05 07:55:15, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
not used
09/15/05 07:55:15, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
Services\LogFiles\SQLDmpr0001.mdmp
09/15/05 07:55:15, ACTION, aspnet_wp.exe, Watson Invoke: No
09/15/05 08:15:42, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
AdjustTokenPrivileges () failed (00000514)
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
4 supplied
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 3444
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
= 0x0
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x11A21E9C
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
ExceptionRecordPtr = 0x00000000
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
= <NULL>
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
not used
09/15/05 08:15:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
not used
09/15/05 08:15:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
Services\LogFiles\SQLDmpr0002.mdmp
09/15/05 08:15:45, ACTION, aspnet_wp.exe, Watson Invoke: No
09/15/05 08:23:14, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
AdjustTokenPrivileges () failed (00000514)
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
4 supplied
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 2732
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
= 0x0
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x10B35858
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
ExceptionRecordPtr = 0x00000000
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
= <NULL>
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
not used
09/15/05 08:23:16, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
not used
09/15/05 08:23:16, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
Services\LogFiles\SQLDmpr0003.mdmp
09/15/05 08:23:16, ACTION, aspnet_wp.exe, Watson Invoke: No
Any ideas?
Everything was fine in June CTP versionDid you upgrade the June CTP or did you remove everything (including the
dotnet 2.0 framework beta) first?
This CTP does not upgrade, you have to remove everything first and then
install.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<bosstan1@.gmail.com> wrote in message
news:1126801637.855296.186610@.g49g2000cwa.googlegroups.com...
>I just installed September 2005 CTP and all reports with subreports
> getting an error:
> Error occured during local report processing. An internal error occured
> on the report server.
> If i delete subreports everything is fine. The error log says
> following:
> 09/15/05 07:55:10, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
> AdjustTokenPrivileges () failed (00000514)
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
> 4 supplied
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID => 3444
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
> = 0x0
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr => 0x47405858
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir => <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
> ExceptionRecordPtr = 0x00000000
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr => 0x00000000
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile => <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
> = <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName => <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
> not used
> 09/15/05 07:55:15, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
> not used
> 09/15/05 07:55:15, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
> completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
> Services\LogFiles\SQLDmpr0001.mdmp
> 09/15/05 07:55:15, ACTION, aspnet_wp.exe, Watson Invoke: No
> 09/15/05 08:15:42, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
> AdjustTokenPrivileges () failed (00000514)
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
> 4 supplied
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID => 3444
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
> = 0x0
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr => 0x11A21E9C
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir => <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
> ExceptionRecordPtr = 0x00000000
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr => 0x00000000
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile => <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
> = <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName => <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
> not used
> 09/15/05 08:15:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
> not used
> 09/15/05 08:15:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
> completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
> Services\LogFiles\SQLDmpr0002.mdmp
> 09/15/05 08:15:45, ACTION, aspnet_wp.exe, Watson Invoke: No
> 09/15/05 08:23:14, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
> AdjustTokenPrivileges () failed (00000514)
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
> 4 supplied
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID => 2732
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
> = 0x0
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr => 0x10B35858
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir => <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
> ExceptionRecordPtr = 0x00000000
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr => 0x00000000
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile => <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
> = <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName => <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
> not used
> 09/15/05 08:23:16, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
> not used
> 09/15/05 08:23:16, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
> completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
> Services\LogFiles\SQLDmpr0003.mdmp
> 09/15/05 08:23:16, ACTION, aspnet_wp.exe, Watson Invoke: No
> Any ideas?
> Everything was fine in June CTP version
>|||removed everything twice and reinstalled|||I just created one (report/subreport). I suggest trying recreating the
report from scratch (or at least the subreport and then re-embed it).
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<bosstan1@.gmail.com> wrote in message
news:1126803423.272541.149830@.g47g2000cwa.googlegroups.com...
> removed everything twice and reinstalled
>|||that what i did also. did not help.
here is another hint:
if i put this subreport under the group footer (or header) that i want,
report fails.
If i move subreport to different group header it works.|||If you email me the rdl and rdl.data files for both report and subreport I
will see about getting it to the correct person at MS. Just remove NOSPAM
from my email address.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<bosstan1@.gmail.com> wrote in message
news:1126807105.990018.151820@.z14g2000cwz.googlegroups.com...
> that what i did also. did not help.
> here is another hint:
> if i put this subreport under the group footer (or header) that i want,
> report fails.
> If i move subreport to different group header it works.
>|||before I'll do this try to reproduce it this way:
create report with 4 groups:
Group1
Group2
Group3
Group4
create subreport
put subreport under group 4 (or 3, header, footer, detail - does not
matter)
report will not run (at least for me)
if you put it inder group 1 or 2, report will work in Sept CTP 2005
package|||Great repro. I will pass it on to MS.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<bosstan1@.gmail.com> wrote in message
news:1126879282.885405.84350@.g47g2000cwa.googlegroups.com...
> before I'll do this try to reproduce it this way:
> create report with 4 groups:
> Group1
> Group2
> Group3
> Group4
> create subreport
> put subreport under group 4 (or 3, header, footer, detail - does not
> matter)
> report will not run (at least for me)
> if you put it inder group 1 or 2, report will work in Sept CTP 2005
> package
>|||now, i think i know what really happened:
I have 4 groups
Group1
Group2
Group3
Group4
if one of the values for Group4 ( in my case Group3 also) will be null,
subreport that you will put under this group will make main report to
fail. And it happens only in Sept CTP 2005 package|||Great, I'll make sure someone gets this.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
<bosstan1@.gmail.com> wrote in message
news:1126887557.215825.300160@.f14g2000cwb.googlegroups.com...
> now, i think i know what really happened:
> I have 4 groups
> Group1
> Group2
> Group3
> Group4
> if one of the values for Group4 ( in my case Group3 also) will be null,
> subreport that you will put under this group will make main report to
> fail. And it happens only in Sept CTP 2005 package
>|||hi, i have hit this same problem as well. has a fix or workaround been
identified yet?
thanks,
steve
"bosstan1@.gmail.com" wrote:
> I just installed September 2005 CTP and all reports with subreports
> getting an error:
> Error occured during local report processing. An internal error occured
> on the report server.
> If i delete subreports everything is fine. The error log says
> following:
> 09/15/05 07:55:10, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
> AdjustTokenPrivileges () failed (00000514)
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
> 4 supplied
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID => 3444
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
> = 0x0
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr => 0x47405858
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir => <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
> ExceptionRecordPtr = 0x00000000
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr => 0x00000000
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile => <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
> = <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName => <NULL>
> 09/15/05 07:55:10, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
> not used
> 09/15/05 07:55:15, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
> not used
> 09/15/05 07:55:15, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
> completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
> Services\LogFiles\SQLDmpr0001.mdmp
> 09/15/05 07:55:15, ACTION, aspnet_wp.exe, Watson Invoke: No
> 09/15/05 08:15:42, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
> AdjustTokenPrivileges () failed (00000514)
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
> 4 supplied
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID => 3444
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
> = 0x0
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr => 0x11A21E9C
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir => <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
> ExceptionRecordPtr = 0x00000000
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr => 0x00000000
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile => <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
> = <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName => <NULL>
> 09/15/05 08:15:42, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
> not used
> 09/15/05 08:15:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
> not used
> 09/15/05 08:15:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
> completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
> Services\LogFiles\SQLDmpr0002.mdmp
> 09/15/05 08:15:45, ACTION, aspnet_wp.exe, Watson Invoke: No
> 09/15/05 08:23:14, ERROR , SQLDUMPER_UNKNOWN_APP.EXE,
> AdjustTokenPrivileges () failed (00000514)
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters:
> 4 supplied
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID => 2732
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags
> = 0x0
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr => 0x10B35858
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir => <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE,
> ExceptionRecordPtr = 0x00000000
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr => 0x00000000
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile => <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName
> = <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName => <NULL>
> 09/15/05 08:23:14, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11
> not used
> 09/15/05 08:23:16, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7
> not used
> 09/15/05 08:23:16, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump
> completed: D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting
> Services\LogFiles\SQLDmpr0003.mdmp
> 09/15/05 08:23:16, ACTION, aspnet_wp.exe, Watson Invoke: No
> Any ideas?
> Everything was fine in June CTP version
>|||Has anyone found a solution to this? I am running into the same issues.
"Bruce L-C [MVP]" wrote:
> Great, I'll make sure someone gets this.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> <bosstan1@.gmail.com> wrote in message
> news:1126887557.215825.300160@.f14g2000cwb.googlegroups.com...
> > now, i think i know what really happened:
> > I have 4 groups
> > Group1
> > Group2
> > Group3
> > Group4
> >
> > if one of the values for Group4 ( in my case Group3 also) will be null,
> > subreport that you will put under this group will make main report to
> > fail. And it happens only in Sept CTP 2005 package
> >
>
>

After upgrading to 2005, update and add no longer work in ASP pages.

Upgraded to SQL 2005 and now I get the following error when trying to add or update a record

Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[Microsoft][ODBC SQL Server Driver][SQL Server]Could not find server 'NS1' in sysservers. Execute sp_addlinkedserver to add the server to sysservers.

/manage/inc_post_events.asp, line 57

The setup is one server running Windows Server 2000 with IIS and SQL 2005 installed. We previously had SQL 2000 and no issues. Now we cant add new records or update records. Anyone have any ideas? When looking in the tables, I notice in one database, some tables have a schema of dbo and some of a username.... HELP!Probably the wrong forum for this but:

Whats the name of the machine that you upgraded?
is it NS1?

If it is. . . did you name 2005 instance, or leave it as default?

Lets see a simple example of some update SQL that doesnt work

as far as schema names, db objects belong to the schema of the user who created them unless the user explictly declares the schema -

user 'foo' logs in

foo executes:
CREATE TABLE [BAR](i int)
CREATE TABLE [dbo].[BAR](i int)

now there are two tables:

[FOO].[BAR] & [DBO].[BAR]
lastly. . . Why are you using ODBC? SLOWWWWWWWWWWW and faulty!

Thursday, February 16, 2012

After MSDE upgrade to SQL 2005, MDF is not found

After upgrading an MSDE 2000 instance to SQL 2005, the database appears to be intact - according to the log file:

2007-08-28 13:51:13.78 spid11s Starting up database 'HysterSuiteMainSQL'.

Then after a system shutdown:

2007-08-28 13:57:43.57 Server SQL Server is terminating because of a system shutdown. This is an informational message only. No user action is required.

It appears the MDF file disappeared mysteriously:

2007-08-28 14:03:11.84 spid51 Starting up database 'HysterSuiteMainSQL'.
2007-08-28 14:03:11.85 spid51 Error: 17207, Severity: 16, State: 1.
2007-08-28 14:03:11.85 spid51 FCB:Surprisepen: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'C:\PROGRAM FILES\HYSTER SUITE\MSDE\Data\MSSQL$HS2000\Data\Hyster.mdf'. Diagnose and correct the operating system error, and retry the operation.

Has anyone encountered this issue? Any ideas on what might have gone wrong?

Thanks,

Mike

After upgrading to sql 2005 did you change the startup account of sql 2005 ? if yes may be the startup account might not have modify privilege to the path where the mdf and ldf resides........as the error is explicit that its related to permission.....

Thursday, February 9, 2012

Advice on upgrading 2000 to 2005 needed

Hi,
I've read through the threads related to 2000-2005 upgrade I can find on
this newsgroup. From what I've gathered, seems there are the following three
ways to upgrade.
1. in place
2. install a new instance that runs 2005 on the same database server
3. Set up a different server and then install 2005 on it.
We're currently running SQL 2000 SP3 on windows 2003. Is it true that
installing SP4 on SQL 2000 is required before it can be brought up to 2005
for in place upgrade?
For the rest two, I'm not very clear which one is better.
If we do option 3, we need to make DNS changes for server IP/name move which
always doesn't happen right away in my environment. That would most likely
extend upgrade time. But the obvious benefit is in case something wrong
happens with the upgrade, I can have the original 2000 server to safely go
back to.
For option 2, would a new 2005 instance have any negative impact on the sql
2000 instance? Are them totally independent of each other? I need to know
for sure if the 2005 instance doesn't work, the 2000 still works fine.
I'd appreciate any insight or real world experience (better) regarding 2005
upgrade. Things don't always go the way as they are instructed in the doc.
Thanks,
Bing
Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
SP3.
About a side-by-side installation of SQL Server 2005, i'm currently running
on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
2005 instances; since the installation i've never had a problem.
The only important consideration in this case is: do i have sufficient RAM
for both instances? Surely you'll need to configure appropriately Min memory
and Max memory for each instance.
More: currently i'm administering my SQL Server 2000 instances from SQL
Server Management Studio.
Gilberto Zampatti
"bing" wrote:

> Hi,
> I've read through the threads related to 2000-2005 upgrade I can find on
> this newsgroup. From what I've gathered, seems there are the following three
> ways to upgrade.
> 1. in place
> 2. install a new instance that runs 2005 on the same database server
> 3. Set up a different server and then install 2005 on it.
> We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> installing SP4 on SQL 2000 is required before it can be brought up to 2005
> for in place upgrade?
> For the rest two, I'm not very clear which one is better.
> If we do option 3, we need to make DNS changes for server IP/name move which
> always doesn't happen right away in my environment. That would most likely
> extend upgrade time. But the obvious benefit is in case something wrong
> happens with the upgrade, I can have the original 2000 server to safely go
> back to.
> For option 2, would a new 2005 instance have any negative impact on the sql
> 2000 instance? Are them totally independent of each other? I need to know
> for sure if the 2005 instance doesn't work, the 2000 still works fine.
> I'd appreciate any insight or real world experience (better) regarding 2005
> upgrade. Things don't always go the way as they are instructed in the doc.
> Thanks,
> Bing
|||Thanks for the response. RAM allocation is a very good point. Our SQL
server 2000 server (Standard) which is running only one instance currently
has 2G RAM. If I install 2005 (Standard) on the save server, that will
compete with 2000 for RAM.
Bing
"Gilberto Zampatti" wrote:
[vbcol=seagreen]
> Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> SP3.
> About a side-by-side installation of SQL Server 2005, i'm currently running
> on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> 2005 instances; since the installation i've never had a problem.
> The only important consideration in this case is: do i have sufficient RAM
> for both instances? Surely you'll need to configure appropriately Min memory
> and Max memory for each instance.
> More: currently i'm administering my SQL Server 2000 instances from SQL
> Server Management Studio.
> Gilberto Zampatti
> "bing" wrote:
|||On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> Thanks for the response. RAM allocation is a very good point. Our SQL
> server 2000 server (Standard) which is running only one instance currently
> has 2G RAM. If I install 2005 (Standard) on the save server, that will
> compete with 2000 for RAM.
> Bing
>
> "Gilberto Zampatti" wrote:
>
>
>
>
>
>
> - Show quoted text -
Here is my experience in a nutshell - as much as I remember anyway. I
just did a 2000 to 2005 upgrade for 8 production databases varying
from a few hundred megs to 50 gigs.This approach with a new server
allowed us to test and to hold cutting over until we were 100% sure
everything was working. There are may ways to do this, but this how I
did it....
We built and configured a new 2005 server first. Here is the overview
of the check list:
1. Build new server with network engineers.
2. Discuss best place to keep logfiles, databases, backups etc. Do
appropriate sizing etc.
3. Decide what new services to use and get them configured and
running. EX: We are not using analysis service.
4. Configure database mail.
5. Configure alerts and get backups going for system databases etc.
6. do a backup and restore from 2000 to 2005 and get the db backup and
log maintenence jobs going. I did weekly stats update and alter index
reorganize.
7. Created all windows, sql logins on the new box - we are mixed mode.
8. This allowed us to test the apps on the new server and permissions
etc. The schema's can be troublesome. I dropped all users after
restoring and then reapplied the permissions.
9.Here was my actual cutover checklist of things the SSIS package did
a. take down apps/or web server during cutover
b.backup 2000 databases to unc path
c.resotore databases to new 2005 box from unc path.
d.drop permissions (logins, schemas, roles, users)
e. re-assign permissions as required.
f.rebuild indexes
g.set database compatibility level (90) for 2005
h.re-point all applications to new SQL instance
i.run backup and maintenence jobs to make sure all working.
j.test and run other SSIS jobs
k.detach old 2005 databases but leave on the server for awhile in case
of issues.
Kristina
|||"Kristina" wrote:

> On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> Here is my experience in a nutshell - as much as I remember anyway. I
> just did a 2000 to 2005 upgrade for 8 production databases varying
> from a few hundred megs to 50 gigs.This approach with a new server
> allowed us to test and to hold cutting over until we were 100% sure
> everything was working. There are may ways to do this, but this how I
> did it....
> We built and configured a new 2005 server first. Here is the overview
> of the check list:
> 1. Build new server with network engineers.
> 2. Discuss best place to keep logfiles, databases, backups etc. Do
> appropriate sizing etc.
> 3. Decide what new services to use and get them configured and
> running. EX: We are not using analysis service.
> 4. Configure database mail.
> 5. Configure alerts and get backups going for system databases etc.
> 6. do a backup and restore from 2000 to 2005 and get the db backup and
> log maintenence jobs going. I did weekly stats update and alter index
> reorganize.
> 7. Created all windows, sql logins on the new box - we are mixed mode.
> 8. This allowed us to test the apps on the new server and permissions
> etc. The schema's can be troublesome. I dropped all users after
> restoring and then reapplied the permissions.
> 9.Here was my actual cutover checklist of things the SSIS package did
> a. take down apps/or web server during cutover
> b.backup 2000 databases to unc path
> c.resotore databases to new 2005 box from unc path.
> d.drop permissions (logins, schemas, roles, users)
> e. re-assign permissions as required.
> f.rebuild indexes
> g.set database compatibility level (90) for 2005
> h.re-point all applications to new SQL instance
> i.run backup and maintenence jobs to make sure all working.
> j.test and run other SSIS jobs
> k.detach old 2005 databases but leave on the server for awhile in case
> of issues.
> Kristina
>
Excellent! Thanks much. We're in a similar situation. For the last step
k, I think you meant 'detach old 2000 databases', right?
Bing
|||On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> "Kristina" wrote:
>
>
>
>
>
>
>
>
>
> Excellent! Thanks much. We're in a similar situation. For the last step
> k, I think you meant 'detach old 2000 databases', right?
> Bing- Hide quoted text -
> - Show quoted text -
yes, I am a poor writer.....it wasn't really that bad to do the
upgrade. I got the wrox press SQL 2005 Administration book and it
helped tons...
Good LUCK!
|||"Kristina" wrote:

> On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> yes, I am a poor writer.....it wasn't really that bad to do the
> upgrade. I got the wrox press SQL 2005 Administration book and it
> helped tons...
> Good LUCK!
>
Glad to hear it isn't that bad. Thanks again, Kristina.
Bing

Advice on upgrading 2000 to 2005 needed

Hi,
I've read through the threads related to 2000-2005 upgrade I can find on
this newsgroup. From what I've gathered, seems there are the following three
ways to upgrade.
1. in place
2. install a new instance that runs 2005 on the same database server
3. Set up a different server and then install 2005 on it.
We're currently running SQL 2000 SP3 on windows 2003. Is it true that
installing SP4 on SQL 2000 is required before it can be brought up to 2005
for in place upgrade?
For the rest two, I'm not very clear which one is better.
If we do option 3, we need to make DNS changes for server IP/name move which
always doesn't happen right away in my environment. That would most likely
extend upgrade time. But the obvious benefit is in case something wrong
happens with the upgrade, I can have the original 2000 server to safely go
back to.
For option 2, would a new 2005 instance have any negative impact on the sql
2000 instance? Are them totally independent of each other? I need to know
for sure if the 2005 instance doesn't work, the 2000 still works fine.
I'd appreciate any insight or real world experience (better) regarding 2005
upgrade. Things don't always go the way as they are instructed in the doc.
Thanks,
BingUpgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
SP3.
About a side-by-side installation of SQL Server 2005, i'm currently running
on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
2005 instances; since the installation i've never had a problem.
The only important consideration in this case is: do i have sufficient RAM
for both instances? Surely you'll need to configure appropriately Min memory
and Max memory for each instance.
More: currently i'm administering my SQL Server 2000 instances from SQL
Server Management Studio.
Gilberto Zampatti
"bing" wrote:
> Hi,
> I've read through the threads related to 2000-2005 upgrade I can find on
> this newsgroup. From what I've gathered, seems there are the following three
> ways to upgrade.
> 1. in place
> 2. install a new instance that runs 2005 on the same database server
> 3. Set up a different server and then install 2005 on it.
> We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> installing SP4 on SQL 2000 is required before it can be brought up to 2005
> for in place upgrade?
> For the rest two, I'm not very clear which one is better.
> If we do option 3, we need to make DNS changes for server IP/name move which
> always doesn't happen right away in my environment. That would most likely
> extend upgrade time. But the obvious benefit is in case something wrong
> happens with the upgrade, I can have the original 2000 server to safely go
> back to.
> For option 2, would a new 2005 instance have any negative impact on the sql
> 2000 instance? Are them totally independent of each other? I need to know
> for sure if the 2005 instance doesn't work, the 2000 still works fine.
> I'd appreciate any insight or real world experience (better) regarding 2005
> upgrade. Things don't always go the way as they are instructed in the doc.
> Thanks,
> Bing|||Thanks for the response. RAM allocation is a very good point. Our SQL
server 2000 server (Standard) which is running only one instance currently
has 2G RAM. If I install 2005 (Standard) on the save server, that will
compete with 2000 for RAM.
Bing
"Gilberto Zampatti" wrote:
> Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> SP3.
> About a side-by-side installation of SQL Server 2005, i'm currently running
> on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> 2005 instances; since the installation i've never had a problem.
> The only important consideration in this case is: do i have sufficient RAM
> for both instances? Surely you'll need to configure appropriately Min memory
> and Max memory for each instance.
> More: currently i'm administering my SQL Server 2000 instances from SQL
> Server Management Studio.
> Gilberto Zampatti
> "bing" wrote:
> > Hi,
> >
> > I've read through the threads related to 2000-2005 upgrade I can find on
> > this newsgroup. From what I've gathered, seems there are the following three
> > ways to upgrade.
> >
> > 1. in place
> > 2. install a new instance that runs 2005 on the same database server
> > 3. Set up a different server and then install 2005 on it.
> >
> > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > for in place upgrade?
> >
> > For the rest two, I'm not very clear which one is better.
> >
> > If we do option 3, we need to make DNS changes for server IP/name move which
> > always doesn't happen right away in my environment. That would most likely
> > extend upgrade time. But the obvious benefit is in case something wrong
> > happens with the upgrade, I can have the original 2000 server to safely go
> > back to.
> >
> > For option 2, would a new 2005 instance have any negative impact on the sql
> > 2000 instance? Are them totally independent of each other? I need to know
> > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> >
> > I'd appreciate any insight or real world experience (better) regarding 2005
> > upgrade. Things don't always go the way as they are instructed in the doc.
> >
> > Thanks,
> >
> > Bing|||On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> Thanks for the response. RAM allocation is a very good point. Our SQL
> server 2000 server (Standard) which is running only one instance currently
> has 2G RAM. If I install 2005 (Standard) on the save server, that will
> compete with 2000 for RAM.
> Bing
>
> "Gilberto Zampatti" wrote:
> > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > SP3.
> > About a side-by-side installation of SQL Server 2005, i'm currently running
> > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > 2005 instances; since the installation i've never had a problem.
> > The only important consideration in this case is: do i have sufficient RAM
> > for both instances? Surely you'll need to configure appropriately Min memory
> > and Max memory for each instance.
> > More: currently i'm administering my SQL Server 2000 instances from SQL
> > Server Management Studio.
> > Gilberto Zampatti
> > "bing" wrote:
> > > Hi,
> > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > this newsgroup. From what I've gathered, seems there are the following three
> > > ways to upgrade.
> > > 1. in place
> > > 2. install a new instance that runs 2005 on the same database server
> > > 3. Set up a different server and then install 2005 on it.
> > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > for in place upgrade?
> > > For the rest two, I'm not very clear which one is better.
> > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > always doesn't happen right away in my environment. That would most likely
> > > extend upgrade time. But the obvious benefit is in case something wrong
> > > happens with the upgrade, I can have the original 2000 server to safely go
> > > back to.
> > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > 2000 instance? Are them totally independent of each other? I need to know
> > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > upgrade. Things don't always go the way as they are instructed in the doc.
> > > Thanks,
> > > Bing- Hide quoted text -
> - Show quoted text -
Here is my experience in a nutshell - as much as I remember anyway. I
just did a 2000 to 2005 upgrade for 8 production databases varying
from a few hundred megs to 50 gigs.This approach with a new server
allowed us to test and to hold cutting over until we were 100% sure
everything was working. There are may ways to do this, but this how I
did it....
We built and configured a new 2005 server first. Here is the overview
of the check list:
1. Build new server with network engineers.
2. Discuss best place to keep logfiles, databases, backups etc. Do
appropriate sizing etc.
3. Decide what new services to use and get them configured and
running. EX: We are not using analysis service.
4. Configure database mail.
5. Configure alerts and get backups going for system databases etc.
6. do a backup and restore from 2000 to 2005 and get the db backup and
log maintenence jobs going. I did weekly stats update and alter index
reorganize.
7. Created all windows, sql logins on the new box - we are mixed mode.
8. This allowed us to test the apps on the new server and permissions
etc. The schema's can be troublesome. I dropped all users after
restoring and then reapplied the permissions.
9.Here was my actual cutover checklist of things the SSIS package did
a. take down apps/or web server during cutover
b.backup 2000 databases to unc path
c.resotore databases to new 2005 box from unc path.
d.drop permissions (logins, schemas, roles, users)
e. re-assign permissions as required.
f.rebuild indexes
g.set database compatibility level (90) for 2005
h.re-point all applications to new SQL instance
i.run backup and maintenence jobs to make sure all working.
j.test and run other SSIS jobs
k.detach old 2005 databases but leave on the server for awhile in case
of issues.
Kristina|||"Kristina" wrote:
> On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> > Thanks for the response. RAM allocation is a very good point. Our SQL
> > server 2000 server (Standard) which is running only one instance currently
> > has 2G RAM. If I install 2005 (Standard) on the save server, that will
> > compete with 2000 for RAM.
> >
> > Bing
> >
> >
> >
> > "Gilberto Zampatti" wrote:
> > > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > > SP3.
> > > About a side-by-side installation of SQL Server 2005, i'm currently running
> > > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > > 2005 instances; since the installation i've never had a problem.
> > > The only important consideration in this case is: do i have sufficient RAM
> > > for both instances? Surely you'll need to configure appropriately Min memory
> > > and Max memory for each instance.
> > > More: currently i'm administering my SQL Server 2000 instances from SQL
> > > Server Management Studio.
> > > Gilberto Zampatti
> >
> > > "bing" wrote:
> >
> > > > Hi,
> >
> > > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > > this newsgroup. From what I've gathered, seems there are the following three
> > > > ways to upgrade.
> >
> > > > 1. in place
> > > > 2. install a new instance that runs 2005 on the same database server
> > > > 3. Set up a different server and then install 2005 on it.
> >
> > > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > > for in place upgrade?
> >
> > > > For the rest two, I'm not very clear which one is better.
> >
> > > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > > always doesn't happen right away in my environment. That would most likely
> > > > extend upgrade time. But the obvious benefit is in case something wrong
> > > > happens with the upgrade, I can have the original 2000 server to safely go
> > > > back to.
> >
> > > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > > 2000 instance? Are them totally independent of each other? I need to know
> > > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> >
> > > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > > upgrade. Things don't always go the way as they are instructed in the doc.
> >
> > > > Thanks,
> >
> > > > Bing- Hide quoted text -
> >
> > - Show quoted text -
> Here is my experience in a nutshell - as much as I remember anyway. I
> just did a 2000 to 2005 upgrade for 8 production databases varying
> from a few hundred megs to 50 gigs.This approach with a new server
> allowed us to test and to hold cutting over until we were 100% sure
> everything was working. There are may ways to do this, but this how I
> did it....
> We built and configured a new 2005 server first. Here is the overview
> of the check list:
> 1. Build new server with network engineers.
> 2. Discuss best place to keep logfiles, databases, backups etc. Do
> appropriate sizing etc.
> 3. Decide what new services to use and get them configured and
> running. EX: We are not using analysis service.
> 4. Configure database mail.
> 5. Configure alerts and get backups going for system databases etc.
> 6. do a backup and restore from 2000 to 2005 and get the db backup and
> log maintenence jobs going. I did weekly stats update and alter index
> reorganize.
> 7. Created all windows, sql logins on the new box - we are mixed mode.
> 8. This allowed us to test the apps on the new server and permissions
> etc. The schema's can be troublesome. I dropped all users after
> restoring and then reapplied the permissions.
> 9.Here was my actual cutover checklist of things the SSIS package did
> a. take down apps/or web server during cutover
> b.backup 2000 databases to unc path
> c.resotore databases to new 2005 box from unc path.
> d.drop permissions (logins, schemas, roles, users)
> e. re-assign permissions as required.
> f.rebuild indexes
> g.set database compatibility level (90) for 2005
> h.re-point all applications to new SQL instance
> i.run backup and maintenence jobs to make sure all working.
> j.test and run other SSIS jobs
> k.detach old 2005 databases but leave on the server for awhile in case
> of issues.
> Kristina
>
Excellent! Thanks much. We're in a similar situation. For the last step
k, I think you meant 'detach old 2000 databases', right?
Bing|||On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> "Kristina" wrote:
> > On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> > > Thanks for the response. RAM allocation is a very good point. Our SQL
> > > server 2000 server (Standard) which is running only one instance currently
> > > has 2G RAM. If I install 2005 (Standard) on the save server, that will
> > > compete with 2000 for RAM.
> > > Bing
> > > "Gilberto Zampatti" wrote:
> > > > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > > > SP3.
> > > > About a side-by-side installation of SQL Server 2005, i'm currently running
> > > > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > > > 2005 instances; since the installation i've never had a problem.
> > > > The only important consideration in this case is: do i have sufficient RAM
> > > > for both instances? Surely you'll need to configure appropriately Min memory
> > > > and Max memory for each instance.
> > > > More: currently i'm administering my SQL Server 2000 instances from SQL
> > > > Server Management Studio.
> > > > Gilberto Zampatti
> > > > "bing" wrote:
> > > > > Hi,
> > > > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > > > this newsgroup. From what I've gathered, seems there are the following three
> > > > > ways to upgrade.
> > > > > 1. in place
> > > > > 2. install a new instance that runs 2005 on the same database server
> > > > > 3. Set up a different server and then install 2005 on it.
> > > > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > > > for in place upgrade?
> > > > > For the rest two, I'm not very clear which one is better.
> > > > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > > > always doesn't happen right away in my environment. That would most likely
> > > > > extend upgrade time. But the obvious benefit is in case something wrong
> > > > > happens with the upgrade, I can have the original 2000 server to safely go
> > > > > back to.
> > > > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > > > 2000 instance? Are them totally independent of each other? I need to know
> > > > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> > > > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > > > upgrade. Things don't always go the way as they are instructed in the doc.
> > > > > Thanks,
> > > > > Bing- Hide quoted text -
> > > - Show quoted text -
> > Here is my experience in a nutshell - as much as I remember anyway. I
> > just did a 2000 to 2005 upgrade for 8 production databases varying
> > from a few hundred megs to 50 gigs.This approach with a new server
> > allowed us to test and to hold cutting over until we were 100% sure
> > everything was working. There are may ways to do this, but this how I
> > did it....
> > We built and configured a new 2005 server first. Here is the overview
> > of the check list:
> > 1. Build new server with network engineers.
> > 2. Discuss best place to keep logfiles, databases, backups etc. Do
> > appropriate sizing etc.
> > 3. Decide what new services to use and get them configured and
> > running. EX: We are not using analysis service.
> > 4. Configure database mail.
> > 5. Configure alerts and get backups going for system databases etc.
> > 6. do a backup and restore from 2000 to 2005 and get the db backup and
> > log maintenence jobs going. I did weekly stats update and alter index
> > reorganize.
> > 7. Created all windows, sql logins on the new box - we are mixed mode.
> > 8. This allowed us to test the apps on the new server and permissions
> > etc. The schema's can be troublesome. I dropped all users after
> > restoring and then reapplied the permissions.
> > 9.Here was my actual cutover checklist of things the SSIS package did
> > a. take down apps/or web server during cutover
> > b.backup 2000 databases to unc path
> > c.resotore databases to new 2005 box from unc path.
> > d.drop permissions (logins, schemas, roles, users)
> > e. re-assign permissions as required.
> > f.rebuild indexes
> > g.set database compatibility level (90) for 2005
> > h.re-point all applications to new SQL instance
> > i.run backup and maintenence jobs to make sure all working.
> > j.test and run other SSIS jobs
> > k.detach old 2005 databases but leave on the server for awhile in case
> > of issues.
> > Kristina
> Excellent! Thanks much. We're in a similar situation. For the last step
> k, I think you meant 'detach old 2000 databases', right?
> Bing- Hide quoted text -
> - Show quoted text -
yes, I am a poor writer.....it wasn't really that bad to do the
upgrade. I got the wrox press SQL 2005 Administration book and it
helped tons...
Good LUCK!|||"Kristina" wrote:
> On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> > "Kristina" wrote:
> > > On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> > > > Thanks for the response. RAM allocation is a very good point. Our SQL
> > > > server 2000 server (Standard) which is running only one instance currently
> > > > has 2G RAM. If I install 2005 (Standard) on the save server, that will
> > > > compete with 2000 for RAM.
> >
> > > > Bing
> >
> > > > "Gilberto Zampatti" wrote:
> > > > > Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
> > > > > SP3.
> > > > > About a side-by-side installation of SQL Server 2005, i'm currently running
> > > > > on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> > > > > 2005 instances; since the installation i've never had a problem.
> > > > > The only important consideration in this case is: do i have sufficient RAM
> > > > > for both instances? Surely you'll need to configure appropriately Min memory
> > > > > and Max memory for each instance.
> > > > > More: currently i'm administering my SQL Server 2000 instances from SQL
> > > > > Server Management Studio.
> > > > > Gilberto Zampatti
> >
> > > > > "bing" wrote:
> >
> > > > > > Hi,
> >
> > > > > > I've read through the threads related to 2000-2005 upgrade I can find on
> > > > > > this newsgroup. From what I've gathered, seems there are the following three
> > > > > > ways to upgrade.
> >
> > > > > > 1. in place
> > > > > > 2. install a new instance that runs 2005 on the same database server
> > > > > > 3. Set up a different server and then install 2005 on it.
> >
> > > > > > We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> > > > > > installing SP4 on SQL 2000 is required before it can be brought up to 2005
> > > > > > for in place upgrade?
> >
> > > > > > For the rest two, I'm not very clear which one is better.
> >
> > > > > > If we do option 3, we need to make DNS changes for server IP/name move which
> > > > > > always doesn't happen right away in my environment. That would most likely
> > > > > > extend upgrade time. But the obvious benefit is in case something wrong
> > > > > > happens with the upgrade, I can have the original 2000 server to safely go
> > > > > > back to.
> >
> > > > > > For option 2, would a new 2005 instance have any negative impact on the sql
> > > > > > 2000 instance? Are them totally independent of each other? I need to know
> > > > > > for sure if the 2005 instance doesn't work, the 2000 still works fine.
> >
> > > > > > I'd appreciate any insight or real world experience (better) regarding 2005
> > > > > > upgrade. Things don't always go the way as they are instructed in the doc.
> >
> > > > > > Thanks,
> >
> > > > > > Bing- Hide quoted text -
> >
> > > > - Show quoted text -
> >
> > > Here is my experience in a nutshell - as much as I remember anyway. I
> > > just did a 2000 to 2005 upgrade for 8 production databases varying
> > > from a few hundred megs to 50 gigs.This approach with a new server
> > > allowed us to test and to hold cutting over until we were 100% sure
> > > everything was working. There are may ways to do this, but this how I
> > > did it....
> >
> > > We built and configured a new 2005 server first. Here is the overview
> > > of the check list:
> > > 1. Build new server with network engineers.
> > > 2. Discuss best place to keep logfiles, databases, backups etc. Do
> > > appropriate sizing etc.
> > > 3. Decide what new services to use and get them configured and
> > > running. EX: We are not using analysis service.
> > > 4. Configure database mail.
> > > 5. Configure alerts and get backups going for system databases etc.
> > > 6. do a backup and restore from 2000 to 2005 and get the db backup and
> > > log maintenence jobs going. I did weekly stats update and alter index
> > > reorganize.
> > > 7. Created all windows, sql logins on the new box - we are mixed mode.
> > > 8. This allowed us to test the apps on the new server and permissions
> > > etc. The schema's can be troublesome. I dropped all users after
> > > restoring and then reapplied the permissions.
> > > 9.Here was my actual cutover checklist of things the SSIS package did
> > > a. take down apps/or web server during cutover
> > > b.backup 2000 databases to unc path
> > > c.resotore databases to new 2005 box from unc path.
> > > d.drop permissions (logins, schemas, roles, users)
> > > e. re-assign permissions as required.
> > > f.rebuild indexes
> > > g.set database compatibility level (90) for 2005
> > > h.re-point all applications to new SQL instance
> > > i.run backup and maintenence jobs to make sure all working.
> > > j.test and run other SSIS jobs
> > > k.detach old 2005 databases but leave on the server for awhile in case
> > > of issues.
> >
> > > Kristina
> >
> > Excellent! Thanks much. We're in a similar situation. For the last step
> > k, I think you meant 'detach old 2000 databases', right?
> >
> > Bing- Hide quoted text -
> >
> > - Show quoted text -
> yes, I am a poor writer.....it wasn't really that bad to do the
> upgrade. I got the wrox press SQL 2005 Administration book and it
> helped tons...
> Good LUCK!
>
Glad to hear it isn't that bad. Thanks again, Kristina.
Bing

Advice on upgrading 2000 to 2005 needed

Hi,
I've read through the threads related to 2000-2005 upgrade I can find on
this newsgroup. From what I've gathered, seems there are the following thre
e
ways to upgrade.
1. in place
2. install a new instance that runs 2005 on the same database server
3. Set up a different server and then install 2005 on it.
We're currently running SQL 2000 SP3 on windows 2003. Is it true that
installing SP4 on SQL 2000 is required before it can be brought up to 2005
for in place upgrade?
For the rest two, I'm not very clear which one is better.
If we do option 3, we need to make DNS changes for server IP/name move which
always doesn't happen right away in my environment. That would most likely
extend upgrade time. But the obvious benefit is in case something wrong
happens with the upgrade, I can have the original 2000 server to safely go
back to.
For option 2, would a new 2005 instance have any negative impact on the sql
2000 instance? Are them totally independent of each other? I need to know
for sure if the 2005 instance doesn't work, the 2000 still works fine.
I'd appreciate any insight or real world experience (better) regarding 2005
upgrade. Things don't always go the way as they are instructed in the doc.
Thanks,
BingUpgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 2000
SP3.
About a side-by-side installation of SQL Server 2005, i'm currently running
on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
2005 instances; since the installation i've never had a problem.
The only important consideration in this case is: do i have sufficient RAM
for both instances? Surely you'll need to configure appropriately Min memory
and Max memory for each instance.
More: currently i'm administering my SQL Server 2000 instances from SQL
Server Management Studio.
Gilberto Zampatti
"bing" wrote:

> Hi,
> I've read through the threads related to 2000-2005 upgrade I can find on
> this newsgroup. From what I've gathered, seems there are the following th
ree
> ways to upgrade.
> 1. in place
> 2. install a new instance that runs 2005 on the same database server
> 3. Set up a different server and then install 2005 on it.
> We're currently running SQL 2000 SP3 on windows 2003. Is it true that
> installing SP4 on SQL 2000 is required before it can be brought up to 2005
> for in place upgrade?
> For the rest two, I'm not very clear which one is better.
> If we do option 3, we need to make DNS changes for server IP/name move whi
ch
> always doesn't happen right away in my environment. That would most likel
y
> extend upgrade time. But the obvious benefit is in case something wrong
> happens with the upgrade, I can have the original 2000 server to safely go
> back to.
> For option 2, would a new 2005 instance have any negative impact on the sq
l
> 2000 instance? Are them totally independent of each other? I need to know
> for sure if the 2005 instance doesn't work, the 2000 still works fine.
> I'd appreciate any insight or real world experience (better) regarding 200
5
> upgrade. Things don't always go the way as they are instructed in the doc
.
> Thanks,
> Bing|||Thanks for the response. RAM allocation is a very good point. Our SQL
server 2000 server (Standard) which is running only one instance currently
has 2G RAM. If I install 2005 (Standard) on the save server, that will
compete with 2000 for RAM.
Bing
"Gilberto Zampatti" wrote:
[vbcol=seagreen]
> Upgrade supported by SQL Server 2005 include SQL Server 7.0 SP$ and SQL 20
00
> SP3.
> About a side-by-side installation of SQL Server 2005, i'm currently runnin
g
> on my laptop (2Gb RAM...) two SQL Server 2000 instances and two SQL Server
> 2005 instances; since the installation i've never had a problem.
> The only important consideration in this case is: do i have sufficient RAM
> for both instances? Surely you'll need to configure appropriately Min memo
ry
> and Max memory for each instance.
> More: currently i'm administering my SQL Server 2000 instances from SQL
> Server Management Studio.
> Gilberto Zampatti
> "bing" wrote:
>|||On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> Thanks for the response. RAM allocation is a very good point. Our SQL
> server 2000 server (Standard) which is running only one instance currently
> has 2G RAM. If I install 2005 (Standard) on the save server, that will
> compete with 2000 for RAM.
> Bing
>
> "Gilberto Zampatti" wrote:
>
>
>
>
>
>
>
>
>
>
>
> - Show quoted text -
Here is my experience in a nutshell - as much as I remember anyway. I
just did a 2000 to 2005 upgrade for 8 production databases varying
from a few hundred megs to 50 gigs.This approach with a new server
allowed us to test and to hold cutting over until we were 100% sure
everything was working. There are may ways to do this, but this how I
did it....
We built and configured a new 2005 server first. Here is the overview
of the check list:
1. Build new server with network engineers.
2. Discuss best place to keep logfiles, databases, backups etc. Do
appropriate sizing etc.
3. Decide what new services to use and get them configured and
running. EX: We are not using analysis service.
4. Configure database mail.
5. Configure alerts and get backups going for system databases etc.
6. do a backup and restore from 2000 to 2005 and get the db backup and
log maintenence jobs going. I did weekly stats update and alter index
reorganize.
7. Created all windows, sql logins on the new box - we are mixed mode.
8. This allowed us to test the apps on the new server and permissions
etc. The schema's can be troublesome. I dropped all users after
restoring and then reapplied the permissions.
9.Here was my actual cutover checklist of things the SSIS package did
a. take down apps/or web server during cutover
b.backup 2000 databases to unc path
c.resotore databases to new 2005 box from unc path.
d.drop permissions (logins, schemas, roles, users)
e. re-assign permissions as required.
f.rebuild indexes
g.set database compatibility level (90) for 2005
h.re-point all applications to new SQL instance
i.run backup and maintenence jobs to make sure all working.
j.test and run other SSIS jobs
k.detach old 2005 databases but leave on the server for awhile in case
of issues.
Kristina|||"Kristina" wrote:

> On May 18, 9:49 am, bing <b...@.discussions.microsoft.com> wrote:
> Here is my experience in a nutshell - as much as I remember anyway. I
> just did a 2000 to 2005 upgrade for 8 production databases varying
> from a few hundred megs to 50 gigs.This approach with a new server
> allowed us to test and to hold cutting over until we were 100% sure
> everything was working. There are may ways to do this, but this how I
> did it....
> We built and configured a new 2005 server first. Here is the overview
> of the check list:
> 1. Build new server with network engineers.
> 2. Discuss best place to keep logfiles, databases, backups etc. Do
> appropriate sizing etc.
> 3. Decide what new services to use and get them configured and
> running. EX: We are not using analysis service.
> 4. Configure database mail.
> 5. Configure alerts and get backups going for system databases etc.
> 6. do a backup and restore from 2000 to 2005 and get the db backup and
> log maintenence jobs going. I did weekly stats update and alter index
> reorganize.
> 7. Created all windows, sql logins on the new box - we are mixed mode.
> 8. This allowed us to test the apps on the new server and permissions
> etc. The schema's can be troublesome. I dropped all users after
> restoring and then reapplied the permissions.
> 9.Here was my actual cutover checklist of things the SSIS package did
> a. take down apps/or web server during cutover
> b.backup 2000 databases to unc path
> c.resotore databases to new 2005 box from unc path.
> d.drop permissions (logins, schemas, roles, users)
> e. re-assign permissions as required.
> f.rebuild indexes
> g.set database compatibility level (90) for 2005
> h.re-point all applications to new SQL instance
> i.run backup and maintenence jobs to make sure all working.
> j.test and run other SSIS jobs
> k.detach old 2005 databases but leave on the server for awhile in case
> of issues.
> Kristina
>
Excellent! Thanks much. We're in a similar situation. For the last step
k, I think you meant 'detach old 2000 databases', right?
Bing|||On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> "Kristina" wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Excellent! Thanks much. We're in a similar situation. For the last step
> k, I think you meant 'detach old 2000 databases', right?
> Bing- Hide quoted text -
> - Show quoted text -
yes, I am a poor writer.....it wasn't really that bad to do the
upgrade. I got the wrox press SQL 2005 Administration book and it
helped tons...
Good LUCK!|||"Kristina" wrote:

> On May 18, 11:11 am, bing <b...@.discussions.microsoft.com> wrote:
> yes, I am a poor writer.....it wasn't really that bad to do the
> upgrade. I got the wrox press SQL 2005 Administration book and it
> helped tons...
> Good LUCK!
>
Glad to hear it isn't that bad. Thanks again, Kristina.
Bing