My web host sent out a notification last week that they were changing servers and updating from Windows Server 2003 to 2012.

To make this transition easier for you we have moved your entire account under the new environment using an offline migration meaning that your old website will remain active until you will verify that all your contents/databases have been moved under the new environment and finally switch your nameservers to have your domains pointed over under the new servers.

We are also afraid that as this was an automated process using a migration tool, some web/database contents might not be synchronized between our old and new shared windows servers. We urge you to check your contents as soon as possible and update your connection strings/nameservers as soon as possible to have your entire domain pointed over to the new environment as your old account under the old shared windows server will be removed in 15 days.

Yeah, right, their automated tool failed miserably for me. First of all, they didn’t transfer my old password, so that took 2 days to straighten out.

When I was finally able to log in I noticed they didn’t transfer any of my databases. Really? That took another day.

I changed the database connection string in my webconfig file and FTP’d the updated file to the server.

Then I asked, “how do I test the web site before go live?” The sysadmin responded:

update your name servers from your domain registrar then you test your website working fine on new servers or not.

To which I replied “So you’re telling me I have to go live in order to test it? I’d prefer not to do that if possible. If not, well, I guess I’ll jump in both feet.”

No response, so I did the DNS change. Well, of course it crashed.

Much later I received a response from the “good” sysadmin:

You can always test your website using your local hosts file. Simply add the following lines under your C:\Windows\System32\Drivers\etc\Hosts file:
==
XX.XXX.XXX.X rxkinetics.net
==
Then clear your browser cache, flush your DNS and you should be able to browse your website hosted under our new environment before you will have your nameservers updated.

I’ve since switched back to the old DNS, but that take will take another day to revert back to the old server. And I’m worried that it will not actually revert back.

I should have known better. Something like this always happens to me with ASP.NET. Make one little change and it stops working, and doesn’t give any clue as to why. I haven’t touched this code in three years because I didn’t want to break it.

I’m pretty sure it’s a setting on the admin side, which I have no control over. I believe it’s related to this problem I blogged about 3 years ago Fun with ASP dot NET.

In 1984, shortly after the pharmacy received a new IBM-PC XT with a green screen monitor and a dot matrix printer, I wrote my first practical pharmacy program: UD Labels.

In those days unit-dose packaging was a time-consuming and messy affair as the labels were printed with a mimeograph machine. It utilized stencils which were typed up on an IBM typewriter with the ribbon removed. The stencils were small and it was nearly impossible to line them up on the typewriter roller.

Before printing the roller had to be inked. Then, depending on how well it was inked, the first run of labels was either too faint or smeared with excess ink. After trial and error, eventually you were able to print labels that were somewhat legible.

The labels were pushed into the printing area with a mechanical arm, and often jammed or misaligned within the loud and complicated Rube Goldberg contraption. If you only needed a few pills for a rarely used drug, the machine was overkill. To save time, we dispensed a few pills into a prescription vial with a typed label. Any remaining pills had to be discarded.

It came to me one day while printing a report from the PC and watching (listening) to that ridiculous packaging machine chug away at labels, that a computer printer would be much easier, and would produce labels that could be easily read.

It took me about 2 days to write a simple little program in IBM BASIC, and it worked like a charm. My regional manager Russ Collins came by for a visit a few weeks later and I showed him what I’d developed. Shortly thereafter I was getting requests from other DOPS in our region for a copy of the program. And thus, my little software publishing enterprise began.

I’ve made countless improvements to the program in the thirty years since. The latest version is secure, has full database capabilities, and has the ability to print bar codes in any format.

A few software companies have since copied my idea, and charge a ridiculous price for their intellectual thievery. Even my current employer was duped into buying one of these ridiculously over-priced and impractical pieces of crapware. I was off one week then came back to find that all traces of my program were erased, they even erased all the old data. I was not advised or consulted. Blatant disrespect that I will certainly never forget.

Which brings us to 2014, thirty years after my brainstorm, UD labels has become the most popular RxKinetics PC software. Karma.

Tim “the tool man” approves.

“More models”.. I get this request often, and my usual answer is, in as nice a way as possible, do the work yourself lazy ass. I gave you the tools, learn how to use them.

But most people don’t get it. This sh*t isn’t carved into stone tablets by the hand of God. The way pharmacists are taught these days everything has to be in writing somewhere. So, here it is: Wagner: Fundamentals of Pharmacokinetics, nineteen-f**king-SEVENTY-FIVE. Yup, that’s right, almost FORTY f**king years ago. You weren’t even a gleam in your daddy’s eye. So, look it up old school in an actual lie-bary (sic) because it ain’t on the f**king inter-webs.

I’ve described the Wagner method before, in great detail here . No lie-bary required!

And now I’ve done all that work for you too! All it takes is a suck-up email to appeal to my altruism: “I like your program a lot because it is serious about PK/PD and pushes the concept of PK target attainment. As such, to optimize dosing with Abx is critical and apps to me are the future. I request that you build out the PK ability to dose other common beta lactams as well as the aztreonam and ceftazidime. I realize this can be done by entering the necessary parameters in the customizable part of the app but it would be easier for us if this was built in.”

Well, here it is.

I’ve also built the functionality to download these models into the Antibiotic Kinetics for Windows program.

AbPK how to

Eventually this functionality will be added to the iOS and Android versions.

Group sing-along:

Since adding EurekaLog to APK I’ve been able to track down the causes of some perplexing errors.

EConvertError

“X is not a valid floating point value”, this error has puzzled me for years. I have actually never seen it myself in 15+ years of using the program. I am only aware of it because of scattered reports from users.

Once nice feature of the EurekaLog report is a screenshot of the user’s current screen.

As usual, it is the user causing the error. Instead of entering a valid decimal value, ie, [1.02], they accidentally add a decimal point or two: [1.02.] or [1..02], etc. This error has cropped up twice in only 30 reports. I never would have imagined that someone would do something so fundamentally wrong. I also believe that it is impossible to imagine every possible scenario of software usage. I think it would take a troop of monkeys randomly pounding on multiple keyboards to approximate the myriad of potential mistakes.

Regardless, any software program must be able to prevent a user’s dumb mistake from causing a fatal error. All of the input boxes for numeric values in APK are coupled to procedures to prevent non-numeric input:
procedure TfrmMain.EditRecentSCrKeyPress(Sender: TObject; var Key: Char);
begin
if not (Key in ['0'..'9', DecimalSep, #8]) then
Key := #0;
end;

However, that’s not enough. I was under the impression that the StrToFloat function was fault tolerant, i.e., if the input was wrong, it would output a zero.
RecentSCr :=0;
if EditRecentSCr.Text <> '' then
RecentSCr := StrToFloat(EditRecentSCr.Text);

Unfortunately that’s not true. Instead, execution is halted with a fatal error and the program crashes.

The little known expression SysUtils.TryStrToFloat does have fault tolerance.
RecentSCr :=0;
if EditRecentSCr.Text <> '' then
TryStrToFloat(EditRecentSCr.Text, RecentSCr);
if RecentSCr <= 0 then begin ValidPatData := False; MessageDlg('Data entry error', 'Serum creatinine is a required field.', mtError, [mbOK], 100, dckActiveForm); EditRecentSCr.SetFocus; Exit; end;

Alternatively one can test the boolean result of TryStrToFloat within an if..then block to flag an error:
KelSD:=0;
if TryStrToFloat(EditKel.Text, KelSD) = False then
begin
IsOkay := False;
ErrMsg := 'Kel SD';
end;

So, I've spent the better part of 3 days re-coding all the StrToFloat calls to TryStrToFloat (also StrToInt -> TryStrToInt). And I've been able to prevent fatal errors.

However, if the field is linked to a database, the type of error appears to be unavoidable. Although it's not a fatal error, it still generates a EurekaLog error dialog.

I feel that the EurekaLog dialog doesn't really fit this situation. I'd rather catch the error, display a dialog, and rollback the edit which produced the error. But I've hit a brick wall, unable to get to the event triggering the error. I've tried BeforePost, PostError, BeforeEdit, and EditError, none of these events are trapped when a db field is edited. In the case of database fields it appears that no event is triggered. WTF!?

EIniFileException

Another error that EurekaLog discovered is "unable to save settings". The most fundamental requirement for use of this program is to have full read and write privileges to the APK folder. Without that, you can't really use the software. Again, regardless, any software program should not allow a user's dumb mistake to cause a fatal error. So, I combed through all code, and surrounded all ini writes in try..try..finally..except blocks:
try
UserIni := TIniFile.Create(AppDataPath + 'screen.ini');
try
UserIni.WriteInteger('Window Placement', 'Main.Top', frmMain.Top);
UserIni.WriteInteger('Window Placement', 'Main.Left', frmMain.Left);
finally
UserIni.Free;
end;
except
on E:Exception do
begin
MessageDlg('Error saving window placement',
E.Message,
mtError, [mbOK], 690, dckActiveForm);
Action := caFree;
end;
end;

ERangeError

The other common error that I've addressed in this update is "range check error". Unfortunately there are not enough reports to establish a pattern, so I simply switched off range error checking. Within the compiler settings, range error checking is turned off by default. I only switched it on because some Delphi guru advised it. Well, sorry guru, in the end your advice caused more problems than it solved.

Peace out.

Post script

Today I figured out how to bypass the EurekaLog dialog for the EDatabaseError 'not a valid floating point value':

1. Activated Exception Filters in the EurekaLog options
2. Added EDatabaseError
3. Changed handler to RLT

Result is this "somewhat" more user friendly dialog, without the unnecessary "Send Error Report" option.: