Kim Gräsman, 2005
It's recently come to my attention that I'm an idiot. The APIs I'm using to set the decimal point are not scoped to the current thread as I first thought, nor to the current process. They are system-wide, persistent settings.
This means that every time you start Query Analyzer with the localization fix installed, your global decimal point setting will be altered permanently to a single period.
I'll figure something out when I find the time, but until then I've removed the download link to save people from nasty surprises.
SQL Server users in Sweden either don't use the excellent Execution Plan feature, or have been taught not to trust it. Part of the reason why may be it doesn't work. How's this for a nice set of percentages?
This is quite obviously wrong, and this is because Query Analyzer does not respect the user's locale when it converts between numeric and string format, more specifically, it expects the decimal separator to be a single dot (.).
Christoffer has already described this in much better detail than I, so I'll refer you to his discovery.
As Christoffer eloquently noted, the straightforward workaround is to just change your decimal separator. If you set it to a period rather than the default comma, QA works just fine. However, your machine is now globally set for a non-standard decimal separator, so you'd better keep that in mind when using Microsoft Office, and make sure you use a decimal dot rather than a decimal comma.
My first instinct, when Christoffer explained this to me, was that it'd be much nicer if we could control the decimal separator for ISQLW.EXE only.
I experimented a bit with a stub that modified the current locale, started QA, and let it inherit the new setting. That worked nicely, but it would still require that users started the qastub.exe rather than isqlw.exe. For Start menu-surfers, this would be no big deal, re-route the shortcut and you're done.
Myself, I always run QA using Start > Run..., for some reason. Also, there are menus in Enterprise Manager and Profiler that fire off isqlw.exe... It'd be nice if we could get the localization to apply to all instances of QA.
I finally came to the conclusion that the easiest way to hijack isqlw.exe would be to register it under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. See Google for a couple of background references. With my stub acting as a debugger for isqlw.exe, I can make sure my code always runs before isqlw.exe starts, no matter how it's started. This is guaranteed by the Windows loader.
After installing QuALFix, there should be no way for you to run QA without the decimal separator forced to a dot. Everything falls back on the loader sooner or later, and before isqlw.exe is started, my stub is notified, and takes over control.
This makes for a clean fix, all you have to do is run the installer below, and after that Execution Plans within QA should just work.
Registering a debugger to hijack a process and modify localization info is not exactly your run-of-the-mill activity. It can go wrong.
Make sure noone else is already using Image File Execution Options for isqlw.exe (very unlikely), and refrain from installing QuALFix if they are, since the installer will overwrite anything there unconditionally.
This should be helpful for people outside of Sweden as well, anywhere where the decimal separator is not a single period.
First public release
The package will install a single executable onto your system, and register itself as a debugger in the registry. It should uninstall cleanly.
Feel free to contact me if you have any problems.
Installer download removed until I'm able to fix the fundamental issues