>In what circumstances would admin of one DB require all DBs to be down in a way that having them on

>different instances wouldnt? Obviously restarting the  server would take all...

Here's one way to do it by a selfjoin.

There's a drawback, though, in that using a function in the join will invalidate indexusage,

so there may not be the best performance...

Well... maybe... But since it seems to be a bug, and also may be related to memory conditions, it's not certain that all the necessary conditions to provoke the bug...

There seems to be a few scenarios that may produce this error text.

http://support.microsoft.com/kb/896980 is one of them.

If you google on Query Processor could not produce a query plan, you'll a...

It seems like the question is more: Which recovery model do you curerntly have? And which recovery model is it that you 'should' have? This question needs an answer before...

Tibor has written a very nice article on the subject -

'Why you want to be restrictive with shrink of database files'.

http://www.karaszi.com/SQLServer/info_dont_shrink.asp

It's well worth the time reading.

/Kenneth

Without knowing anything about those databases, it's likely that the 'best' would be as separate db's in a single instance.

There's a lot of considerations, such as:

What these databases really...

Spid 9 is involved in an autoshrink operation.

This is general a 'bad idea' to have turned on, so you should consider to turn this option off for this database.

Spid 59...

Ray...?

You don't need to create/drop tables if there is no clustered index on the table you want to move.

It's enough to just create a clustered index on the table on...

-- quote BOL --

Filegroups can be created when the database is first created or later when more files are added to the database. However, it...

Ok.. I think it's slowly sinking in... Didn't read that closely in the example data given..

The table C - that one already exists? Is that it?

So the emps are already...

ummm... I don't quite get it...

Are you now saying that depending on the actual count of emps between different departments, you could end up with 'new' names like 200 and...

You're doing a lot of concatenations...

Could it be that some of the concatenated values are NULL, and you're session have CONCAT_NULL_YIELDS_NULL ON ...?

If so, that could explain the 'lost' rows.

/Kenneth

Don't think it can be much clearer, can it?

/Kenneth

1.) The process of making your system run and work 'smoother and better'.

2.) The process of finding a problem/error.

/Kenneth