|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
2000 Enterprise Manager vs. 2005Though most of the changes we might be able to get used to, there is
one super annoying change we have not found the equivalent to: What is the equivalent of using the 2000 EM Right-Click--->Open--->Query method in 2005 ES? That was always the safest and fastest way to access very specific record(s) to change value(s) in a table. The 2005 implementation makes you wade through the whole dataset to do this, not just slow, but dangerous (at best). > What is the equivalent of using the 2000 EM That is not the safest way and is often problematic and NOT fast, depending > Right-Click--->Open--->Query method in 2005 ES? That was always the > safest and fastest way to access very specific record(s) to change > value(s) in a table. on the table design and the size of the table. It often doesn't even work if the GUI can't uniquely identify the row you're modifying. http://tinyurl.com/ylojsb http://tinyurl.com/ykmveg I would go so far as to argue that this is the LEAST safe way to modify your data -- though I'm sure plenty of people can find worse practices. :-) > The 2005 implementation makes you wade through Do you think OPEN TABLE is doing anything different than reading a "whole > the whole dataset to do this, not just slow, but dangerous (at best). dataset"? How about opening a query window, and typing: SELECT <columns> FROM <table> WHERE <clause>; Or right-clicking the table name in Object Explorer, Script Table As, SELECT To > New Query Editor Window. Press F5. Now that you are sure you have the right row(s), change to: BEGIN TRANSACTION; UPDATE <table> SET <column> = <value> --, ...n WHERE <clause>; /* COMMIT TRANSACTION; ROLLBACK TRANSACTION; */ When you are sure you have modified the right rows in the right way, highlight the commit line and hit F5. Or, if you goofed up, highlight the rollback line and hit F5. SQL Server is not Excel. You should not be striving to open/view/modify data in a GUI that potentially holds locks on the table while you are doing so. Well in the cases one is modifying data, it is a very simple
modification (a single value) to record(s) that will not be modified by any other user or task while the selection is open. Very often, one is adding a single row to a simple table in which case one is saving an extreme amount of time. Contrary what you may have experienced, it has always been very fast and very reliable, regardless of the table size. I'm going back years of using ver 7 and 2000 at over 100 different sites. Naturally, simplicity and reliability for such things come from applying KISS principles to the way one designs the tables and their relationships in the first place, so this would be a factor if the structure was complex. So it sounds like they removed the capability and one can only open the entire table. Oh well, just more typing and a longer hour-glass to get to same end. This is a case where one wishes they were paid by the hour and not by results. Aaron Bertrand [SQL Server MVP] wrote: Show quote > > What is the equivalent of using the 2000 EM > > Right-Click--->Open--->Query method in 2005 ES? That was always the > > safest and fastest way to access very specific record(s) to change > > value(s) in a table. > > That is not the safest way and is often problematic and NOT fast, depending > on the table design and the size of the table. It often doesn't even work > if the GUI can't uniquely identify the row you're modifying. > > http://tinyurl.com/ylojsb > http://tinyurl.com/ykmveg > > I would go so far as to argue that this is the LEAST safe way to modify your > data -- though I'm sure plenty of people can find worse practices. :-) > > > The 2005 implementation makes you wade through > > the whole dataset to do this, not just slow, but dangerous (at best). > > Do you think OPEN TABLE is doing anything different than reading a "whole > dataset"? > > How about opening a query window, and typing: > > SELECT <columns> FROM <table> WHERE <clause>; > > Or right-clicking the table name in Object Explorer, Script Table As, SELECT > To > New Query Editor Window. > > Press F5. Now that you are sure you have the right row(s), change to: > > BEGIN TRANSACTION; > UPDATE <table> > SET <column> = <value> --, ...n > WHERE <clause>; > /* > COMMIT TRANSACTION; > ROLLBACK TRANSACTION; > */ > > When you are sure you have modified the right rows in the right way, > highlight the commit line and hit F5. Or, if you goofed up, highlight the > rollback line and hit F5. > > SQL Server is not Excel. You should not be striving to open/view/modify > data in a GUI that potentially holds locks on the table while you are doing > so. > Very often, one Really? Have you tried right-clicking the table, Script Table As > Insert > is adding a single row to a simple table in which case one is saving an > extreme amount of time. To > New Query Window? Have you considered automating the creation of CRUD stored procedures for all of your base tables? It doesn't seem very intuitive to me to want to open a query window, then write a SELECT statement, then manually point and click to add a row, entering the data, and hoping you get your datatypes right (including figuring out whether Management Studio wants "true/false" or 1/0 for BIT columns). All of this to INSERT a row? That's what an INSERT statement is for. Again, try to stop thinking about SQL Server as "Excel with spinach." A I think what you are doing in Enterprise Manager has an equivilant in
Management Studio of: 1) Right-click Views, and then click New View. 2) Select the table, click Add, and then click Close. That's looks like the same thing I get in Enterprise Manager, unless I misunderstand what you are doing. -- Show quoteRick Byham, MS This posting is provided "AS IS" with no warranties, and confers no rights. "Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message news:%23Cv18yXDHHA.3520@TK2MSFTNGP04.phx.gbl... >> Very often, one >> is adding a single row to a simple table in which case one is saving an >> extreme amount of time. > > Really? Have you tried right-clicking the table, Script Table As > Insert > To > New Query Window? Have you considered automating the creation of > CRUD stored procedures for all of your base tables? > > It doesn't seem very intuitive to me to want to open a query window, then > write a SELECT statement, then manually point and click to add a row, > entering the data, and hoping you get your datatypes right (including > figuring out whether Management Studio wants "true/false" or 1/0 for BIT > columns). All of this to INSERT a row? That's what an INSERT statement > is for. > > Again, try to stop thinking about SQL Server as "Excel with spinach." > > A > >I think what you are doing in Enterprise Manager has an equivilant in And do you really recommend this as a "safe, efficient way to update data in >Management Studio of: > 1) Right-click Views, and then click New View. > 2) Select the table, click Add, and then click Close. > That's looks like the same thing I get in Enterprise Manager, unless I > misunderstand what you are doing. SQL Server"?  |
|||||||||||||||||||||||
Other interesting topics