0

This has me scratching my head...

We have a WSS3.0 front-end server which connects to config and content databases on a separate SQL server (SQLA). This DB server is being decommissioned so we are moving the databases to a new server (SQLB). The databases themselves have restored to the new server, so now it's a case of rewiring WSS3.0 to see the new databases. From my research, I should be able to run:

stsadm -o renameserver -oldservername sqla -newservername sqlb

Before I do that though, I had a look at the config database to find the database connection info so I would know it had worked. What concerns me is that the dbo.Databases, dbo.Sites and dbo.VirtualServers tables are all empty!

From comparing with my WSS2.0 installation, it has all these tables populated with what I expect. I am doing all of this as SA so it's not a permissions issue.

I have checked and doubled-checked the ConfigDb connection string on the front-end server and it is indeed pointing to the same database on SQLA.

So how come my site seems to run without any of this information in the database? What will happen if I reboot my server? How will WSS3.0 know where all the databases are?

Rob King
  • 1
  • 3

1 Answers1

0

Ok, I think I've worked out what the problem was. This is my hunch...

The database layout for WSS 3.0 is a superset of the tables in WSS 2.0. In a standard (non-upgrade) install of WSS 3.0 it doesn't use the deprecated WSS 2.0 tables, but instead opts for sticking everything in the dbo.Objects table. However, when you upgrade from WSS 2.0 to WSS 3.0, the upgrade process takes the data from the dbo.Sites, dbo.Databases tables and folds it into the dbo.Objects table.

Rob King
  • 1
  • 3