JWColby
jwcolby at colbyconsulting.com
Wed Nov 1 14:11:49 CST 2006
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