Friday, October 07, 2005

Why policies are made

I have a business policy to never load new software on my development machine right before a conference where I am presenting. The policy was created years ago when I did this and it triggered a panic attack during a rehearsal days before I was headed to GLGDW in Milwaukee. Demonstrations I had run a dozen times all of a sudden stopped working. Burned once and hopefully never to happen again... Well until yesterday.

Yesterday my client set me up for access to their Citrix box so I can do remote support. I have loaded the Citrix client on other computers without incident so I never gave it a thought when we went to set this up. The Citrix client installed just fine. Life is good.

Then I started VFP 9 (with the SP1 beta installed) which I have been using for more than a week now. The VFP window is displayed, the Stonefield Database Toolkit splash screen is display, a couple more of my startup program items are processed and then the Windows Installer kicks in and asks me for the VFP 9 install CD. What the heck?

I don't have the CD with me (a freak of nature by itself) so I cancel the install and quit VFP 9. I start up VFP 9 without the SP applied and it does the same thing. Argh! What the heck did Citrix install that could possibly mess up the VFP files? The frustrating thing about this is I probably will never know, but I suspect it is one of the ActiveX controls. I supplied the Windows Installer with the CD when I returned back to my office and all is well again. All I could think of is how bad my sessions would go this Saturday at the Grand Rapids Area Fox User Group and next week in Tempe at the Southwest Fox conference. Life is too short to have to worry about this kind of stuff happening to my machine.

So back to the business policy. I am going to add language like "never, ever" (in bold) to the "do not load any software two weeks before a conference" policy, and make this an offence punishable by termination. How hard is it to fire yourself?

4 Comments:

At 10/07/2005 12:04:00 PM, Anonymous Anonymous said...

How hard is it to fire yourself? Put on a wig, look at yourself in the mirror, and in your best Donald Trump imitation say, "You're fired".

 
At 10/07/2005 01:10:00 PM, Anonymous Malcolm Greene said...

Rick,

I recently had the exact same thing happen with the VFP 9 setup trying to run again every time I started VFP. I've never had this happen with any of the previous releases of VFP so I believe the root cause of this behavior is VFP's use of the DREADED Windows Installer technology trying to self-repair the VFP 9 setup when certain configuration details change on your workstation.

As you point out, the way to repair this is to re-run the VFP setup.

In addition to remembering to bring setup CD's with me, I've also begun archiving copies of important CD's (Office, VS Studio, VFP, etc) on my hard drive ... just in case.

Good luck with your presentations at SWFox!

Malcolm

 
At 10/07/2005 02:24:00 PM, Blogger Rick Schummer said...

Malcolm,

VFP has been using the same setup probably since VFP 6. I don't think the root cause it the Windows Installer, rather something else destroying or changing a file belonging to or shared with VFP. In fact, VFP and Windows Installer are doing exactly what they are designed to do when something or someone monkeys around with the files.

My curiosity is the what.

 
At 10/07/2005 07:23:00 PM, Anonymous Paul Mrozowski said...

Take a look in the event log; it will usually have an entry there telling you which component it thinks is messed up. If it's just the class ID you'll have to search the registry for the program ID, but it will at least point you in the right direction.

-Paul

 

Post a Comment

<< Home