|
|
Software Engineer - Red Gate Software
-
Posted Monday, May 12, 2008 2:37 PM |
For those of you with the stomach for this kind of thing,
today, for the first time, we’ve made available a bleeding edge build of a
product in development. We did admittedly trial this
with Exception Hunter 1.1, but we kept it pretty quiet because it really
was a bit of an experiment on many levels, and as expected there were a few headaches. But we're now feeling more
confident about the whole process, so I’m very pleased to be able to tell you
that you can get your hands on a very early, very rough version of ANTS
Performance Profiler 4. The build numbers will change with every version so you'll find download links in the feedback forum at:
http://www.red-gate.com/messageboard/viewforum.php?f=80Now let me be absolutely clear about this: it’s not a beta, it’s
not beta quality, it really is a just a development build, so it’s rough and it
might crash, or behave strangely sometimes. We’ve spent about an hour testing
it to ensure the installer works and that’s it… well OK, we’ve retested it about 800 times because we kept finding bugs, and we fixed
some x64 problems before we put it out, and all of that took a lot more than an
hour let me tell you, but basically it’s a build we just yanked from our build server. Being the first time round though we wanted to make sure it wouldn't immediately crash for everyone who downloaded it.
So if you’re feeling brave you might want to download it and
give it a try. It (probably) won’t crash your computer, and it certainly won’t
reformat your hard disk. You probably won’t die simply because you
installed it either, although beyond that I wouldn’t like to make too many guarantees about
its stability or fitness for purpose. We’d certainly like to know what you think about the new direction we’re
taking with it, so please post your feedback and ideas in the forum.
I imagine that after that blistering sales pitch you’re just
gagging to get your hands on it so, before I move on to being a little more positive about the whole thing, let me just reiterate one last time that
this is definitely not up to the standard of a normal Red Gate beta in terms of either quality or features.
Right, now that I've got the disclaimers out of the way, I should point out that we really are quite excited about this, and we really hope that, despite the warts, you’re going to like it.
So what can you expect from this build?
- Much improved performance: in general it’s around 5x
faster than ANTS Profiler 3 when recording both method and line level timings.
It can be up to 30x faster depending upon what you’re doing.
- New timeline, which allows you select the region for which
you’re interested in viewing performance data. No need to keep stopping and
restarting the data. Just run the profiler once against your application and
run through all the tasks you need to perform, then drag out a region on the
timeline to view performance data for the period when you performed each task.
- New call tree, allowing you to see performance data in
context and really understand what your application is up to. You can instantly
see the hottest path through your application for the time period you’ve
selected. You can also summarise the tree at any time to exclude all methods
without source code, which makes things even clearer, and is particularly
useful for Windows Forms apps, where the bulk of many call stacks is spent in
the FCL.
- Support for
profiling desktop applications, windows services and COM+ servers; ASP.NET will
be added later.
- Both CPU and wall clock times are recorded, and you can
switch between them at any time.
- Three different profiling modes: method and line level
timings (pretty fast), method level timings only (really fast), or method level
timings only for methods with source code (really, really fast).
A quick word on ASP.NET: it's coming soon but it was giving us a few
usability headaches so we decided to pull it for now because we’ve redesigned
the configuration screens, and re-implementing them would have delayed the build.
Getting Started
It’s pretty simple to get going. Once you’ve downloaded,
installed, and run the profiler, you’ll be presented with the project settings
dialog box.
First select the type of application, then provide the required
information; for example, if you select a desktop application—this can also be
a console app—you need to tell the profiler where the executable is. You may
need to supply some arguments, but if not you can probably just hit Start
Profiling, unless you only want method level timings (see below).
The Default timing display setting allows you to choose
between Wall clock and CPU timings. The difference is that wall clock time
includes time spent blocking, e.g., sleeping, waiting for I/O, and so on, whereas CPU time
doesn’t include this. Each setting is useful in different contexts.
You don’t need to worry about changing this now, if you don’t want to, because
you can switch at any time later on using the drop-down beneath the tree view.
The Profile child processes option does exactly what it
says on the tin, but at the moment you can’t view any results for child
processes so you may as well uncheck it. To be honest it doesn’t make a lot of
difference though so it doesn't matter that much.
Note that saving/loading of project settings isn’t yet
supported, but it should remember your last settings when you next start up the
profiler (it might forget the application type though). I'd also recommend that if you want to start a new profiling session you exit and restart the profiler, rather than hitting File > New Profiling Session, because things can tend to get a little messy otherwise.
When you start profiling the profiler will start your
application and begin collecting performance data. You’ll see that the timeline at the top of the screen also starts collecting data about your application.
The orange trace shows the amount of CPU time your application is using. A
word of caution here: the y-axis of the trace auto-scales to include the maximum and
minimum values, but we don’t yet display any axis labels, so you won’t really
have too much idea what the actual value is: just because the trace is hovering
near the top of the graph doesn’t mean your process is necessarily using nearly
100% CPU time, although in general this probably would be the case. Again, we'll sort this out later so you don't have to cross check with Task Manager.
Whilst the
profiler is running do whatever it is you need to do with your application to manifest any performance problem, assuming you have one, or if you just want to get an overview of your application's performance, just carry out a typical set of actions. You should find that in either situation ANTS Performance Profiler can provide you with useful information.
Once you're finished you can do one of two things. The first and most obvious is click the big red Stop
button to the right of the timeline and wait for the profiler to summarise all
the performance data it's collected for the whole time your application was
running. You can also just close your application. Whatever you do, don't
click Stop more than once. You'll end up with it just sitting there for ever
and a day with no results. If you do do this, just drag out a region on the
timeline and you'll see some performance data appear. Obviously we'll fix this as well in a later build.
Summarisation can
take anywhere from a couple of seconds to several minutes, although I'd say 10
- 30 seconds is about average, depending upon what you've been doing, the call
complexity of your application, how long you've left it running, etc. If your machine's CPU usage is at 0% for any length of time but the profiler still claims to be summarising data then probably something has gone wrong, but it's not irredeemable. As above you can just drag out a region on the timeline to see results for that region.
Once summarisation is complete you'll see a
representation of all the stack traces in your application, or all the stack
traces within the time period you've selected, if this is what you did. By default they're displayed top
down, i.e., with root methods, such as main(), as the tree roots (for threads other
than the main thread the root method will be different). You can also display a
bottom up view, which not surprisingly starts at the deepest methods—actually
there's a heuristic here so we only include anything that takes more than 1% of
execution time—and then as you drill down the child nodes progress up to the highest
level calling methods; thus main() will be shown as one or more leaf nodes.
In both views you'll find that the hottest paths—i.e., stack
traces—through the application are expanded, and are shown at the top of the
tree. We always expand down to (or up from) a level where there is at least one method
that takes 1% or more of the total execution time. For the sake of clarity and
performance, we only expand stack traces towards the top of the tree. We'll
provide a right-click menu option in future to allow you to “smart expand” any
method in this way without needing to click down through all the child methods
manually.
Personally I prefer the top down view, but that's just me,
and I think both views have their uses. Another feature I also really like, and
which I think you'll find really useful, are the abridged views. These views
exclude virtually all methods without source code from the tree view, which can
be extremely handy if you're calling into or through a lot of library code.
They're very similar to the view you'll see if you choose to profile only
methods with source code, and provide a similar degree of clarity if you want line level timings. Sometimes, of course, you're going to want to
see if some of the libraries you're using are guilty of slowing down your
application.
These different views can be selected by using the
appropriate drop-down below the tree view.
Just like ANTS Profiler 3, you can view source code, where
it's available. Any method with source code will be rendered in bold in
the tree view. Just click on it to highlight it and the source code view will
appear. If you've chosen to profile line level timings these will be shown for
your method. Line level timings for other methods in the file will also be
populated in the background.
For now that's about it, although we hope there's enough there
to be useful. Finally, remember, you can switch between CPU and wall clock time at any
time once you've got some results. You can also do the same for timing
representations: percentages are the default, but you can also choose ticks, or
actual times.
We'll be making these builds available on pretty regular basis, and as each build is released we'll announce it on the forum: http://www.red-gate.com/messageboard/viewforum.php?f=80
I'd recommend subscribing either to email notifications or the RSS feed if you want these. I'll also post here if any notable bugs have been fixed, or new features added.
|
-
Posted Monday, April 28, 2008 5:17 PM |
|
Let me lay my cards on the table right from the start: I don’t like using, and I don’t use it any more (no pun intended). In fact I haven’t for quite some time. In this post I’m going to try to explain why I don’t use it, and why I don’t think you should either.
When you first encounter using, it seems like a great little timesaver. You write some code like this (the logic is just there for illustration, and in any case is not the best performing way to read an entire file):
using ( FileStream stream = new FileStream(
somePathName,
FileMode.Open,
FileAccess.Read,
FileShare.Read ) )
{
while ( stream.ReadByte() >= 0 ); // Stream reading logic here
}
And the compiler turns it into something like this:
FileStream stream = new FileStream(
somePathName,
FileMode.Open,
FileAccess.Read,
FileShare.Read );
try
{
while ( stream.ReadByte() >= 0 ); // Stream reading logic here
}
finally
{
stream.Dispose();
}
Fantastic! If an exception is thrown by my stream reading logic the FileStream will still be disposed of and the file closed, and I’ve had to do less typing to ensure that happens.
In a more realistic situation you might choose to wrap the using block in a try..catch statement that deals with FileNotFoundException, IOException, UnauthorisedAccessException, and the rest, and provides the user with a helpful error if something goes wrong, but basically it’s all good.
Isn’t it?
Weeeelllll…. not quite as much as you might think.
Before going any further I will say it’s a big improvement over this:
FileStream stream = new FileStream(
somePathName,
FileMode.Open,
FileAccess.Read,
FileShare.Read );
while ( stream.ReadByte() >= 0 ); // Stream reading logic here
stream.Dispose(); // Or stream.Close(), doesn't really matter
With this code, if your stream reading logic throws an exception, the file won’t be closed until the FileStream is finalised, which might happen immediately, or might not happen until, well, goodness knows really. The point is that until it does other processes may not be able to access the file, depending upon what they’re trying to do: in this case reading would be okay but trying to open the file for writing would fail. Potentially this could be catastrophic, at least for your software; if your code is running in a hospital, aboard an aircraft, or inside a nuclear power plant it could really be catastrophic, so don’t say I didn’t warn you.
Getting back to the code generated by the compiler for your using block, let’s say again that the logic in the try block throws an IOException of some sort. In the normal case your finally block will execute, the FileStream will be disposed of, and the file will be closed, making it available to other threads or processes. But what about the abnormal case: what happens if the Dispose() method throws an exception? Then you could be in some trouble.
“But wait!” I hear you cry, “Implementations of Dispose() shouldn’t throw any exceptions!” Now I’m pretty sure I remember hearing somebody—a speaker—say exactly that at a conference a few years back, and I’m also pretty sure I remember them saying that this was what Microsoft say should happen. In an ideal world that would be great but given the complexity of the .NET framework it’s just not realistic, and if you read the MSDN documentation for IDisposable there’s not even a hint that this might be the case, at least for .NET 2.0, so I’m going to brand this assertion wishful thinking.
To prove it let’s take a look at the Dispose() method on FileStream, which is inherited, and follows the expected pattern by calling the virtual Dispose( bool ) method. This in turn calls FileStream.FlushWrite() which most assuredly can throw exceptions, the most obvious of which are IOException and its subclasses. So whilst it might be a rare occurrence, it’s certainly a fallacy to think that you’re never going to run into a situation where Dispose() throws an exception.
Now if Dispose() does throw an exception, it will mask the exception thrown from the try block. At the very least this is likely to cause you some inconvenience whilst debugging, but if, for example, the exceptions are of different types, you could find yourself in side-effect city if you handled one but not the other, or had handlers at different levels in your code. In production code this is not a great situation.
Fortunately there is a solution, although you may not like it. Truthfully I don’t particularly like it either because it’s comparatively verbose: I’m lazy so the idea of using has quite a strong appeal. Anyway, here it is:
FileStream stream = null;
try
{
stream = new FileStream(
somePathName,
FileMode.Open,
FileAccess.Read,
FileShare.Read );
while ( stream.ReadByte() >= 0 ); // Stream reading logic here
stream.Dispose();
stream = null;
}
finally
{
if ( stream != null )
{
try { stream.Dispose(); } catch ( Exception ) {}
}
}
Note that I’ve initialised the stream inside the try block because in this simple case I’d probably just handle any exceptions by adding catch blocks to this try..finally statement. If you need finer grained control and want to handle exceptions occurring whilst trying to open the file separately, you could place the initialisation just before the try block—just like the compiler when it expands using—and then wrap the whole lot in another try..catch statement.
What happens here is that in the normal case the stream is created, used, and cleaned up in the try block. The test in the finally block always evaluates to false, and the second call to Dispose() is not executed. On the other hand if an exception is thrown anywhere in the try block after stream is initialised the Dispose() method will be invoked in the finally block and any CLR exception it throws will be swallowed. If stream hasn’t been initialised the test will again fail and the call to Dispose() won’t be made. Thus, exceptions can be thrown by the stream reading logic, or the Dispose() call, but an exception thrown by Dispose() will never mask an exception thrown earlier on in the stream reading logic. If you see an exception thrown by Dispose() it’s a ‘real’ exception neither (indirectly) caused by, nor masking, a previously thrown exception.
Note that in general it's very bad form—actually it's just a bad idea—to catch general exception types (Exception, ApplicationException), or to catch everything including non-CLR exceptions, but in this case the Dispose() method in the finally block is only executed in the event that an exception has already been thrown so this is okay because you're going to be much more interested in the first exception.
And that’s it. What I’ve actually shown here is a specific instance of a general problem with finally blocks—exceptions thrown in a finally block can hide an exception thrown elsewhere—but here a solution is available. It’s certainly more verbose—and perhaps just a wee bit anal retentive—but in the worst case it’s a much safer scenario than trusting using to do your cleanup for you.
Take home message: don’t use using.
|
-
Posted Tuesday, February 12, 2008 2:28 PM |
Weeeeell... okay, so a cursory glance at today's news headlines would suggest that to be a rather bold claim, however a few days ago I noticed that The Daily WTF was back to its old self. I'm not the most avid reader, although I do stop by fairly regularly, so I'm not sure when it happened. On the other hand, one of my colleagues who reads it pretty much every day wasn't sure either so I don't feel too bad about it. Now obviously a website called "The Daily WTF" is more than slightly rude, however when it was renamed "Worse Than Failure" I couldn't help feeling slightly sad that it appeared to have been infected by a little of the spirit of corporate blandness, which seems inescapable so much of the time... But no longer, hurrah!
|
-
Posted Tuesday, February 12, 2008 11:53 AM |
We're going to be working on a new version
of Red Gate's award winning performance profiler over the next few months and
we need your feedback to make it even better! Respond to the survey at https://www.surveymk.com///s.aspx?sm=AY9BjmF5HBBxhifLo5uQIw_3d_3d, and you will be entered into a prize draw to win a copy of the profiler.
It's dead simple and should take no more than 5 minutes to complete.
We are also currently evaluating the usability of ANTS Profiler and are
looking for .NET Professionals to provide feedback on the initial
design ideas for our next release.
The session will last 45 minutes to 1 hour and will include a short
interview as well as going through some scenarios with prototypes of
the designs.
These sessions can be run remotely from the comfort of your own office
chair or if you live close to Red Gate then you can visit our offices.
Interested? Do you want to know more?
Just send a mail to usability@red-gate.com and we will contact you.
|
-
Posted Monday, December 10, 2007 6:11 PM |
In many ways this has been a very long time coming… think Daikatana, but without the
offensive advertising campaign, the disgruntled employees, or the wild
expenditure on, uh, what I’ll loosely term as software development related
expenses. And nobody involved, at any point, has owned (or even driven) a
Ferrari. As a matter of fact whilst the protracted timescales are almost
identical, thankfully that’s pretty much where the similarities end.
I first remember a conversation about this when Lionel and I
talking about it at the office Christmas party in 2004, around six months after
I’d joined Red Gate, one month after Lionel joined, and when we still only had half
a dozen developers in total. Then Lionel and James discussed it again maybe a
year later, but this time went some way towards working out how you might go
about doing it, and then in between times there were more casual discussions
involving various different people.
But at the time Red Gate’s focus was largely SQL, so it never
got off the ground.
Then in mid-2007 Red Gate formed the .NET Developer Tools
division. We still had only one developer tool, ANTS Profiler, but Exception
Hunter’s time had come.
So what is it?
Put simply, it’s a tool that allows you to analyse your code
and find the unhandled exceptions before they ever happen. But so what?
So this…
Before .NET 2.0 came along, if your application threw an
unhandled exception somewhere other than the main thread, you might get away
with it. You might never even know it had happened, and maybe your user would
quit the application before you knew anything bad had happened, or maybe your
application would slowly edge its way into a world of utter agony in which it
depends more and more strangely until it eventually conks out entirely, but by
this time you’ve really no way of finding out why this has happened. It’s a
debugging nightmare. Back in the mists of time I was asked to fix a bug in SQL Packager
that turned out to be happening because deep in the bowels of the application a
background thread was being terminated by an unhandled exception and leaving
the application in an inconsistent state.
With .NET 2.0 the situation changed radically. Bam! Suddenly
your application that worked most of the time under .NET 1.1 now doesn’t work
for any length of time at all because there’s this background process that
regularly throws unhandled exceptions and in .NET 2.0 if that happens then your
application is terminated, or in ASP.NET your worker process is killed and a
new one spawned. And, unless you’ve set up a delegate to listen for one of the
unhandled exception events, such as AppDomain.UnhandledException,
or Application.ThreadException,
you’re probably not going to get any useful information either.
By now we’re all pretty used to this behaviour, and as a
number of other authors and speakers have pointed out, it’s actually a good
thing. And it’s certainly a lot easier to debug, assuming you do yourself the
favour of setting up these event listeners and logging the exception
information (including inner exceptions).
However, what this completely fails to address, is that when
your application suddenly goes unexpectedly KERBLAM!!! out there in the field when it’s being used by a real
customer, it’s also extremely embarrassing. You really don’t want that to
happen. Many of us will have sat on both sides of that fence. It annoys your
customers, it causes stress and hassle for your support team, who are probably
going to have to deal with somebody actually foaming at the mouth, if not
actually spitting burning jet fuel, and it soaks up time from your developers
and testers, who are quite likely working on different projects by now, so the
knock-on is that it hurts those new projects as well.
And it takes time, time during which your customer isn’t
likely to get any happier. We tried an experiment recently, which was to see if
we could get a patch out the door to a customer within a few days, even as a
private release with extremely limited QA time assigned to it. We failed
miserably. We failed because it’s not realistic to get the three or four people
we needed to do all the things we needed in a very short period of time to do
so when they’re all working on different projects, all of which have problems
of their own. In reality what we ended up doing was rolling up perhaps a dozen
fixes of varying levels of severity into a private release, each of us involved
set aside an entire day to do the work we needed to do, and in total the whole
process took around four weeks. And we’re a pretty small company in the grand
scheme of things. For larger companies the situation is clearly going to be
worse.
And whilst the “time is money” analogy can be taken too far,
in this case time is money. Lost time
equates to lost, or delayed sales. Too much lost time can equate to a failure
to consolidate a product’s position in the market before other competing
products are released. That sounds pretty extreme, but it can happen, and it
does happen all the time. How many software products are delayed because
they’re plagued by stability problems? Wouldn’t it be great if you could find
and fix these issues before a tester even touches a piece of functionality,
never mind a user?
The point is, you definitely want this stuff fixed before it
goes out the door. It’s also entirely unrealistic to expect that your testers are
going to find absolutely every scenario in which an unhandled exception can
bring your application down before you release, even if they’re really good.
Trust me, I know. At Red Gate the developer to tester ratio on every project
we’ve run since I’ve been here has been somewhere between 1:1 and 2:1, and 1:1
is pretty common, even if for only part of the project. Some tools do even
better: 3:4 in one case.
But still, you can’t find everything, and still your
application can crash embarrassingly once it’s been released to the world at
large, which is where Exception
Hunter comes in.
Exception
Hunter is a compile time analysis tool that analyses your assemblies and
dives down into their dependencies to find out which exceptions your code can
throw. It works by allowing you to pick the methods you want to analyse, shows
you which exceptions they throw, and allows you to drill down through the stack
traces to find their exact origin. Once you’ve found the line of code you’re
interested in you can open up your source at that exact line in Visual Studio
for editing. At this point you might choose one of the following courses of
action:
- Catch
and handle the exception by performing some alternative logic to do what
you need,
- Wrap
the exception in a domain specific exception type that you’ve created, or
in some other different but more appropriate exception type, populate it
with an informative message if you think you might report it to a user
later, and then rethrow it,
- Wrap
your code in a try block, then add a finally block to perform resource
clean-up, then add XML documentation comments to your code indicating that
the exception is thrown,
- Choose
to do nothing in that method, but instead deal with the exception or
perform clean-up at a higher level.
You might also find that the exception isn’t particularly
interesting. For example, you’re 100% confident that the values you provide to
a method will always be valid, and that therefore the ArgumentOutOfRangeException
that is nominally thrown will never occur, so you never need to worry about it.
That’s fine: you can and should make value judgements like that, but at least
you’re now in a position to do so in an informed manner, rather than guessing
and hoping.
You can also use Exception
Hunter when you do get a crash report. So, you get the (probably
obfuscated) stack trace back from the customer, or from your website logs, and
figure out what’s going on, but you might legitimately wonder if anything else
can go wrong. It’s a great time to run Exception
Hunter over the offending code to see if there’s anything else that might
catch you out. I did exactly this when fixing a problem with the meta-data
cache in SQL
Prompt, and managed to find three more potential problems in less than five
minutes. I was then able to fix these before they caused any trouble.
Exception Hunter works with code written with every version
of .NET from 1.1 right through to 3.5. It can analyse code originally written
in C#, VB, and Managed C++. It also provides more limited support for J#.
You can find more information about Exception Hunter,
including a demonstration video, at:
http://www.red-gate.com/products/exception_hunter/index.htm
You’ll find the support forum release announcement at:
http://www.red-gate.com/messageboard/viewtopic.php?t=6108
|
-
Posted Friday, September 07, 2007 4:28 PM |
The full announcement, including a list of major new features and bug fixes, can be found here: http://www.red-gate.com/messageboard/viewtopic.php?t=5606The short version is, if you've experienced some problems with 3.5 (exceptions, hangs after entering a dot, or any other performance type issues), please download this new version and give it a go to see if it fixes them. If not then please tell us: we'd like to get as many of these kinds of problems fixed as possible before the final 3.6 release. Just post on the support forum and one of us will get back to you as soon as we can barring accident, weekends, or a really good party. There's also so much new stuff in there that you'd be mad not to upgrade when the final release comes out, even if you're one of the many people who's happy with 3.5. It's a FREE upgrade if you've already purchased any 3.x version of SQL Prompt. You'll also note that we've done one of the slickest back-pedalling exercises in history by adding support for Microsoft Visual Studio Team Edition for Database Professionals (Data Dude).
|
-
Posted Friday, August 31, 2007 11:30 AM |
Look, temporary tables:
This also works for normal tables created in the script, as well as stored procedures, functions and views, and it'll all be available in the next SQL Prompt release, which should be within about two weeks all being well.
Originally this functionality was slated for SQL Prompt 3, but as you'll all be aware that took rather longer than we expected and we ended up dropping much of what we'd hoped to put in there. We're working on an article about that joyous saga that will appear on Simple Talk, hopefully in the next few weeks if I get time to finish it off (sorry Tony, Phil).
Also coming in the next release:
- Data Dude support - both because it's technically easier than not supporting it (or so we originally thought), and because we've actually had quite a number of requests about it come in over the past month or so.
- CTE support - never something we originally planned on supporting in SQL Prompt 3, but it's new functionality in SQL Server 2005 and is something we felt we should probably handle, although it's far from clear to me at least how popular these are.
- Control flow statement support (
IF, WHILE etc)- these previously didn't work brilliantly, which was less than ideal if you were writing a lot of functions or stored procedures, so we've shored up the support considerably.
- Loads of bug fixes, plus some more tweaking of the performance. Notably, again because this could be enormously irritating in some situations, the popup no longer appears when you're entering an alias for a table, view etc in a
FROM clause.
As I say, all this should be available in the next couple of weeks or so.
|
-
Posted Tuesday, August 28, 2007 4:48 PM |
Or, why doesn't the Red Gate "Check for updates" service automatically download and install software updates? Disclaimer: everything in this post represents my view only and does not necessarily coincide with the viewpoint of Red Gate Software Ltd. On the other hand I'm not trying to be deliberately contrary, I'm just saying don't take this as the official company line.So why am I writing about this? Well somebody recently asked me about it and to be honest the entire topic makes me quite grumpy, so I thought, what the heck, I may as well post an opinion. Maybe somebody will have something intelligent to say on the topic. "Check for Updates" first appeared in a Red Gate product around two years ago, or maybe a little longer, and when it was first mooted we did indeed consider an automated solution. I mean it sounds great. Users just get a little notification and then the update is downloaded and installed and they never even have to visit your website. It's a technocrat's wet dream... or is it? You see three years ago I was all for this, I was one of the people who was saying, "Hey, look we can just automate this whole process and make it really easy for our users, and won't it be great?" And I was disappointed at what I saw as the limited scope and vision of the proposed "update service", which we now have. I mean all it does is tell you when an update is available and take you to the corresponding web page when you click on the link for the update. And you even have to click on the menu item yourself: it won't even check automatically and give you a nice little flashing notification or anything. I mean, how much of a token effort is that? Well let me tell you, three years of InstallShield, Paint Shop Pro, Quicktime, iTunes, and Steam update notifications later, not to mention Real Player (or whatever it's called these days), and all the others, it's very clear to me that we soooo did the right thing. I think I've now managed to disable most of them, but these things all pop up their own update reminders with their own home-rolled update solutions. Of course, I now don't get any updates, which is also really a part of the problem. Here's an example. You're in the middle of writing some code in Visual Studio, in the zone as it were, and suddenly up pops the most unnecessarily large dialog box in the history of computing telling you that updates are available for Quicktime and iTunes. So I'm having a chat with my colleague Andras this morning about case-sensitivity and binary collations in SQL Server over at his desk, and he's showing me around some code in SQL Compare, and up pops that chuffing dialog, which he said something very rude to and then dismissed with a contemptuous click of the mouse. I felt like writing a letter along the lines of, "Dear Apple, Whilst I think you make cool computers, and the iPod is very funky, there are no words in the English language to express how much I never care that a Quicktime update is available..." Not only do these things have their own special way of rolling out updates, but whereas with Windows you can install SUS so you only download updates once and then push them out to client machines on your network, with Installshield et al each and every client goes and downloads the updates individually, and if you've got a hundreds or thousands of clients what's that going to do to your bandwidth and internet connectivity? (For obvious reasons, this is probably less of an issue with Steam.) In short, it sucks. Really badly. And I'm not anxious to contribute to this problem. Honestly, all third party software update services need to be dumped in room 101: seriously, pick any two word phrase in the English language where the second word is "off", followed by an exclamation mark, and apply it to yourselves. Really, you all suck. I also don't think we're anxious to roll our own full blown Windows Update style technology that doesn't suck, and that we'll then have to support and patch, and assign valuable (and expensive) development resources to, when Microsoft already have a perfectly good solution. Which brings me on to my next point, which is that nowadays I believe it's possible for ISVs to roll out updates using Windows Update, which sounds a whole lot more sensible to me: - You only get one montly update notification as part of the standard Windows Update functionality, unless of course you've configured it to check more or less often.
- You can use SUS so you only download each update once.
- Windows Update works really quite well and sucks a whole lot less than everybody else's solutions.
- You don't have 53 different "agent" applications of varying degrees of half-arsedness sitting in your system tray or running on startup, that poll their respective vendors for updates, and sometimes display their popup notifications simultaneously above the system tray.
One downside is that you have to trust that Microsoft won't do something nefarious with your application, like, for example, reverse engineer it, after you make it available via Windows Update. Frankly though, if they wanted to do that they could just download it from your website in the first place. Or just buy a licensed copy. It's not like they don't have the money. On a more serious note I think these issues might put it out of reach for a lot of companies, which I think is a shame: - I can't help thinking you probably have to jump through a lot of hoops to get updates for your application accepted for distribution via Windows Update. Probably too many hoops to make it viable for small to medium ISVs due to the overhead in terms of staff time required. Maybe there need to be different levels of certification.
- It might cost a lot, and again this might put it out of reach for small to medium ISVs. On the other hand given the amount of software that's out there, expecting Microsoft not to charge for it at all seems more than a little unreasonable.
I'll admit I'm being somewhat idealistic here, but wouldn't it be great
if there were some way to keep all your software up to date using a
single mechanism rather than having a different method for every vendor? And whilst it's not often that I play the Microsoft fanboy, why not Windows Update? As I've already said: it works, and whilst there are many ways in which I'm sure it isn't perfect, it seems a lot less imperfect, and a lot better thought out, than everybody else's solutions. Maybe there is something else out there: I could probably live with Windows Update and one other update service, but not half a dozen. Or ten. Or more. There, I feel calm and rational again now. :)
|
-
Posted Thursday, July 26, 2007 6:20 PM |
Well, this is it, it's finally out there. Download it from http://www.red-gate.com/products/SQL_Prompt/index.htmImprovements include:
- Visual Studio 2005 database project support
-
Cross database queries
-
Distributed queries across linked SQL Server instances
-
Correlated subqueries
-
3 – 5 times faster metadata retrieval
-
Large script support
-
40 – 95% decrease in memory footprint
And plenty more. I'll be carrying on my more in depth look into the functionality with a discussion of cross-database and distributed queries next. The past few days have been quite busy tying up loose ends and providing training for our Technical Services, Sales and Marketing teams.
Enjoy the new functionality!
|
-
Posted Friday, July 20, 2007 5:23 PM |
|
Well it's taken me slightly longer to get around to writing this than originally planned, however...
Visual Studio 2005 support, along with cross-database/linked server support was one of our top two requested features for SQL Prompt 3.5. It got to the point where not a day would go past without somebody emailing sales or support to ask about it, and of course all these emails eventually found their way into my inbox. Then of course we had people asking on the support forums as well, so I guess in some ways it might seem quite odd that we didn't include it the first time around in version 3.
The reason is that we did a survey and the survey told us that 90% of people either used Query Analyzer or SQL Server Management Studio, with around 50% of them using QA. Only around 5% of people used Visual Studio 2005 for editing SQL at this stage. This was in May 2006 and we were aiming to get SQL Prompt 3 out at the end of September (hah! - not that I'm bitter), so it seemed reasonable to target only QA and SSMS. Obviously times change and by the time we did release SQL Prompt 3.0 and 3.1 the uptake of Visual Studio 2005 would have been greater, and more people were asking for VS 2005 support. And so we've added it for 3.5.
So if you're editing a database project, or scripting and editing objects using the server explorer you can now use SQL Prompt to help you out. Actually in the RC due to an oversight just using the server explorer in a standard project SQL Prompt doesn't work properly, however we've now fixed this so when we release the final version, hopefully, although not definitely, at the end of next week, this will be working fine. One thing I should say is that for commercial rather than technical reasons, we don't support VSTS for Database Professionals, popularly known as Data Dude.
As far as limitations go there really aren't any; you should find that it works just as well as in SSMS or QA. The only difference is that you'll probably find it asks you for authentication credentials slightly more often that it does in the other editors because it is not always possible to extract the complete credentials from Visual Studio.
In my next post I'll talk about the cross-database and linked server support and give a few simple examples.
|
-
Posted Wednesday, July 18, 2007 6:06 PM |
Well I said I’d post some more detailed information about
the new version of SQL Prompt so I thought I’d better get down to it. I wanted
to do this to coincide with getting the release candidate out there, which we’d
planned on being this Friday, however we all had a bit of a rush of blood to
the head at about 5 o’clock yesterday afternoon and decided to just jolly well
release it, and frankly I’m glad. We were holding on only due to a couple of
issues with the installer:
- If
Visual Studio 2005 has never been used prior to installing SQL Prompt 3.5
then the SQL Prompt menu will not appear until Visual Studio is restarted.
I can’t imagine too many people are going to run into this one, however if
you have I apologise. The reason we encountered it is that we generally do
install testing using virtual machines, which although I hate them with a
raging passion, do have some uses.
- If
you’re upgrading from 3.1 the tray application restarts during the
installation but SQL Prompt won’t work in Query Analyzer until you
manually restart it again. This is clearly going to affect a lot more
people, however we decided that it wasn’t serious enough to hold up the RC
any more.
I must admit it felt just slightly cavalier, however when
you bear in mind that we’d been trying to fix just these two issues since last Thursday you can see why some of
us might have been losing the will to live because they were holding us up from
making any real progress and (1) in particular just isn’t that big a deal.
So… it’s out there in the wild, and already we’ve had one
person who’s reported an issue with VS 2005 that’s likely to affect a number of
people that we wouldn’t have found for some days, if at all, and which we’ll be
fixing for the final release. And that’s why we released it: we reached the
point where the user feedback was the thing we most needed. Getting a few
hundred, or even a few dozen, people with widely varying system configurations
to take an early look at a product is a really good way to shake out those last
few pesky bugs.
There’s a whole philosophical debate then about whether or
not this really constitutes a release candidate if we’re intending to make some
changes, however what I’d say is this: we put out a release candidate when we
think something is good enough to release (apart from the installer issues in
this case), but I have never yet
worked on a product here at Red Gate where we didn’t end up fixing at least a
couple of bugs between the RC and the final release, so in this case we just
did the pragmatic thing and kicked it out the door.
Anyway, I’ve deviated somewhat from the point, and now I'm (again) running out of time. In my last post I briefly listed some of the new features and
enhancements we’ve added so over my next few posts I’m going to
take a look at these things individually along with a few other improvements in more detail.
|
-
Posted Tuesday, July 17, 2007 6:40 PM |
Well that's pretty self-explanatory. We've had a few teething problems trying to get this thing ready and on the FTP site today so this will be a rather more brief post than I'd originally planned. I'd intended to talk about some of the new features in a little more depth, however I'll do that over the next few days. Anyway, cutting to the chase, the forum announcement is here: http://www.red-gate.com/messageboard/viewtopic.php?t=5263And the download URL is: ftp://ftp.red-gate.com/sqlpromptbeta/SQLPrompt3.5.0.000323.exe
Major new features and improvements include: - Visual Studio 2005 database project support
- Cross database queries
- Distributed queries across linked SQL Server instances
-
Correlated subqueries
-
3 – 5 times faster metadata retrieval
-
Large script support
-
40 – 95% decrease in memory footprint
The team have worked really hard on this and so there are also a whole raft of other fixes and enhancements in there but I'll talk more about all this stuff tomorrow and over the next few days. Right now I have a barbecue to go to, and it looks dangerously like it might not even rain which (let me tell you) makes a very pleasant change round here at the moment.
Enjoy the RC. As I say, more of an update soon, and all being well the final release should be out by the end of the month.
|
-
Posted Friday, March 23, 2007 12:59 PM |
We are very pleased to announce that SQL Prompt 3.1 has now been released. You can download it from:
http://www.red-gate.com/products/SQL_Prompt/index.htm
The most notable addition is support for SQL Server Management Studio
Express Edition, however even if you don't use this version of
Management Studio we'd recommend the upgrade so you can take advantage
of the following bug fixes and improvements:
- Fixed various glitches when running on Windows Vista,
- Fixed bug causing lock-up when an apostrophe is entered whilst editing in a split window in Management Studio,
- Now prefers exact matches for the current filter string by bringing them to the top of the candidate list,
- Keywords etc no longer auto-upper/lower-cased in comments and strings,
- Auto-closing character behaviour improved: insertion made less
intrusive, auto-deletes when opening character is removed, can now
overtype closing characters,
- Fixed case-sensitive owner/schema filtering bug,
- Empty object name no longer causes exception,
- Fixed exceptions when using "Run As..." to run Query Analyzer and/or Management Studio
- Fixed inappropriate connection attempts by SQL Prompt; fixes VPN related issues,
- A number of other small fixes and improvements to handle uncommon situations, e.g. attempting to connect to SQL Server 6.5.
Please enjoy using SQL Prompt 3.1.
This is a duplicate of the announcement at http://www.red-gate.com/messageboard/viewtopic.php?t=4562.
|
-
Posted Wednesday, February 28, 2007 2:36 PM |
For anyone out there working with SQL Server on a large or mission critical system it's quite likely that, unless you're the DBA, you're not going to have dbo access to the databases you're working with, particularly if you're working directly with the production servers. Unsurprisingly then we've had a number of complaints from people finding themselves in exactly this situation who want to be able to use SQL Prompt 3, but can't because it generally doesn't work unless you're dbo. Fortunately my colleague Jon this morning let me know that a solution is at hand for SQL Server 2005 at least, although you're still going to have to be nice to your DBA to make this work (I'd suggest that beer often helps). What you need to do is ask him or her to grant you the VIEW DEFINITION permission on the database of interest. What this means is that you'll be able to see all the meta-data for any object defined in the database, but you won't have access to the objects themselves, so for example you won't be able to read any data from a table unless you have the permissions required to do so. For example, say your username is "bill" and you need access to the AdventureWorks database, then your DBA would need to execute the following command: GRANT VIEW DEFINITION ON Database::AdventureWorks TO bill
Now, just to be clear about exactly what access this gives you, here's an extract from SQL Server 2005 books online that explains how this permission works: "The VIEW DEFINITION permission lets a user see the metadata of the securable
on which it is granted. However, VIEW DEFINITION permission does not confer
access to the securable itself. For example, a user that is granted only VIEW
DEFINITION permission on a table can see metadata related to the table in the
sys.objects catalog view. However, without additional permissions, the
user cannot read data from the table."
You might still be curious about why SQL Prompt needs this permission, and the reason has to do with the fact that back in the mists of time (last May) we decided to use the SQL Compare back-end to retrieve our meta-data. Now this is a great example of software reuse, and it saved us an awful lot of development time, however when you reuse something for a purpose for which it wasn't originally intended you can't really be surprised if you encounter the odd hiccup along the way. The problem here is that SQL Compare doesn't trust the SQL Server system tables or views (wisely if you think about what it's supposed to do) so it works out most of what it needs to know by parsing the SQL definitions for the objects in your database, and if it can't get at the definition then it can't build up a model of your database. Now for SQL Prompt having partial information is OK since giving people some help is probably better than giving them no help whatsoever, but if you want to find out what the differences are between two databases then anything less than complete and accurate information really won't do at all, and SQL Compare therefore gets mardy as you like if it can't get the information it needs. You can be sure that we'll be working on fixing this in the future but in the meantime cultivate kindness towards your DBA and ask them nicely to grant you the VIEW DEFINITION permission on your database and all will be well.
|
-
Posted Monday, January 22, 2007 4:03 PM |
We're very pleased to be able to announce the release of SQL Prompt 3. Get it here: http://www.red-gate.com/products/SQL_Prompt/index.htmWe've fixed quite a number of bugs since the final beta. Most notably the popup behaviour is significantly improved. We've also added support for SQL Server 7. We hope you enjoy using it!
|
|
|