Changes in REDO/UNDO in ApexSQL Log

We had a great thread on ApexSQL Log support forum today regarding the issues on REDO/UNDO generation for tables with no unique indexes. Due to this thread we have already made some changes in REDO/UNDO generation (these will be included in the upcoming service release of the product.) Based on the feedback from our users, we have also implemented changes in the way ApexSQL Log handles identity columns for INSERT statements. These two changes together make the need to manually edit generated REDO/UNDO scripts considerably less likely than before.

DST bug in (some versions of) Windows

Last night I have been hit again with Daylight Saving Time bug in Windows. All my PCs are in the GMT-4:00 Santiago TZ. But for some reason ever since Windows 2000 (if I remember correctly), DST switching for my TZ happens a day before than it really should. So I keep DST turned off on all my PCs... except for the newest one running Windows 2003. For some reason I thought that Microsoft has actually fixed this bug (apparently I was in Daylight Dreaming Time when I installed the OS) so I left DST turned on. At 12AM Windows smoothly switched to 1AM thus producing a cascade of updates (through my own doing) on all other PCs and clocks. Only this morning I remembered that the switch is done on Sunday morning, not Saturday morning (I usually check the official time page for Chile but I forgot to do that last night - such is the power of my belief in Windows ;) Well, no harm done this time, it's just annoying (some of the household members woke up an hour earlier but figured out the situation quickly... after all the TV is never wrong! ;)

UPDATE: Some good news - MS fixed this bug in Vista! I just checked on my RC1 and this is what I get:


This is cool. Finally some transparency in the matter!

Running .NET 2.0 applications under 64-bit Windows (x64)

By default Visual Studio 2005 compiles .NET executables under "Any CPU" compilation target (the exception is C++/CLI where you have to choose 32-bit or 64-bit target). This allows the same binaries to run as 32-bit or 64-bit binaries depending on the operating system .NET framework is running on. However, if your executable compiled thus depends on 32-bit components (either .NET 1.1 assemblies, 32-bit native DLLs, C++/CLI .NET 2.0 assemblies under 32-bit target, etc.) it will crash when run on 64-bit operating system (and vice versa; if it depends on 64-bit native DLL for example it will crash on 32-bit operating system - but that's not the usual case.) The reason for this is that in Windows 64-bit processes cannot load 32-bit components and vice versa. So what can be done about this?

There are several ways to solve this:
1. Compile all your binaries under "32-bit" target in VS2005. This is the easiest thing to do but it prevents .NET framework from optimizing your code (on the fly of course) to utilize fully 64-bit CPUs. Also, if you are developing assemblies that need to be run in 64-bit processes then this option is out.
2. Convert all 32-bit dependencies to "Any CPU" dependencies. Depending on your situation this can range from easy to impossible to do (e.g. if you are using 3rd party 32-bit native DLLs, it won't help to ask the vendor to recompile for 64-bit or even for .NET - you will need to find a .NET 2.0 library compiled as "Any CPU" to do the same job)
3. Obtain all dependencies as 32-bit and 64-bit versions and install them accordingly. This can also range from easy to impossible to do (e.g. you are using 32-bit native DLLs from a now defunct closed source vendor) but it does allow you to run both managed and native code, if you have such, as fully 64-bit.
4. Move all 32-bit dependencies to a separate 32-bit executable and communicate with it from your 64-bit process through some form of IPC (e.g. shared memory). Yet again this can range from simple to impossible to do (e.g. using 32-bit components in GUI would be a tough to implement through any IPC) But it's a great solution when you are using critical 32-bit components whitout any chance on getting them as 64-bit components. Variant of this solution is out-of-process COM library.

Now that I'm thinking about it, we at ApexSQL in our efforts to bring 64-bit support in all our apps, had the opportunity to implement all four solutions at one time or another. Please feel free to comment on these - I must have missed some alternative solution. I would be most interested in hearing other experiences.

Finally, for those that need to support users running their "Any CPU" applications dependent on 32-bit components on 64-bit operating systems (that's a mouthful!) I recommend reading this article: Setting Platform dependency bits in .Net 2.0. It shows how to use a utility from .NET 2.0 SDK to force application to always run as a 32-bit process.

Using ISNULL() for parametrized filtering

Alex Grinberg over at SQL Server central wrote an article named "Self Eliminated Parameters" on how to avoid building dynamic SQL in queries that filter by more than one optional parameter. The technique boils down to the following use:

(COLUMN_NAME = @PARAM_NAME OR @PARAM_NAME = DEFAULT_VALUE)

and he shows the example for Northwind database:

(Products.ProductName = @prodname OR @prodname Is Null)

I have been using this technique for years but with a twist: instead of doing my own OR operation I leverage T-SQL ISNULL() command. Like this:

Products.ProductName = ISNULL(@prodname, Products.ProductName)

However, not that I'm looking at it I'm wondering if it's not too "cute". In any case from my tests the performance is on par or a tiny bit better than with OR condition.

Open source search engines

If you are anything like me you like leveraging implementations that are publicly available and not re-intenting the wheel all the time. Here are three source code search engines to help you with that:

Koders

Google Code Search

Krugle

Personally, the tool I use is plain vainilla Google but I have used Koders from time to time. Now Google Code Search comes along (it was released just today) so I'll be sure to check that out. I didn't even hear about Krugle before today but it looks slick - I will check it out as well.

While I'm on the subject of use of open source I can't but mention the absolutely best open source C++ library out there: Boost!