[AccessD] Access97 on W2000 crashes

Andy,

Can you convert your app to MS Access 2003 just for testing purposes? Reason
is that MS Access 2003 is more stable usually and it may give you exact
position where your code is troublesome...

<<<
>  but there can't
> be a conventional bug if it's so inconsistent.
>>>
It still can be a conventional bug:

1. If Win32 API is used
2. If late binding is used
3. If default properties (with late binding) are used
4. If withevents is used
...

For example late binding uses COM marshaling and for that it dynamically
allocates memory from the heap memory area - and what could be there can't
be predicted - "unexpected" crash when late binding used in "DLL-hell"
environment....

<<<
bit like a very big and complex wizard
>>>
Do you mean that during your tests you assign values to the wizard form
controls using saved in tables' values?
Do you have checkboxes on your wizard form?

Shamil

P.S. Have a look on real life case how WinAPI calls may result in
"unexpected" bugs:

<<<
http://www.lebans.com/monthcalendar.htm

Version 3.8

** BUG FIX**  Pressing the SHIFT Key under WIN2K caused a GPF. My partner
Pedro Gil found the cause. I had inadvertently left in some debug code that
was calling CopyMemory on what is now , under the current logic, a random
memory address. Under Win9x you can get away with this but with WIN2K's more
advanced memory protection logic you will generate an exception.

>>>

----- Original Message ----- 
From: "Andy Lacey" <andy at minstersystems.co.uk>
To: "'Access Developers discussion and problem solving'"
<accessd at databaseadvisors.com>
Sent: Wednesday, January 11, 2006 1:07 AM
Subject: Re: [AccessD] Access97 on W2000 crashes


> No, exactly the same data. Believe me. And I key absolutely nothing in.
It's
> a quoation module. Very complex but it's written such that the user's last
> selections are "remembered" (ie written to a table). So when I open the
1st
> form in the quotation cycle it offers me the last selections I made. All I
> have to do is click 'Proceed' buttons to step through the process (bit
like
> a very big and complex wizard), so reproducing the same path through the
> operation is easy. And sometimes it will crash on the first Proceed,
> sometimes the 4th, or the 5th, and so on. Sometimes it will get all the
way
> through but crash on a second pass. But behind those buttons there's
masses
> of data retrieval and calculation going on, and calls to zillions of
> functions. So, for example, pressing the 2nd Proceed will execute
literally
> hunders of lines of code. And it may crash somewhere in there. Or it may
> not, but crash after the next Proceed. And bear in mind that none of this
> crashes ever on any W98 machine (and did I mention that it doesn't crash
> either on my XP machine at home, just W2K and XP machines as configured at
> work?). So I'm not being difficult in holding off from tracking the point
in
> code where it crashes, it just looks like a lifetime's work to do so. And
of
> course I'd have to face up to that if I had a bug in there, but there
can't
> be a conventional bug if it's so inconsistent.
>
> Aaaaaargh.
>
> -- Andy Lacey
> http://www.minstersystems.co.uk
>
> Website: http://www.databaseadvisors.com