Showing posts with label aware. Show all posts
Showing posts with label aware. Show all posts

Wednesday, March 28, 2012

Moving a SQL Server to a new domain?

Can anyone point me in the right direction here?
What do I need to be aware of when moving a SQL 2000 server from a 2000 to a
different 2003 domain (not upgrading the existing domain)? The server has
roughly 40 SQL users and they are all configured to use SQL Authentication.
Is it as simple as removing the server from one domain and joining the other
with some possible workstation configuration changes to reflect the new FQDN?
Thanks in advance!If it was 6.5, then you would have lots of work. But 2000 is fairly
transparent. The only thing you can have to do is recreate the login because
their GUID changed on the new domain.
--
Mohit K. Gupta
B.Sc. CS, Minor Japanese
MCTS: SQL Server 2005
"FombyJambox" wrote:
> Can anyone point me in the right direction here?
> What do I need to be aware of when moving a SQL 2000 server from a 2000 to a
> different 2003 domain (not upgrading the existing domain)? The server has
> roughly 40 SQL users and they are all configured to use SQL Authentication.
> Is it as simple as removing the server from one domain and joining the other
> with some possible workstation configuration changes to reflect the new FQDN?
> Thanks in advance!

Friday, March 23, 2012

moved from ms sql 2000 to ms sql2005

database has been recently upgraded from ms sql 2000 to ms sql 2005.
are there anything I need to be aware after upgrading to ms sql 2005?

for my experience, i got an error if i use column alias in ORDER BY
clause which was fine on ms sql 200.

thanksHandersonVA (handersonva@.hotmail.com) writes:

Quote:

Originally Posted by

database has been recently upgraded from ms sql 2000 to ms sql 2005.
are there anything I need to be aware after upgrading to ms sql 2005?


Run sp_updatestats on all databases, since statistics from SQL 2000 are
invalidated with the upgrade.

Quote:

Originally Posted by

for my experience, i got an error if i use column alias in ORDER BY
clause which was fine on ms sql 200.


It's fine in SQL 2005 too. However, there were bugs in SQL 2000 which lead
to incorrect code being accepted. For instance in SQL 2000 you can
say:

SELECT name FROM sysobjects ORDER BY myownalias.name

This is correctly rejected in SQL 2005. There are a couple of variations
on this theme.

Another issue that has bitten more that one is that they had views
like:

CREATE VIEW myview AS
SELECT TOP 100 PERCENT ...
ORDER BY somecol

then they expect "SELECT ... FORM myview" to always return data ordered
by somecol. SQL 2000 usually honors that, which is mere chance. On
SQL 2005 you are less lucky. The moral is that you should always
specify an ORDER BY clause on SELECT statements that produces data.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspxsql

Monday, March 12, 2012

Move RS database to a new computer

we are aware of KB84245 Titled:
"How to move a Reporting Servides database from a computer that is running
Reporting Services to another computer".
this seems rather clear. But I have I a question.
Does this article assume the original DB is on the web server machine, and
if so would these
exact instructions apply to mvoing a database in a multi-tier arrangement.
By which I mean: in our case we have a Web Server and a Database Server.
The Web Server Hosts ReportingSservices and the Database Server hosts the
ReportingService DBs. We are moving our reportingservice DB to a different
database server.
are there additional/different instructions I should follow for a move in a
multi-tier arrangement? Are is this KB good to go for all situations?
thanks.
dlrHi Dennis,
I just successfully moved a RS database to a new server in a 2-tiered
environment, and the MS instructions worked perfectly. I backed up the 2
dbs to files, then restored them to the new db server. Then on the IIS
machine, I used rsconfig utility to reconfigure the db location/connection
info. I moved the reportserver component to a new IIS machine as well, so I
had to backup/restore the encryption keys, too - but I don't think you'll
have to do that, as you're not moving the reportserver.
--
Regards,
Jake Marx
MS MVP - Excel
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
Dennis Redfield wrote:
> we are aware of KB84245 Titled:
> "How to move a Reporting Servides database from a computer that is
> running Reporting Services to another computer".
> this seems rather clear. But I have I a question.
> Does this article assume the original DB is on the web server
> machine, and if so would these
> exact instructions apply to mvoing a database in a multi-tier
> arrangement.
> By which I mean: in our case we have a Web Server and a Database
> Server. The Web Server Hosts ReportingSservices and the Database
> Server hosts the ReportingService DBs. We are moving our
> reportingservice DB to a different database server.
> are there additional/different instructions I should follow for a
> move in a multi-tier arrangement? Are is this KB good to go for all
> situations?
> thanks.
> dlr|||well i did have problems. I moved the RS databases to a new server (which
was a clean SQL Server install with no prior RS history). and indeed
everything seemed to work fine until I got permission errors when attempting
a snap-shot execution. The problem:
RS creates an RSExecRole in the databases it creates AND in the master
database and adds your connection user to those roles. On the databases
moved to the new server theRSExecRole move along with the restore. The
master database on the new machine is not restored from anywhere, of course,
and thus IT DOES NOT HAVE THE RSExecRole. If you are using the prinicple of
least previlge and use a RS database connection user with few intrinsic
rights you will see the permission error. Solution: manually create the
RSExecRole in "master" and manually add your connection user to this role.
Easy but not fun in a disaster recovery situation.
dlr
"Jake Marx" <msnews@.longhead.com> wrote in message
news:OPxDc7PvEHA.1452@.TK2MSFTNGP11.phx.gbl...
> Hi Dennis,
> I just successfully moved a RS database to a new server in a 2-tiered
> environment, and the MS instructions worked perfectly. I backed up the 2
> dbs to files, then restored them to the new db server. Then on the IIS
> machine, I used rsconfig utility to reconfigure the db location/connection
> info. I moved the reportserver component to a new IIS machine as well, so
I
> had to backup/restore the encryption keys, too - but I don't think you'll
> have to do that, as you're not moving the reportserver.
> --
> Regards,
> Jake Marx
> MS MVP - Excel
> www.longhead.com
> [please keep replies in the newsgroup - email address unmonitored]
>
> Dennis Redfield wrote:
> > we are aware of KB84245 Titled:
> > "How to move a Reporting Servides database from a computer that is
> > running Reporting Services to another computer".
> >
> > this seems rather clear. But I have I a question.
> >
> > Does this article assume the original DB is on the web server
> > machine, and if so would these
> > exact instructions apply to mvoing a database in a multi-tier
> > arrangement.
> >
> > By which I mean: in our case we have a Web Server and a Database
> > Server. The Web Server Hosts ReportingSservices and the Database
> > Server hosts the ReportingService DBs. We are moving our
> > reportingservice DB to a different database server.
> >
> > are there additional/different instructions I should follow for a
> > move in a multi-tier arrangement? Are is this KB good to go for all
> > situations?
> >
> > thanks.
> >
> > dlr
>