The Facts:

I'm maintaining reconciliation software that sucks in two files,
compares them and writes like information to a matching table, unlike
info to an exceptions table.  The program is written in VB 3.0 Professional,
hooked up to an Access Database, both running under Windows 3.1.

The Problem:

Here's THE THING.  The thing is that every so often, say once every two to three
weeks, the compare just doesn't do anything.  Run it again, it behaves as it
should.  This is at the client's site.  Here, I can't make it break.  Both
the executable and interpreted versions work like champs.  It's just like
taking the car to the mechanic and having the car start purring like a
kitten as you turn onto the mechanic's block.

What's been done, so far:

Tons o'Testing here, no problems.  The client has sent me exact setups of the
database, the exe he ran, and the files compared.  No problems running it.
Got the results that should be gotten.  

Summary:

I don't know what else to do besides to start pointing fingers at VB, Access
or the client.  Best bet is that it's User error.  But it's a simple, couple
click operation.  One they've been doing for a month and a half period already.

So I'm thinking.  Has anyone else had problems with VB created executables?
I know in the past that sometimes the created exe will croak when I double
click on it.  I just recreate it and it usually works fine.  Could it be that
some Gremlin has introduced itself?  I have to zip it up to send it to him.
Maybe that's the problem.

Anybody know of a sure fire approach of distributing the goods?

TIA for any assistance.
--
"A journey of a thousand miles begins with the first step."  
                                              Lao-Tse, Taoist Philosopher

What happens to your app if they click the buttons twice or more in rapid
succession? We tore our hair out here over an app that consisted of a single
form with three text boxes and a single command button. Some users could
blow that thing away at odd intervals and could not explain (even under
torture... woops, I mean detailed questioning...) what they were doing that
was different from the rest of the user population. Finally, one of us went
out and happened to catch him double-clicking on the damn button! We went
in and added code to *disable* the button until the underlying routine had
finished, and the problems went away immediately.

--
===========================================================================
Philippe D. Nave, Jr. | We're sorry - all our .sigs are busy right now.
Denver, Colorado USA  | Please re-read this message, and the next available

One debugging aid I've found useful in "what the hell is going on"
situations is writing out to a log file.  Write a function that takes
in a string, opens the log file, appends the string (with time/date if
you like), and closes it.  Then call the function from "strategic"
locations (i.e., button clicks, processing loops, etc.).  
You'll have to figure out a purging method, like delete log file at
beginning of day or whatevers, and a switch in an ini to enable the
log at all.

[snip]

The designers of operating systems know all about the non-repeatable
intermittent fault that occurs only on Wednesday afternoons when the
temperature is 27 degrees with 69 tasks and 1,139,408 bytes of free
memory.

The cure is called 'instrumentation'. You add lots of debug code that
prints to a log file. Then you give them this version. Every time it
runs, it'll create log file entries of everything it does and you can
then review this file after a crash - like an aircraft flight
recorder.

Avanti make a useful product called PinPoint that will add this code
to your project automatically - it is normally used for profiling but
would be most useful in this context. Or its easy to do manually.
Record when you enter a routine and the time of day plus param values
plus when you exit as a minimum. Then wait.

Of course, if you're really unlucky, adding the instrumentation code
causes the problem to go away. There are tricks here but lets try this
one first... then repost if the problem wasn't resolvable.

Sticking an On Error Resume Next at the top of a procedure is
what I would call the "Ignorance is Bliss" school of programming.

Cheers,

Joe

Never underestimate the power of a WAG.

http://www.citilink.com/~jgarrick