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 t
he 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!
1 Comments:
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
End
So then any subsequent calls to Drive() return what is usually expected.
By Matt Crozier, At 12 November 2012 at 20:25
Post a Comment
Subscribe to Post Comments [Atom]
<< Home