Welcome to 64-bit hell

I just spent a few hours trying to figure out an issue on a project I started a while back to automate the SQL replication setup for any servers we add to our environment.  I started the project when I had some free time a few months ago, then got going on another project which took preference, and now finally have time to get going again.  First thing I did after loading the solution was hit F5 to run it, making sure that everything is as it should.  Also remembering that I left it in a working state when I put it on the back-burner.

Then I get this beauty

"Could not load file or assembly 'Microsoft.SqlServer.Replication, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. An attempt was made to load a program with an incorrect format."

Now my first reaction was that I reinstalled my machine recently, upgrading from XP SP2 to Windows 2008 64-bit edition, so I double checked my installation of the SQL Server SDK, and the various other things that are referenced in this project, but no luck.  AARRRRGGGHHH!!!

Boot up the XP VM, test the project there and it works like it should.

So, I went back to my dev environment and do what I should have done in the first place, click that friendly "Search for more help online".  And first in the list is the description for the System.BadImageFormatException with a simple solution.

Turns out that the SQL Replication SDK was developed for 32bit platforms only, so go to the Project Properties, select the Build page and set the Target Platform to x86.  Hit F5, and my project is back to a working state.

SSIS – Accessing variables from script components

 In SSIS there are are two different types of script components.  The Control Flow script, and the Data Flow script.  These 2 use different ways of accessing package variables, which was a bit confusing the first time I used teh Data Flow script component.

In the Control Flow script component you access package variables in a similar way to how DTS used to do it.


 However, trying this in the DataFlow script component only cause some compilation errors and nothing more.

After doing some searching, I eventually found the simple solution that was staring me in the face all along, I just never tried it.


In both cases you still have to tell the component which variables you're passing in on the property page.


Don’t you just love it how Internet Explorer 7 will take you to the IE7 download page for an “upgrade” every now and then.  Surely their site can detect that you are already using it…Yes I still use it for internal company sites, it is just less hassle.

Garmin, educate your vendors

I've helped two people in the last year to update the firmware on their Garmin units.  It is a fairly simple procedure, and it is FREE.  But in both cases that is not what the stores where the bought the units told them.  Both stores, different ones, tried to sell them new map software, which would not help to fix the issues they were experiencing, but on which the store would make a big profit.

Surely these sales people should have the training and INTEGRITY to help Garmin's clients, and if not, why are they still agents? 

Dear Multichoice…

…I have a few feature requests.

1. Would it be possible for me to instruct my PVR to record a specific show from the Internet.  I'm not always home when I realise that I forgot to program it to record a "cannot be missed" show or event.  Even better, allow me to do this from my mobile phone.

2. Why should I pay for having all the channels if I only watch a few of them?  Can I not rather have a choice selecting only the channels I want?  There are some channels that I will never watch, they do not appeal to me.  I don't see why I should pay for the "privilege" of having them.  If that is not financially feasible, make up packages where I can buy bundles of 10 channels at a time.  And allow me to swap these on a monthly basis, online if possible.  Surely this would make the service more affordable for most, and you'd grow your subscriber base.

Did your upgrade kill usability?

Our office building's elevators recently went through an "upgrade" process.  All the elevator mechanisms were replaced, and then they replaced the management system.

The new management system decides which elevator you'll be using when you push the button.  It has a nice big arrow above the lift door that lights up while you're waiting, and then starts flashing when the elevator arrives, so the moment you push the button you know which elevator to go stand in front of.  Only sometimes the system realises that the particular elevator is in use between other floors, and then switches to another.

At ground floor level they've installed a set of buttons for each floor in the building, and the system then lets you know which elevator will stop on your floor.  The problem here is that most people don't even bother looking, and just storm into the first elevator that arrives.  You just have to wait for the first stop before you can push your floor button again to make the elevator stop there.

I have no idea how the system calculates which elevator to use, but what I do know is that the average wait time has gone from 30 seconds to about 3 minutes. Surely the developers of the management system should have tested and timed the new system in a real building, preferably their own.  Why try to predict which elevator to use if you can just stop the first one that comes past going in the right direction.

The insides of the new elevators look very nice, but they're still just as shaky as what they used to be.  The only improvement I can really see here is that you can now switch off buttons that were pressed by mistake.

 What I'm getting to here, is that, hopefully, when you get a brilliant idea for your system as the developer, you actually do some homework on the usability of the feature before implementing the changes into your production environment.  I've seen many users hampered by a design decision a developer took, because it would be cool to design, instead of thinking what would benefit the users.

Installing Ubuntu on an eMac

Sometime last year I bought a second hand eMac for R500, thinking it was about time that I started learning non-Microsoft products.  The machine was great and for the first few months everything ran great and I learnt quite a bit about Mac OS X 9.x.  The same person then gave me an iMac that was taking up needed space in his garage.  I got the iMac home, tried to switch it on, but it was dead, and clearly not serviceable by mere mortals.  So that got tossed, but I kept the software that came with it seeing the eMac had nothing.

I noticed that the iMac's software package included an upgrade disc for OS X 10.1 (Jaguar I think), and the tinkerer in me woke up immediately.  I had to give this a try, see what changed.  I booted with the disc, went through the process and made my first mistake on step 1.  Where you choose the partition on which to install, you also have the option to clear it out.  Guess what, that was the first thing I did, happily continued with my installation, only to be told, sorry for you, there's no prior version of OS X on this drive, cannot install.

No problem I thought, just boot up with the iMac's install disk for version 9.2, install that and then do the upgrade.  Only the iMac's disk would not boot on the eMac.  No I had a nice big white doorstop on my hands. 

Plan B was to get a copy of Tiger and install that, but the importer & distributors of Apple products in SA had another plan for me.  Since there is supposed to be an upgrade released in October, they thought it would be wise to stop importing and stocking any copies at the end of 2006.  So every shop I went to had the family pack in stock, but no single licenses.  I only have one machine capable of running OS X, so why the hell would I pay double the price for 3 licenses.  Still had a big white doorstop on my hands.

Fast forward a few months, I take delivery of a set of Ubuntu disks, some non-microsoft technology I can learn on a machine that is serviceable by mortals.  But lo and behold, included in the package there's an Ubuntu disk "For your Mac".  Had to try this.  So I fired up my big white doorstop, had to eject the CD drive with a paperclip because the eject button on the keyboard did not work witouh any OS installed, and booted up with the CD.  Now the install I did on a VPC worked fine first time, and looked to be working fine on the Mac.  Until it started loading X to get to the installation icons.   X did not like the eMac and failed with a particularly ugly error message, I can't quite remember the wording.

Time for some serious googling.

I found a few articles on installing Ubuntu on the eMac, but none of the advice worked, until I downloaded the alternative ISO mentioned in this article.

Ripped it to cd, booted the doorstop, and have never seen an easier installation.  After selecting a few basic options like language and machine name, the install did the rest, and I now have a working eMac again, although not with the intended OS.