reCAPTHCA: fight spam and help digitize books

I just read this article on Ars Technica. I won't go into details here but it's very cool so check it out. And if you have time take a look at this video - it's a lecture by Luis von Ahn (he's mentioned in the article) on harnessing the power of human computation (sounds scary but it's not :)

ZX Spectrum - 25th anniversary

This is what I wanted to blog about today but I'll leave it for some other time now.

Rah

My dearest of all cats, Rah, has died today after a long fight with illness (induced by several poisonings he had over the past year.) Here's a photo from last year taken on the day I let all my cats roam free for the first time:



He was my friend, my companion, my pride and joy. I loved him dearly.

Building Boost 1.34 for x86, x64 and IA64

The new version of Boost library has been released recently. Since we have released ApexSQL Log 2005.04 just the other day, we can now migrate our source base to Boost 1.34. This post will deal with building of Boost static libraries for side-by-side compilation and linking of x86, x64 and IA64 libraries. This is now much easier than it was in Boost 1.33 but there is still some work to be done.

1. Download Boost and Boost.Jam from here.
2. Put Boost.Jam binary into a directory on your PATH.
3. Uncompress Boost library into a directory of your choice.
4. There is an error in one of Boost build files that needs to be fixed before compiling for IA64 architecture:

1. Go to boost_1_34_0\tools\build\v2\tools folder.
2. Open msvc.jam in your favorite editor (mine is by *far* Visual Studio itself)
3. Replace all instances of "x86_IPF" with "x86_ia64" (there should be two)

There is also an omission in the same file and native x64 compiler will be used only on boxes with %PROCESS_IDENTIFIER% matching AMD64. So if you have Intel based x64 CPU build will be done with x86-x64 cross-compiler. It's just slower but the results are the same. If it bothers you, you should be able to fix it easily.

5. Go to command prompt, change directory to boost_1_34 and build Boost library for all three architectures.

• For x86:

bjam msvc architecture=x86 stage

• For x64:

bjam msvc architecture=x86 address-model=64 stage

• For IA64:

bjam msvc architecture=ia64 stage

6. Install x86 libraries:

bjam msvc architecture=x86 install

By default Boost will install its include and lib files into C:\Boost\lib and C:\Boost\include\boost-1_34. The problem with this is that if want to install x64 or IA64 static library files these will overwrite x86 static library files already installed. To avoid this we need to move all x86 static libraries to C:\Boost\lib\x86 (this is my solution - obviously other solutions are possible) so that these aren't overwritten by subsequent installations.

7. Install x64 libraries:

bjam msvc architecture=x86 address-model=64 install

Again, move these libraries from C:\Boost\lib to C:\Boost\lib\x64.

8. Install IA64 libraries:

bjam msvc architecture=architecture=ia64 install

Now move these libraries C:\Boost\lib to C:\Boost\lib\ia64.

9. Adapt your Visual C++ projects so that:

• x86 platform links libraries from C:\Boost\lib\x86
• x64 platform links libraries from C:\Boost\lib\x64
• ia64 platform links libraries from C:\Boost\lib\ia64

That's it! You should now be ready to use Boost libraries for binaries on all three Windows platforms.

Update: Fixed a typo in "For IA64" build statement.

ApexSQL Log 2005.04 released

Yesterday we have finally released 2005.04 version of ApexSQL Log. You can download it here.

Here's the full list of enhancements, changes and fixes:

----------------------------------------------------
RELEASE 2005.04.0453
DATE: 15 May 2007
DESCRIPTION: Medium Enhancement/Fix release
----------------------------------------------------

Enhancements:

- Greatly improved reconstruction of UPDATE operations (MAJOR ENHANCEMENT)
- Greatly improved memory footprint and performance scaling (MAJOR ENHANCEMENT)
- Added support for recovery of VARCHAR(MAX), NVARCHAR(MAX) and VARBINARY(MAX) data types from
database files (MAJOR ENHANCEMENT)
- Improved support for transaction log backups converted from 3rd party backups (MAJOR ENHANCEMENT)
- Added partial reconstruction of changes made to fixed-length fields in UPDATE operations.
- Added partial support for recovery of XML data type from database files.
- Added support for reading SQL Server 7/2000 transaction logs under SQL Server 2005.
- Added support for reading SQL Server 2005 transaction logs under SQL Server 7/2000.
- Added more recovery reports details to recovery scripts.
- Added dummy data to BLOBs that are partially recovered due to lack of data.
- Added "row partially reconstructed" column to SQL, BULK, CSV and XML exports.
- Added "/run_small" switch to command line interface which forces the application not to save
most of intermediate files on the hard drive. If there is less than 5% free space on the drive
the application will switch automatically to "run small" mode.
- Added recovery script path selection to Recovery Wizard.
- Added table mapping to MDF data recovery.
- Improved generated recovery scripts for less-than-perfect data recovery scenarios.
- Improved progress bar during transaction log reading.
- Improved reliability of BLOB recovery algorithm.
- Improved auditing performance in general.
- Improved memory managment when under memory pressure.
- Improved formatting for REAL and DOUBLE SQL types.
- Improved diagnostic logging.
- Integrated client-side and server-side setups into one setup.

Changes:

- Increased drive usage for intermediate and temporary files during auditing/recovery, to approximately
10-20% of transaction log file sizes. If there is less than 5% free space on the drive the application
will switch automatically to "run small" mode thereby saving on drive space.
- Limited export options to exporting every 10th REDO/UNDO script during the evaluation period.
- Limited copy to clipboard for all REDO/UNDO scripts during the evaluation period.

Fixes:

- A set of problems with server-side components running on SQL Server run by non-administrator account (MAJOR FIX)
- A problem with relying on @@SERVERNAME for server name on repeated connections which
blocked re-connections for servers not accessible through their @@SERVERNAME (MAJOR FIX)
- A problem with UPDATETEXT and line breaks in BLOB recovery (MAJOR FIX)
- A problem with double reading of log files during open (MAJOR FIX)
- A problem with recovery of some system table structures (MAJOR FIX)
- A problem with primary key values in SQL export (MAJOR FIX)
- A problem with XML data type recovery (MAJOR FIX)
- A problem with some recovery options not working correctly on remote servers (MAJOR FIX)
- A problem with putting server logs to system32 (or SysWOW64) directories. Now server logs are all in LOG
directory of SQL Server instance.
- A problem with recovery of dropped tables in SQL Server 2000.
- A problem with bad IDENTITY status for some reconstructed tables on SQL 2005.
- A problem with grid refresh if the last transaction was rolled back.
- A problem with clustered index keys not shown for un-reconstructed UPDATE operations.
- A problem with in-row values in NTEXT fields not correctly shown.
- A problem with recovery of BLOB data of NTEXT columns.
- A problem with NVARCHAR(MAX) columns in recovered table structures.
- A problem with some field values not being exported on UPDATE operations.
- A problem with application crashing when trying to write to a read-only file.
- A problem with "File not found" exception when doing recovery from online database files.
- A problem with extended procedure connecting back to SQL Server and being rejected due to lack of permissions.
- A problem with SQL authentication not working correctly when accessing logs from server tree.
- A problem with SQL authentication if invalid user/password entered.
- A problem with a label on SQL authentication user/password window.
- A problem with relying on @@SERVERNAME to start Connection Monitor.
- A problem with temporary UNDO/REDO scripts not having SQL extension.
- A problem with table structure lines not ending with consistent UNICODE line endings.
- A problem with reaching EOF of online database files.
- A problem with declaration of FLOAT data type in generated scripts.
- A problem with duplicate column names in some recovered table structures.
- A problem with duplicate recovered tables.
- A problem with lingering IDENTITY_INSERT state after a generated INSERT with identity fails.
- A problem with inserting NULL field values into NON-NULL columns in some recovery scenarios.
- A problem with application always demanding valid file paths in sysfiles.
- A problem with recovery of tables with timestamp columns in some recovery scenarios.
- A problem with duplicate servers in "Server Activation Center" dialog.
- A rare problem with BLOB data updates being out of range for the current BLOB values.
- A rare problem with not loading all operations in some circumstances.
- A rare problem with command line interface not creating log files correctly.
- A rare connectivity problem on SQL Server 2005.
- A rare problem with activation not working correctly.
- A rare problem with activations on multiple instances of SQL Server 2005.
- A rare problem with NULL values crashing the application.
- A very rare problem with calls to some empty extended stored procedures hanging on SQL 2005.
- A very rare problem with Connection Monitor not resetting on consecutive errors.
- A very rare problem with ApexSQL Server Helper driver sometimes crashing on SMP machines.

As you can see this is a huge release. I have blogged about some aspects of it before here and here.

ApexSQL Log 2005.04, part II: Smoother user experience

This is the 2nd part of my "ApexSQL Log 2005.04" series which I started here. In the first one I blogged about some of the most important new features and fixes, this time I'm going to mention most important things we did to improve user experience (especially for new users)

Integrated client-side and server-side setups into one setup

Starting with version 2005.03 we have provided a standalone server-side setup for our customers. However, this hasn't been convenient enough so we went one step further and we will now provide one unified setup for client and server-side components.

There are now three setup options:
1. Client application (GUI and CLI) and server-side components on a local server
2. Client application (GUI and CLI)
3. Server-side components on a local server

The only thing worth noting here is that setup can install server-side components only on a local server (this includes virtual servers in failover cluster) and not on a remote server.

Problems with SQL Server run by non-administrator account

In previous versions of the software our server-side components needed high level of privileges which of course led to problems in environments with restricted privileges of the account running SQL Server service. In version 2005.04 we took this problem head on and have significantly lowered the level of privileges needed for server-side components. In the process we have also solved another of problems springing from inability of the account running SQL Server to back-connect to the server itself. There is one known issue left here: Connection Monitor still needs login privileges for the account. In future versions we will allow manual configuration of Connection Monitor connection parameters.

We also had problems with logging on server-side components when lacking privileges. In previous versions server-side logs were stored in System32 (or SysWOW64) folder but in some configurations the account running SQL Server service lacks privileges for writing into system folders. Version 2005.04 stores all server-side logs into "LOG" subdirectory of SQL Server (which, in retrospect, is the ideal place for log files!)

For the record, I think that restricting privileges to SQL Server service (and other services) to bare minimum is a great security practice and one that we certainly try to encourage.

Problems with bad @@SERVERNAME

ApexSQL Log uses @@SERVERNAME to identify server's real name in some situations. But this leads to problems if you change server's network name after SQL Server was already installed. When that happens @@SERVERNAME continues to return the old server name even after the service restart so ApexSQL Log doesn't have access to real machine name which in turn leads to all sorts of problems. This is surprisingly (for me) common situation and we often had to help users fix @@SERVERNAME values. Starting with version 2005.04 this has been fixed. We still use @@SERVERNAME for some internal stuff but connection is now always done through server name as input by user. This also solved the problem with accessing servers available only through IP address or listening on a port other than 1433.

We also solved the same problem but on server-side with Connection Monitor. Connection Monitor has to back connect to SQL Server and used to obtain its server name from @@SERVERNAME. It doesn't any more - it now always connects to 127.0.0.1 with instance name if available retrieved directly from command line that ran SQL Server.

In case you are wondering, to fix @@SERVERNAME so that it returns the correct machine name you can do the following:
1. Execute the following script

sp_dropserver ''
go
sp_addserver '', local
go

2. Restart SQL Server service

ApexSQL Log 2005.04, part I

As I announced back in March ApexSQL Log 2005.04 is now in QA. It took more time that I thought back then but for a good reason: we went back to our keyboards and did more damage on new issues reported by some customers - especially scaling for very large transaction log files (50 Gb and greater.) In any case 2005.04 version is in QA right now, it's looking great and I hope it will be out soon. In the meantime I'm going to do a small series of posts on improvements that 2005.04 brings starting right now.

Reconstruction of UPDATE operations

Here's the problem of UPDATE reconstructions in a nutshell:
1. In general case, when logging an UPDATE statement, SQL Server just logs what was changed and into what.
2. These before/after state can correspond to everything from sub-field parts to cross-field parts of a row.

So from 1 and 2 comes the following definition of the problem:

To reconstruct fully what happened on a field level in an UPDATE statement one needs to know the state of the row in which the UPDATE statement occurred.

The difficult part of UPDATE reconstruction is finding that original state of the row. We have greatly improved this in version 2005.04 and I will blog more on this later on together with 2005.03/2005.04 examples.

Memory footprint and performance scaling

Storage is getting cheaper, processing power abounds, bandwidths are improving and this all leads to larger databases and higher transactions counts. Both of these increments - larger databases lead to larger MDF files which we use in our recovery process and more transactions lead to larger transaction logs - are beginning to weight on our "last year's" technology. Hence we felt it necessary to redesign the way memory is used by the application in order to allow greater scaling. We also wanted to improve the user experience with the application playing nicely with system resources (well, with memory and disk space at least - as with most other applications we want as much CPU and I/O as we can get.) In this kind of software there is a constant tension between just how much memory we should use (so that we don't have to re-read a lot - which slows things down of course) vs. how does our memory and I/O usage affect the ability of the system on which it is running and its own ability to successfully finish auditing. All of these things (better scaling in memory and performance, playing nicely with the rest of the applications) we have improved greatly in 2005.04. I plan to blog in detail on this soon.

Support for transaction log backups converted from 3rd party backups

Use of 3rd party backup tools is getting more frequent and some of the people using 3rd party backups are also our customers (or want to become one.) However, there is a problem with some 3rd party backups and their converters to MTF (Microsoft Tape Format) files as the converted MTF files do not always match files that SQL Server would have produced. This used to confuse ApexSQL Log but starting with version 2005.04 the application handles correctly these inconsistencies and will now read backups that doesn't perfectly match SQL Server's backups.

Support for reading transaction logs of SQL Server 7/2000 under SQL Server 2005 and vice versa

Format of transaction log changed significantly between SQL Server 2000 and 2005. In ApexSQL Log versions prior to 2005.04 it was not possible to read SQL Server 7/2000 transaction logs when connecting to SQL Server 2005 server or vice versa. However, as migration toward SQL Server 2005 is accelerating (which I believe from anecdotal evidence) there is more and more need for auditing of old transaction logs on newly migrated servers. This situation happens in two instances:
1. When migration is done by detaching the db files from old SQL Server and then attaching them to SQL Server 2005. In this case old transactions are still in the transaction log file but in the format of the previous version of SQL Server.
2. When the need arises to audit old transaction log backups (or detached transaction log files) and the new server is all that we have left available.
Starting with SQL Server 2005.04 we handle both of these cases seamlessly. We also handle reading of SQL Server 2005 transaction logs on SQL Server 7/2000 - just in case anyone ever needs that.

Auditing progress in GUI

With the current version of the software users can't really tell how much more will they have to wait before the results come in. This is , especially for large data sets that we are processing, and I'm sorry we never got around to fixing this prior to 2005.04. But the good news is - it's fixed and I think that audit progress bar is now informative and helpful. The progress is split into two parts:
1. First 50% of the progress are dedicated to initial processing of the transaction log sources we are auditing. Here's a typical shot:


2. Second 50% of the progress are dedicated to filtering of transaction log sources according to the parameters set by the user. However, even when the there is no progress in the number of matching entries, the time in log that is currently being analyzed is shown. Here's a typical shot:

This makes it easy to understand what's going on, where the application is and just how much more (approximately) there is to go.

I think that's it for today. But this isn't all - I'll blog more on 2005.04 soon.

What's the difference between database version and database compatibility level?

Paul Randal, over at SQL Server Storage Engine blog, discusses in his post the difference between database version and database compatibility level. When working with ApexSQL Log this difference is important since any db on SQL Server 2005, even with compatibility level of 70 (SQL Server 7) or 80 (SQL Server 2000), still has the same structure of system tables as a db with the level of 90 (SQL Server 2005). This matters in three cases:
1. When we are doing DDL analysis/recovery since we have to look for changes in different tables under SQL Server 7/2000 and SQL Server 2005 due to complete redesign of system tables in the latter version.
2. When users are directly auditing changes made to system tables (which is sometimes necessary.)
3. When auditing transaction log backups from one version of SQL Server on another. In ApexSQL Log 2005.03 transaction logs from SQL Server 7/2000 could not be read at SQL Server 2005 or vice versa. With the upcoming 2005.04 version this will be done seamlessly.

Of all of these cases only the 3rd is really problematic since we depend on SQL Server to provide us with meta-data for all the tables including system tables. So when we see an operation on say "sysobjects" table from a SQL Server 2000 transaction log attached to SQL Server 2005, we aren't able to reconstruct it since SQL Server 2005 lacks meta-data for "sysobjects" table. This case is very rare but even so we will try to solve it after 2005.04 by building in meta-data for system tables of all three versions of SQL Server that we support.

Btw, in case anyone is wondering how you can audit SQL Server 2005 transaction logs on SQL Server 7/2000 database (considering that it cannot be attached), it can be done by auditing transaction log backups or detached transaction logs.

Update

I have updated Links section with some Software Development and SQL Server links. I have also added Tools and C++ sections with some links. I'll be adding more of these in the future.

Neighborhood poisonings

In other related news to my cat Estrella poisoning, three weeks ago I adopted my first puppy ever.... which has also been poisoned and has been in the vet clinic since Monday. He hasn't eaten any solid food since then and it is still unclear when will he be able to come back home. These poisonings are just the latest in a long string of animal poisonings in my neighborhood. Last year another one of my cats died from it along with at least two more neighborhood cats and one dog. I managed save Rah, my tomcat, even though he was already in his death throws when I found him by pure chance (I managed to take him to the clinic just in time.) Since then he had another poisoning (another poison) and is now suffering from chronic renal failure. This year we had another neighborhood cat die just last month. And now this... This time I have located between 6 and 8 food baits with poison, all one or two houses from mine. Couple of months ago I have also found bait inside of my own garden. So far we have no idea who's doing the poisoning.

Ok, that's it for today's bad news. Next up - something I *wanted* to blog about today.

Estrella

One of my cats died last night due to poisoning. Estrella ("Star" in Spanish) came to live with me a bit over 3 years ago. She was a good momma cat and a loving companion. She will be remembered as a warm, sweet, dear nuisance whenever she wanted to be petted (which was often.) Here she is, two days after her kittens were born:

Estrella, you will be greatly missed. There is a hole in our lives where you used to be and the sadness in our hearts. We will not forget you. I hope that you have found your "Door into Summer".

VMWare Converter

Two days ago my notebook hard disk drive started failing... or at least the system seems to have stopped the disk (while I was away) and after I reset the system S.M.A.R.T. message appeared warning me of imminent disk failure and urging me to backup the data immediately. I have all my correspondence on that notebook but that's not the problem - the problem is that I have Office there and IM there and Skype and that I didn't (and still don't) want to pollute my development PCs with all those applications. While I was researching my options I stumbled upon VMWare Converter which turned out to be just what the doctor ordered: I used the application to convert the physical PC to a virtual OS image on my main development PC. The conversion process took almost 48 hours to finish (I had to restart the conversion process at one point due to network router reset) but it was worth it - I now have my notebook's image running on the development PC and it's working really great.

So VMWare Converter is pretty cool product as it is but here's my wish list for it:
1. Allow virtual machine to physical machine conversions! This is crucial. With this the circle would be complete allowing in my case for example to transfer back my notebook OS image to new hard disk drive once it's installed. It can be done (google for "VMWare V2P" without the quotes or see here) but not directly from the software and using 3rd party tools only (for hard disk image transfer)
2. Extend the software so that it can used as an incremental backup tool. Instead of backing up parts of hard disk, one would backup the entire system as a virtual OS image and VMWare would in future backups correctly recognize and backup just the changed parts. Then if the original PC say gets broken, lost, stolen, whatever one could be up and running the same image (as it was backed up) immediately.
3. Allow selection of parts of hard disks to be backed up. There are folders that contain huge amounts of data that doesn't really matter or is backed up somewhere else and which takes precious time during the conversion process.
4. In the case of network failure, conversion process is not reset but resumed once network comes up again (this was the only major annoyance but it was really *major* and it could have been avoided rather easily I think)
5. Allow VMWare Converter to be licensed on its own. Right now there is the free version and the Enterprise version which cannot be licensed on its own but one has to licenses who-knows-what to get it.

Once I get my notebook back I may dare and try Virtual 2 Physical (V2P) conversion. If I do, I'll post the results here. Somehow I have a feeling that it won't be as nearly as smooth as Physical 2 Virtual (P2V) conversion.

Turn AUTO_SHRINK off!!

Paul Randal (Principal Lead Program Manager, SQL Storage Engine) over at SQL Server Storage Engine blog, has posted today on why everybody should turn AUTO_SHRINK off for their production dbs. He enumerates three reasons why AUTO_SHRINK should be turned off. He's an authority on the SQL Server Storage Engine so I would heed what he says.

I have however one more reason to add: in case of catastrophic data loss (either through db corruption, DELETE without WHERE, DROP TABLE or TRUNCATE TABLE) from which you can't recover by restoring a backup (either because you don't have it or you don't have up to date transaction log backups or whatever), you really really *really* don't want SQL Server going in and shrinking the database files before you had a chance to recover the data. What you want to do instead is:
1. Put database in read-only mode immediately so that it's left in the state as close as possible to the state it was in in the moment of the data loss (if you experienced a hardware failure or something such your db files are now detached - just leave them like that for now)
2. Download ApexSQL Log and install it. If you need to analyze a database that's online install ApexSQL Log's server-side components on the server. It doesn't matter if you have or don't have transaction logs for the database - the application will try to recover data from what you have (besides, transaction logs can help only with the recovery of delete data)
3. Run ApexSQL Log's Recovery Wizard and chose the recovery option most adequate for the scenario. Recovery Wizard will recover all the data (including BLOB) it can still find in the database and create a recovery script.
4. Run recovery script on another database to check the data. If everything is fine - great! If there's a problem or you think that the software should have recovered more data, please contact us at support@apexsql.com and we will help you out.

On Technical Support

At ApexSQL we strive to give the best possible technical support we can. Brian (my boss) already blogged on this in Support Engineer Creed. I'm writing this to give my thanks to all those people in all these years that have put their trust in us. It gives me great joy to be daily talking to you, our customers, and I love being able to help you (and I feel bad when I can't.) Thank you.

Chileno!

Hoy recibí el comunicado oficial de mi ciudanania Chilena. Las palabras no me bastan para expresar la felcidad y la gratitud que siento.

Danas sam primio zvanicno obavestenje o mom Cileanskom drzavljanstvu. Reci mi nisu dovoljne da izdrazim srecu i zahvalnost koju osecam.

Today I have received the official notice of my Chilean citizenship. Words fail me to express the happiness and the gratitude I feel.

Upcoming ApexSQL Log 2005.04

We are in the final stages of releasing ApexSQL Log 2005.04 to our QA team. In the previous versions the bulk of improvements were in 64-bit support and in recovery process while auditing has sort of taken a backseat. But this upcoming version will bring some very serious improvements on the auditing end, especially with the infamous (at least in our little world of transaction log auditing) UPDATE reconstruction problem (which has been a very exciting problem to solve, in a geekish sort of way of course :) I invite those that weren't very happy with UPDATE auditing in the past to check it out once the new version is out. Beside this we have further improved BLOB recovery process (adding full support for new VAR*(MAX) types in SQL Server 2005) and we generally improved reliability, performance and memory footprint. All in all, I hope this new version will be a real boon for our customers.

Digital Blasphemy

As I mentioned couple of weeks ago I switched to two 1,600 x 1,200 screens. I can't say enough good things about that - it's just marvelous for productivity. However, with so much screen real estate the bland default background of Windows 2003 Server gets boring very quickly. So I set about to search for alternatives. I have known about Digital Blasphemy site for a long time and while I like the images very much it never attracted me so much as to subscribe to it - my screen was always too cluttered with too many windows to appreciate a great looking desktop background. This time however it was different and with a lot of great images provided for 3,200 x 1,200 I was hooked. I subscribed for a year and if it works out good for me I'll go with lifetime subscription next year.

Check out the site for yourself and see if you like it. All the art is created by just one guy, Ryan Bliss, and he's behind the site as well. You can check more about him here.

Going multi-monitor

Yesterday I have received my DELL 2007FP monitors! Here's a shot:


So far it has been a joy to work with and I'm really happy I have chosen two 20" 1600x1200 screens over one 24" 1920x1200 one. This is my primary development machine and it feels great to run VS2005 on one screen with Management Studio, Firefox, IE7, VMWare and MSDN Library running on the other!

First thing I did though was to install a trial of UltraMon. It's a great utility and unless something catastrophic happens with it I will buy it soon. The only thing so far that I wish it would do and it doesn't is show Alt+Tab window on both monitors, not just on the primary.

I also needed a new keyboard so I ran out and bought Microsoft Natural Ergonomic Keyboard 4000 (I sure hope they don't keep adding new adjectives to their product names.) I love Microsoft Natural keyboards and I have been using them happily for over 7 years now. I've been through three of them so far; my keyboards do heavy mileage (although one is still alive on another PC). On the other hand, I'm still using the good old Microsoft Intellisense Optical mouse - it's over 6 years old now and it still works great (although I'll admit that I've been eyeing a new one.)

In the background you can see my faithful HP notebook. It's almost two years old now so I will need to upgrade it soon. It runs Outlook, IM, Office and it collects general clutter. I develop on it only rarely.

ApexSQL Log 2005.03 released

Today we have released ApexSQL Log 2005.03. It's been six months since the last release and there are several major features that we packed in 2005.03, of which the most important, and definitely the most anticipated by our users, is full x64 support. This includes support for SQL Server 2005 x64 and for 32-bit SQL Server 7/2000/2005 running on Windows x64 operating systems (including online transaction log reading). Beside this we have added BLOB support to our Recovery Wizard (only when recovering from MDF files though, not from transaction log files) and we have greatly improved performance of MDF recovery. There is a host of other smaller features accompanied with another host of really important bug fixes.

I almost forgot that we have also created a separate installer for server-side components. This is now our recommended way to install server-side components since it allows uninstallation directly from Add/Remove Programs. Of course, remote installation/uninstallation from the client is still supported in GUI and CLI.

So, if you are interested in top-of-the-line transaction log reader (reading online and detached transaction logs and transaction log backups) and recovery tool (allowing recovery of deleted, dropped, truncated and even corrupted data and database objects from transaction log files or database files) for SQL Server 7, 2000 and 2005 (as of 12/29/2006 the only such tool on the market to support SQL Server 2005) that works equally well on your 32-bit and 64-bit SQL Servers, you may want to download here a 30 day evaluation version of ApexSQL Log 2005.03 and give it a go. While you are at it, maybe you will also want to check out our Universal Studio, packing all 9 of our tools with 1 year of full support and 1 year of major upgrades for just USD 1,999.

The full list of features and fixes of ApexSQL Log 2005.03 follows.

----------------------------------------------------
RELEASE 2005.03.0417
DATE: 29 December 2006
DESCRIPTION: Major Enhancement/Fix release
----------------------------------------------------

Enhancements:
- Added support for Windows 64-bit and SQL Server 2005 64-bit for x64 CPUs (MAJOR ENHANCEMENT)
- Added BLOB support in recovery of deleted rows and rows in truncated and dropped tables when using database sources for recovery (online database files and MDF files) (MAJOR ENHANCEMENT)
- Significantly improved performance of data recovery from MDF files, online or detached (MAJOR ENHANCEMENT)
- Added support for online transaction log and database files on drives mounted as NTFS folders.
- Added support for in-row values for BLOB types.
- Added SERVER_NAME column to Connection Monitor table allowing for filtering by the name of the server where transaction log was created.
- Added xp_ApexSqlLogMonitor_Enable and xp_ApexSqlLogMonitor_Disable extended procedures.
- In generation of UNDO/REDO statements:
- Added SET IDENTITY_INSERT ON/OFF for INSERT operations.
- Added transaction wrapping for DELETE operations.
- Changed preference for construction of WHERE statments to primary key over clustered index.
- For heap tables, added generation of WHERE clause from values of all non-BLOB fields.
- Added skipping of BLOB and TIMESTAMP fields.
- In recovery from detached MDF files, added loading of meta-data from a live database when such is unaivalable in MDF files.
- For recovery on SQL Server 2005, modified algorhitms to improve chances of success in suboptimal recovery scenarios.
- Added SET NOCOUNT ON to recovery scripts.

Changes:
- Last used filter now is stored per server and database.
- Added server name to login information captured by Connection Monitor.

Fixes:
- A problem with conversion of _variant_t to __int64 (MAJOR FIX)
- A problem with memory over-consumption (MAJOR FIX)
- A problem with activation not taking immediate effect on the server side (MAJOR FIX)
- A problem with old ID mapping feature (MAJOR FIX)
- A problem with multiple value switches in CLI (MAJOR FIX)
- Parsing of table names in command line interface (table names can now be specified with within angular brackets)
- A problem with NULL values in WHERE statements.
- A problem with UNICODE table names and table names with quotes in CLI and Recovery Wizard.
- A problem with Connection Monitor with automatic restart.
- A problem with Connection Monitor sometimes failing to flush rows from temporary login table.
- A rare problem with table names on case-sensitive databases.
- A problem with user ID showing as N/A even when it's known.
- A problem with refreshing of transaction log operations grid.
- A problem with NULL/NOT NULL flag in table DDL scripts.
- A rare problem with transaction log reading.
- A rare unhandled NULL exception.
- A rare problem of mistaken table ID for dropped tables on SQL Server 2005.
- An exception in About box when not connected to any server.
- Several errors in captions and messages.
- Several icons in the Log Filter dialog.

Freedom

It strikes me as interesting that my last two posts were both, in an indirect way, posts on freedom. First I posted on SQL Server Central being bought by an industry vendor and losing its independence. Then I posted on passing away of Milton Friedman. And I think there is a connection between these two things.

Mr. Friedman believed, as I do, in free and unregulated markets in which this kind of move that Red-Gate made is nobody's business but of the parties involved directly in the transaction. I couldn't agree more. So why are we and others making any noise about it? My answer is simple - to stop the spin and pretenses currently being woven by Red-Gate's spin doctors. Red-Gate bought a site and they bought it for the brand, the membership list and, I believe, the control of information on the site (and probably some other things I didn't think of.) So why not just say so? Because it would be a terrible PR to just go and say "we won't publish negative reviews of our tools, we won't publish positive reviews of the tools of our competitors, we won't allow advertising from our competitors" and so on. Since Red-Gate won't say it - I guess somebody else has to say it.