Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
By Sprezz | Thursday, 8 November 2012 16:15 | 1 Comments
Sometimes, just when we're starting to think that we've seen it all (with the obvious exception of a man eating his own head) we're hit with a support issue that really has us stumped.

Recently we came across just such a problem. The client was finding that very intermittently at one specific site, an attach to a location would fail. This created a problem as the client wasn't using get_status to check for a failure and was just continuing on with the rest of their program leading to corrupted data.

An awful lot of sleuthing followed. The problem manifested itself in an xlate returning a null value due to the table it was xlating from not being attached. So initially the blame fell on xlate - perhaps it was caching an old value in some way? FLUSHs were inserted into the code to ensure cache wasn't being used - but no joy. Long support calls ensued and the States gamely became involved in trying to find a solution.

Eventually the issue was traced by the client to the use of the Drive() command. You probably think you know this command well - but let's refresh your memory. The help for this says

Returns the current operating system path from which OpenInsight is running.

The value returned will be the current operating system path for the default drive, directory, subdirectory, or volume. The default drive is the drive current at logon time.

Now from the first line you MIGHT think that Drive() returns the current operating system path from which OpenInsight was booted. But you'd be wrong. The devil, as they say, is in the details. The second paragraph more accurately states that the value returned in Drive() will be the current operating system path and that's another beast entirely. What that first line ought to say is "Returns the current operating system path for the drive from which OpenInsight is running".

Y'see Windows carrys around a pile of environmental variables and one of them is the current directory. So if some wascally wabbit changes this value that's what you'll get returned. Now under normal circumstances this shouldn't affect us as it is considered good Windows etiquette that if you change the current operating system path you put it back how you found it. But some people don't write perfect code.

What the client found was that Drive() was pointing to a driver directory in the Windows folder, not the OpenInsight subdirectory. Because of this the attach failed. Because the attach failed more problems ensued.

But what had caused this change of directory? Well we can only assume (given the driver directory pointed to) that OIPI had initialised a printer and that printer driver had a bug that left the wrong path set. There's nothing we can do to fix that other than change the driver or the printer.

So what do we take away from this? Simply, that Drive() isn't always the OI directory - and that get_status is your friend after calling ANY system routine as you never know when or why they might fail!


  • That rings a bell! We found the same thing using another third party product - that on return the 'current directory' had been changed. It appears that this can be restored if the behaviour is known, or just being cautious:

    Wshell = OleCreateInstance( 'WScript.Shell')
    revboot = Wshell->CurrentDirectory

    // Do the dirty work...

    If Wshell->CurrentDirectory # revboot then
    Wshell->CurrentDirectory = revboot

    So then any subsequent calls to Drive() return what is usually expected.

    By Anonymous Matt Crozier, At 12 November 2012 at 20:25  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

Pixel Footer R1 C1 Pixel