Dell Studio: Slow mouse (touchpad) and missing keys issue

Just before I installed Windows 7, the new Dell Studio suddenly started slowing down. The touchpad movements would be jerky and some keys wouldn’t get pressed. A post on a dell support forum outlined the same problem that I had and the keys the other user reported were the exact same ones.

What’s even worse is that the support site is so bad I can’t even locate that forum post. But here are a couple I found reporting the same problem (one with keyboard problems here and another with touchpad problems).

Draining the battery power was one suggestion but couldn’t be bothered doing that, I just went with updating the BIOS to the latest version (A05) and viola that fixed it.

So here’s to anyone having the same problem with a Dell Studio where the whole machine goes into slow motion when moving the mouse with the touchpad as well as when punching in the keys into the keyboard go missing. Solution: Update your BIOS to the latest version.

Dell Studio: Slow mouse (touchpad) and missing keys issue

Running Windows 7 Beta

With everyone reporting that Windows 7 beta was very stable I upgraded both my wife’s Dell Studio and my Dell 64-bit XPS to Windows 7.

Both setups ran fine without a hitch although the upgrade route took a couple of extra hours with all the migrating of application and user settings.

The good news is that I’ve been using both for over a week without any major hitches. The only problems I’ve had so far are to do with the 64-bit install. The first one being Windows Live Mesh which stays forever at the ‘Live mesh is starting’ step (there doesn’t seem to be any kind of fix out for this) and Google Chrome which flat out doesn’t work unless you add a flag to it’s startup. This seems to work for most cases except for a few place where it fails like the new Gmail Offline access using Gears.

Running Windows 7 Beta

Migrating from BlogEngine.NET to WordPress

Yet another migration post, feels like just yesterday I migrated from dasBlog to BlogEngine.NET.

My justification was that I didn’t want to be manually updating my blog with each new release.

With Aneef graciously offering to host my site I’d be cutting down on my hosting bill as well! How sweet is that?

So here’s how I made the move.

  • First I setup a new instance of WordPress on my host account. Now this is the absolutest fun part, with Fantastico it takes just two clicks and literally two seconds to install WP, plus upgrading to the latest version of WordPress is going to be a breeze as well!

fantastico-wordpress-install

  • Next we’ll export our posts to BlogML from the BlogEngine.NET admin site.
  • You’ll need to tweak this file a bit before the import. Search for .axd files and you’ll realize the first problem. BlogEngine seems to pull down the images through an .axd file, a simple search and replace should fix this problem. You might want to move your images to the wp-content/uploads folder as well since it will become easier to backup your stuff.
  • In the BlogML file, the categories seem to have a GUID, which I think I might have inherited from dasBlog, but if you do come across the problem you can either do a search and replace with the GUIDs or after importing into WordPress rename the category from the Admin site.
  • Finally you’ll need to add the BlogML Import plugin to your WP install. Just grab the zip file from Kavinda, unzip and upload them to the wp-admin/imports folder check his post and the related posts if you have trouble setting it up.
  • From the WordPress admin menu click import, supply your file and your done!
  • You’ll of course need to upload your images as well.
  • If your using FeedBurner remember to change the source address of FeedBurner and also use the FeedBurner plugin from Google so that new user’s will get the FeedBurner url when they subscribe to your blog.

Enjoy! Let me know if you have any issues migrating.

Migrating from BlogEngine.NET to WordPress

Deleting millions of records from a table without blowing the transaction log

Over the weekend I realized that deleting 80% of the records on a table with 87 million rows is not quite as easy as issuing a delete statement with a where criteria.

The main reason is that the transaction log quickly grows as it needs to keep track of all the uncommitted rows that are being deleted. In my case the database file was 60GB and the log file grew quickly from a mere 40MB to 32GB before I ran out of disk space and the database goes into recovery mode.

Browsing through blogs I narrowed my scenario to two options.

  1. Move the required records over to a temporary table and issue a truncate on the table you want to delete.
  2. Issue the deletes in batches so that the log file doesn’t fill up.

The first option seems to take the shorter time to execute but I didn’t want to go through the effort of removing and adding foreign keys  and renaming tables. So I went with the second option. Here’s the script I used for SQL Server which deletes 10,000 rows at a time and commits them.

DECLARE @continue INT
DECLARE @rowcount INT
 
SET @continue = 1
WHILE @continue = 1
BEGIN
    PRINT GETDATE()
    SET ROWCOUNT 10000
    BEGIN TRANSACTION
    DELETE FROM Transactions WHERE  TradeDate IS NULL
    SET @rowcount = @@rowcount 
    COMMIT
    PRINT GETDATE()
    IF @rowcount = 0
    BEGIN
        SET @continue = 0
    END
END

The print statements help to show you how things are moving along.

(10000 row(s) affected)

Jan  1 2009 11:54PM

Jan  1 2009 11:54PM

(10000 row(s) affected)

Jan  1 2009 11:55PM

Jan  1 2009 11:55PM

Seven hours later the script is still executing with 39 million rows deleted so far and the log file currently at 700MB.

Deleting millions of records from a table without blowing the transaction log