December 4, 2009 at 8:43 pm
The tool constricts subsequent options, but also focuses the analysis.
Perhaps this applies here also - efficiency says you remove screws with a screwdriver, nails with a nail puller, either with a shotgun.
While we are talking about screws I think Microsoft needs to fix the problem in the thread below which is actually a two seconds problem in .NET code.
Reference MDAC, access x86 ODBC in the WOW64 directory and compile x86 but there is no valid solution in T-SQL when MDAC and the new Vista and up data access are part of SQL Server.
http://www.sqlservercentral.com/Forums/Topic827617-391-1.aspx
Kind regards,
Gift Peddie
December 5, 2009 at 9:47 am
I like the all-in-one aspects of SSMS... what I don't like is all the functionality that is no longer available. Things like easily being able to do a multiple database search for something simply by pressing F4 or things like being able to script a system proc out simple by right clicking on it as if it were a user proc (instead of having to use sp_helptext on those).
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2009 at 10:24 am
If you want the bare basics - then go with the all in one. If you want specialty tools - you will need to go with the many. I feel that the development time and effort into the individual tools greatly surpasses the bulk products and it reflects in their capabilities.
Notepad for me and btw - Where can I get one of them humongous Swiss Army knifes?
Joe
December 7, 2009 at 11:32 am
Try here: http://www.thinkgeek.com/gadgets/tools/8b97/
I'm not quite sure it's worth the price: US$999
December 8, 2009 at 5:20 am
As a DBA-by-Accident, having one tool that has almost everything that I need in it is a pleasure to work with. SSMS has that, and what it doesn't have inside, it has in a menu, like SQL Server Profiler, so I don't have to hunt for the "right" tool for the job.
As a programmer, I'm all for multiple small tools that do their specific purpose brilliantly. Hmmm... reminds me of the *nix mindset with a side-order of Anti-Bloat 🙂
As for Notepad, try Notepad++[/url]. I find that it's faster and easier to use than Notepad.
December 9, 2009 at 7:48 am
Sorry I'm late guys and gals!!!
I prefer it to be similar to the way MS has gone with configuration; layered.
MS' view of configuration (as can best be seen in MS Exchange - the first product to do it this way) is for the product to have its API (configuration, management etc) which is wrapped by PowerShell Cmdlets. Then wrap the Cmdlets with a small GUI to do that particular type of job (in configuration these are MMC snap-ins). The really handy thing is where the GUI tool has a window showing the PowerShell script it will run. Now there's a learning tool. Of course, MMC shows how you can have separate tools loaded into a common UI framework in whatever combination you prefer.
So for SQL Server, I would like to see tool windows written that wrap either PowerShell Cmdlets calling the usual DDL / DML etc or that wrap the DDL / DML etc directly (whatever is the most appropriate). It is important to show what PS / DDL / DML will be used in some way (e.g. pop-up from a button or a text box - this is just details). These windows can then be loaded into the Visual Studio shell (a la Management Studio). It would be ideal to be able to have multiple tool window configurations saved so that you can switch between roles whilst using the same Management Studio but in different ways. Obviously there will be a set of configurations that would come out of the box.
This would enable reuse of VS shell (good for MS money wise and good for use training/familiarity wise), separation of tools (you only need to learn the simple UI of the tools you use), separation of task UIs (when you switch mind set so can your tool) and it will be a great learning facility for those needing to learn scripting skills through the use of the UI (which can also be used to verify what you believe the script should be to perform a particular function).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 9, 2009 at 8:06 am
I like SSMS pretty well. Seeing a log viewer as a separate app would be great, quick and easy to check the logs. Something that would be nice for MS to do also is integrate that log view into the Windows Event Viewer console.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
December 9, 2009 at 8:16 am
How about a hybrid?
- I like the MAC's approach where you have smaller dedicated apps that are easy to find and intuitive to pick up.
- I dislike having to find things in Windows, so I usually end up preferring an integrated suite. However, I acknowledge all the previous comments about the mega-app often getting in the way.
At the end of the day, you have to click somewhere to get the result you seek. So why not ship an umbrella application that can be customised by the user to bring together all the tools they want, without preventing access to those tools directly?
Duh!
December 9, 2009 at 8:38 am
The code is there, and a wrapper to make it a separate app can't be that hard, so why not do both? Give us access to the log viewer, query editor, etc. as separate apps if we want them. Can't be that hard.
December 9, 2009 at 9:18 am
Steve Jones - Editor (12/9/2009)
The code is there, and a wrapper to make it a separate app can't be that hard, so why not do both? Give us access to the log viewer, query editor, etc. as separate apps if we want them. Can't be that hard.
Anyone who has written add-ins and so on for Visual Studio (and I'm not talking DSLs) knows that it is steeped in a COM ridden design that is a hybrid of two APIs due to the C++ COM model and the VB styled OLE Automation one (yes, I know OLE is COM).
VS is a nightmare for MS, let alone anyone else. They have rewritten the UI in WPF but lets face it, for integration purposes we are talking about the framework that it provides. That is why the MMC model should be applied, in my oh so less than humble opinion.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 9, 2009 at 11:44 am
Steve Jones - Editor (12/7/2009)
Try here: http://www.thinkgeek.com/gadgets/tools/8b97/I'm not quite sure it's worth the price: US$999
Thanks for the info Steve.
Now that is a KNIFE!
But I agree, it is not worth the price. Could you imaging using that 2.5 pound tool to adjust the little screws in your glasses?
Joe
December 9, 2009 at 11:59 am
crookj (12/9/2009)
Steve Jones - Editor (12/7/2009)
Try here: http://www.thinkgeek.com/gadgets/tools/8b97/I'm not quite sure it's worth the price: US$999
Thanks for the info Steve.
Now that is a KNIFE!
But I agree, it is not worth the price. Could you imaging using that 2.5 pound tool to adjust the little screws in your glasses?
Joe
Sure. Set it on the edge of a table, hold the glasses against it, and rotate the glasses onto the screw.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 2, 2010 at 2:50 pm
Jeff Moden (12/5/2009)
I like the all-in-one aspects of SSMS... what I don't like is all the functionality that is no longer available. Things like easily being able to do a multiple database search for something simply by pressing F4 or things like being able to script a system proc out simple by right clicking on it as if it were a user proc (instead of having to use sp_helptext on those).
Actually you can script a system proc without using sp_helptext: right click and select modify to script it (as ALTER) to a new query window (not a very good approach, as accidentally pressing the wrong button may then be embarrassing). So that functionality isn't completely lost - just the abilities to have the existence test and drop action scripted automatically instead of having to type it by hand, and to script directly to a file instead of having script then save. Even so, the loss of functionality for me about balances the added functionality, and I don't understand why useful features have been thrown away. However, what I really hate about SSMS is that it is a terrible resource hog: it is a real pain to use on a machine that happily let me work with many QA and EM windows open and Profiler running simultaneously. It's also pretty opaque, and the help for it in BOL is not a patch on what was supplied for its predecessors.
I really do feel that MS dropped the ball rather badly here - it would have been nice to have separate development and administration tools. Yes adding Query Plan import/export in XML form is great, but it would have been better done as an enhacement to Query Analyser that remained separate from the operational admin toolset. The new system may not actually be much more complex than the old, but the way everything is lumped together gives an impression of enormous complexity and this is throwing away one of the great advantages (simple UI and ease of use) of SQL Server compared to its rivals.
Tom
February 2, 2010 at 5:47 pm
Tom.Thomson (2/2/2010)
Actually you can script a system proc without using sp_helptext: right click and select modify to script it (as ALTER) to a new query window (not a very good approach, as accidentally pressing the wrong button may then be embarrassing). So that functionality isn't completely lost -
Well I'll be dipped... :blush: I'm not sure why I didn't notice that before. Thanks, Tom.
Still, it's an unwelcome change... they could have just left the old functionality in the new product... especially the f4 thing.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 14 posts - 31 through 43 (of 43 total)
You must be logged in to reply to this topic. Login to reply