Since it's Friday, I was looking for another poll and this one seemed to fit nicely. Plus since I know quite a few Microsoft guys at least glance at this daily non-sensical portion of the newsletter, I thought maybe we could get some real suggestions. So the poll is:
What Do You Most Dislike About SQL Server 2005?
Or SQL 2000 for that matter, but since the next version of SQL Server (code-named Nirvana) is underway, it might make some sense to try and influence the product early on. So what really bugs you, makes you less productive, doesn't work the way you want it, etc.
As usual, I'll start it out and give you my feedback. There are a number of things that I have really grown to like in SQL Server 2005 as I work with it more and more. I haven't used some of the really cool features or tested them, but I have been spending more time in Management Studio and there's something I don't like.
Before I give you my item, a little background. I love notepad and wordpad. And I used them often for quick notes and editing on servers or unfamiliar machines because they start quickly, are lightweight and respond without hanging. For my main work, I tend to prefer Edit Plus on my desktop and laptop and it works the same way. I prefer these programs over larger, bloated programs that are slow to start, spawn background threads, and are just heavy in their implementation.
Management Studio tends to fall into this category. It's big and slow and cumbersome to use. My old Start Menu, up arrow 3 times, Enter (on Run), i-s-q-l-w Enter sequence isn't available on 2005 and it's annoying. I like a very small query tool and I wish SQL Server 2005 had included one. So deliver a standalone query tool for Nirvana.
It's not like we don't have lots of programs already in the SQL Server 2005 group(s). One more won't hurt.
Ooo, fun. This could go on for ages.
My bug bear is an SSMS thing as well. You used to be able to script out a whole bunch of tables at the same time and each script would appear in a seperate file. You can't do that anymore (as far as I know).
And yes, it IS bloated. It used to annoy me when I first got hold of the product. I don't notice it any more. Funny that!
I'm just waiting for the first "The import wizard has gotten worse" post
P.S. I thought the next version was called Katmai?
My gripe is more a Reporting Services thing, but it does spill over to SQL proper and it's to do with international date formats. I think there must be plenty of developers at Microsoft that don't realise that the US date format is not the only format!
The preview mode in SSRS (and RS 2000 for that matter) just can't cope with European formats (i.e. dd/mm/yyyy) if they don't look like a valid US date regardless of locale settings. It's fine when deployed, thankfully. This is a problem I've reported when beta testing previously. Date handling in SQL can be a bit hit and miss in SQL too - I'm never quite 100% certain how something like '01/03/2006' will be interpreted, despite setting locales. 1st of March or 3rd of January?
I got so paranoid at one point, that I when hard coding dates I did it as 'yyyy/mm/dd' thinking that it couldn't be mis-interpreted. But then SSIS went and treated it as 'yyyy/dd/mm' because as a UK date it assumed the day and month had to be swapped -
Hello Chris. My 100% support for your arguments! It's been annoying for years and it still is.
But - as I found out, even a lot of experienced developers don't know, that passing an 8-digit string (without any formatting characters) ALWAYS interprets as YYYYMMDD. I mostly resort to this.
CREATE PROCEDURE TEST(@myDate AS DATETIME) ...
called as TEST('20050301') will always be correct (march 1st). And there's no problem in any frontend-app to strip any formatting out (e.g. .,/)
The drawback to this approach is when it comes to time-parts. Unfortunately, there's no analogous 'general time format', eg. ('20050301123412999'). That would be great until the ISO-committe finally agrees on world wide date format which is designated to happen in 2083, as my great-grandfather told me 20 years ago.
PS: As for the clumsiness Steve is talking about: I left Query Analyzer installed. And that's what I use in 99%.
Just another vote for some serious work to be done on Management Studio.
+ like everyone else, I agree it's really, really, really slow and cumbersome
+ right-click madness... not exactly intuitive that sometimes the only way to perform an action is to do your standard tree-node-drilldown, then right-click. I'm not sure why that's such a cool feature but that it's the ONLY way to do things, is maddening and is killing my carpel-tunnel.
+ window positions and sizes are not retained. So agai, you have to expend wrist/mouse action to resize window, but the minute you close it, all is lost. I would say the same thing applies to things like certain "settings". For example, if I want the window refreshed every 20 seconds, that setting should always stick.
All these things seem like nits, but if you have to actually sit at your computer using SSMS for a whole day, they're annoying, frustrating, time-consuming.... all productivity killers.
On another note, from a programmatic perspective....
+ Integration of CLR... well not really. Sure, you can use .NET code in SQL now. But the scenario is one of those "what are you thinking?" So, my dev team has a one or more core classes that they've written that's used by our various web and console apps. This is great because we can truly control and encapsulate logic. Now, *in theory*, I can use that code in SQL too, except it's completely disjointed/disconnected. You have to import the code, and immediately, you've got a branch in the road you have to manage. So, when the dev team redeploys their DLL, it's NOT done, because now someone has to go update it in SQL too. Plus you have to do all that footwork to wire it up to SQL functions in addition...
I don't see why SQL should be such a closed environment environment anymore. Even though I use Visual Studio to create SSIS packages, and SSMS is somewhat of a Visual studio environment itself, the experience couldn't be more foreign and completely unnatural to someone developing in .NET.
This one is pretty obvious, but if the default scripting behavior is no longer going to be to create the if exists - drop statements, at least leave it as an option. Our entire shop depends on that feature of EM.
And along those lines, would it kill SSMS to remember my preferences from the last time that I scripted something? There is a good chance I'm going to want to do it the same way each time and digging through all the options each time is a killer.
Blog | Twitter | LinkedIn
BeachDBA - you've nailed it. Couldn't agree more!
There was a bit of tongue in cheek joking about not being able to change colors in EM etc, but that brings me to an actual annoyance with EM (in 2000 at least)... SQL is entered in proportional font and I don't know of any way to change that.
Writing code (especially string oriented stuff like SQL) in anything other than monospaced font (courier etc) causes eye damage.
How about right clicking on a table and pulling back the top N rows. A lot of times I like to see some of the actual data when I write a query. The only way I've seen to do this in 2005 is to right-click and open the entire table (which if you have more than a couple of thousand rows, starts to get prohibitively time consuming), then edit the query and put a top n clause in it, but by then , you have already waited for the entire table to be returned.
Maybe I'm missing something...