[dba-SQLServer] What is going on

Jim,

I don't understand what this is doing for me.  I have just one data file
ATM.  I don't know whether that is a good thing or a bad thing.  This sounds
like the process for creating and then redistributing data amongst multiple
files.  If you are saying that it is the existence of one huge file that is
causing my slowdown, then I can certainly do that.  



I have to ask if this is as good as it gets with SQL Server.  I understand
that I am doing stuff with big tables but keerimeny.  I started the build of
a PKID field on the big table.  It tells me that "ansi nulls was not on and
it has to rebuild the table" so I do.  EM just locks up tight, won't even
redraw the screen (blank white) if you switch away and back again.  I
believe that it is hard at work but folks, this is the age of threads.

So I open another instance of EM to work with another table.  EM takes
several seconds to expand each tree (server, databases, specific database)
then when I try to expand the tables, the second instance of EM locks up
tight with an hourglass.  I mean c'mon.  This is 2006, a monster (desktop)
system and EM acts as if it is a DOS app from 1986 running on a '286 with 4
megs and swapping memory.  The second EM instance has been trying to open
the tables icon just to show me what tables are there for 20 minutes now.

To say this is discouraging to work with would be an understatement.  If
this is the best I am going to get I am going to have to look for another
database engine to work with.

And the most discouraging part is that my dual proc system is cruising along
using (average?) well under 25% of the processor while EM is locked up
tight.

Does SQl Server 2005 fix any of this?  Or should I just go look at MySQL or
Oracle personal edition.  I have to get work done on this database and it is
telling me that one job (building a field / index) on one table is all it
can handle.  And by the looks of it I will be locked out of this database
for the next 12 to 24 hours.  

Hell, ACCESS can do better than this!!!  Well, maybe not but SQL Server's
rep is taking a beating here.

John W. Colby
Colby Consulting
www.ColbyConsulting.com