March 23, 2006 at 6:01 pm
I saw this blog entry referenced from somewhere and as I read it, for a second I thought the guy was an idiot. Then I realized it was a joke and not too bad. I still think there's a little bitterness in some of the entries, but overall it's a nice poke fun at the product.
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.
Steve Jones
March 24, 2006 at 1:57 am
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
-Jamie
P.S. I thought the next version was called Katmai?
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson
March 24, 2006 at 4:12 am
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 -
Cheers
Chris McGuigan
March 24, 2006 at 4:28 am
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.
regards,
PS: As for the clumsiness Steve is talking about: I left Query Analyzer installed. And that's what I use in 99%.
_/_/_/ paramind _/_/_/
March 24, 2006 at 5:40 am
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.
March 24, 2006 at 5:59 am
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.
March 24, 2006 at 6:01 am
There are definitely some things I really like about the product (I call it ManStud, BTW). But there definitely are the small gripes. For example, I'm not a fan that you have to load another window to get the Job activity and other status (like the logs). I like everything in a single window. But what bugs me the most is viewing permissions or securables. EM was great to just scan through the whole list and identify who has rights to an object. But not with ManStud. Either you have to select each user separately (for objects like tables) or, as with roles, you have to actually add the securables to the window in order to see them. This assumes that you know what securables were granted in the first place. So I've taken to using EM if I ever need to look at permissions.
March 24, 2006 at 6:19 am
GOD YES!!!
BeachDBA - you've nailed it. Couldn't agree more!
-Jamie
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson
March 24, 2006 at 6:29 am
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.
...
-- FORTRAN manual for Xerox Computers --
March 24, 2006 at 6:33 am
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...
March 24, 2006 at 6:54 am
I've been ranting about this since I first came across it.
WHERE HAS COPY/ PASTE CUBE GONE?
I'm a BI developer (DBA on the side). If I want to make changes to a cube I copy/ paste a single cube, amend it, test, and apply final chages to live. 2005 has made this task so much harder and longer than it needs to be.
March 24, 2006 at 6:54 am
Have to say that I havent had the pleasure of using 2005 as much as I would like to, but I imagine when I do, I will really hate having to use a cumbersome IDE to do things I currently do in Query Analyzer. I like Query Analyzer, it is one of my favorite ways of talking to SQL server. In fact, I would much rather touch that then (say) MysqlCC or SQL*Plus (oracle's thingy). Granted, there are things that would have been nice to improve inside of Query Analyzer (for instance, making it more like GVim would be nice, but I know that the chances of that hapening are kinda like the chances of me not having to pay federal income tax next year). I suppose there are some other trivial problems with Query Analyzer, but for the most part I feel that the product is a good way of talking to SQL server and its a DAMN SHAME that they have discontinued using it. I suppose true "NIRVANA" would come from having Query Analyzer back!
But again, I never really used managment studio, so it could really rock. But from what I have seen, it closly resembles a "Database Project" in Visual Studio 2003. Yes, there are nice things about it, but ultimatly as a developer, I like some separation. I like to do my database stuff with the database, and my programming with a programming tool. I don't know that there is neccesarily a lot of room for change in that area. I like to sit down with Query Analyzer, design my database, then get a diagram using Enterprise Manager, then launch my dev environment (which these days seems to be more and more Visual Studio 2005) and then go from there. I don't see myself starting and ending in 2005, because thats not what I am comfortable with. Just my 2 (cheap) cents!
Aleksei
March 24, 2006 at 6:59 am
"Windows Key + R -> sqlwb"
That's much faster then you're method of bring up query analyzer (for that matter, of course, "Windows key + R -> isqlw")
The point is, just because you didn't read it in a "howto" somewhere doesn't mean you cann't quickly get to SSMS.
If SSMS were faster (the downside of being purely .Net, but I can live with it), and had better backward compatibility to work with SQL 2000 things (such as diagrams) I would use it all the time. I think it's nothing but an improvement, sort of those few things.
March 24, 2006 at 7:40 am
In SQL Server proper: Either create a new category of object called a Query, where we can store SQL that is capable of returning an ordered result set, or add a checkbox or a dropdown or something for a property of a View that indicates "Yes, actually return an ordered row set when I specify Order By and I am not returning data to another View within SQL Server."
March 24, 2006 at 7:56 am
I think BOL is massively improved in SS2005 but there are alot of gaps. Many pages about object properties just give the bear minimum of information and don't actually include a discussion of how the property can be used. e.g. ms-help://MS.VSCC.v80/MS.VSIPCC.v80/MS.SQLSVR.v9.en/amo9mref/html/T_Microsoft_AnalysisServices_Cardinality.htm
I make a point of using the Feedback Link whenever I come across a page like this.
-Jamie
P.S. I think the Send Feedback link in BOL is a big improvement. I have complained about things and lo and behold they have been corrected/improved in the next release.
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply