Access has encountered a problem...

From time to time I strike a problem where Access will suddenly shut down
while running some code (Dr Watson message), wiping out any forensics
(diagnostic traces such as debug.prints, etc). This is frustrating enough,
but if I step through the same code one instruction at a time, it always
functions perfectly. I have usually resolved the issue by time-consuming
trial and error, making pseudo-random code changes until I end up with
something that functions more or less as I want, but without crashing
Access.

The fact that it works when stepping through, or even by inserting a single
breakpoint, suggests that there is some sort of timing conflict, probably
with asynchronous activity taking place. I have tried inserting lengthy
delay loops at various points (to simulate the breakpoint), but this
strategy is usually unsuccessful in affecting the operation of the code
(other than to slow it down).

I am currently trying to resolve another instance of this problem, so far
without success. I will detail the current problem in a separate post, but
my question here is: is there some logical strategy for troubleshooting
this type of problem other than trial and error? How can I pinpoint the
problem code when Access crashes and leaves no trace, but works perfectly
when stepping through?

Thanks for any insight,
Lyn.

Re: Access has encountered a problem...

Lyn wrote:

>From time to time I strike a problem where Access will suddenly shut down
>while running some code (Dr Watson message), wiping out any forensics
>(diagnostic traces such as debug.prints, etc).

Try logging things such as debug.print using a call to the following procedure.
Change the file name to suit your environment of course.

Sub LogToTextFile(Comment As String)

Open "Q:\1 access\Fleet Mgmt\zzz Service log.txt" For Append As #1 ' Open file
for output.
Write #1, Comment
Close #1

End Sub

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Access has encountered a problem...

On Sun, 21 Oct 2007 22:16:07 GMT, Tony Toews [MVP] wrote:

> Lyn wrote:
>
>>From time to time I strike a problem where Access will suddenly shut down
>>while running some code (Dr Watson message), wiping out any forensics
>>(diagnostic traces such as debug.prints, etc).
>
> Try logging things such as debug.print using a call to the following procedure.
> Change the file name to suit your environment of course.
>
> Sub LogToTextFile(Comment As String)
>
> Open "Q:\1 access\Fleet Mgmt\zzz Service log.txt" For Append As #1 ' Open file
> for output.
> Write #1, Comment
> Close #1
>
> End Sub
>
> Tony

Tony,
Thanks for the great suggestion. I don't know why I didn't think of this
myself! In any case, I have adapted it and it has led to finding a
workaround solution which I think I can live with (the cause the crashes is
still a mystery).

Cheers,
Lyn.

Re: Access has encountered a problem...

Lyn wrote:

>Thanks for the great suggestion.

You're quite welcome.

>In any case, I have adapted it and it has led to finding a
>workaround solution which I think I can live with (the cause the crashes is
>still a mystery).

BTW please send the crash reports to Microsoft. Fixing those problems are a very
high priority within the development team.

And what was your problem? So we'll know for others?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Access has encountered a problem...

On Wed, 24 Oct 2007 02:26:32 GMT, Tony Toews [MVP] wrote:

> And what was your problem? So we'll know for others?

I posted details of the problem separately some five minutes after the
original post in this thread. It was titled "Form-filtering problem". If
you can't find it, let me know.

Using your suggestion, I discovered that there were three related cases
which caused the problem:

1) Restoring the full recordset display by turning off the .FilterOn
property; or

2) Setting the .Filter property to the ZLS; or

3) Using the DoCmd.ShowAllRecords method.

All of these should disable filtering and redisplay the full recordset. I
found that there was no problem if I changed the .Filter string to show
more or fewer records (directly or via the DoCmd.ApplyFilter method). It
only occurred when I removed all filtering via any of the above methods.

The workaround I ended up with was when I want to remove all filtering,
simply to requery the recordset -- it means going back to the database, but
with the size of my DB so far, any performance hit is unnoticeable (and the
environment is single user).

I would still like to find out (at least) whether removing an applied
filter to redisplay the original recordset is somehow bad practice (if not
illegal), or whether I am doing it in the wrong way (I have tried many
variations, all with the same result). The existence of the
..ShowAllRecords method suggests that it should work.

If you have any good ideas about this, please share!!

Cheers,
Lyn.

Re: Access has encountered a problem...

Greetings,

I couldn't find your "Form Filtering Problem" post, so I have a question
or 2 and some suggestions:

It sounds like you have a backend DB for the data storage. Is this
another Access mdb or a Sql server (Oracle) db?

If your backend is a server based db, you can simulate how you would
handle this with ADO.Net and pull your desired data into a temp table in
the local mdb (ADO.Net uses disconnected recordsets which is the same
thing as writing data to a table in the local mdb app from the backend
DB except that ADO.Net does this all in memory where the mdb writes
everything to the disk - which explains the substantial increase in
performance from ADO.Net over the mdb). Anyway, once you have the
desired dataset in the local app you can filter it very easily without
undesireable side effects.

If the backend is another mdb and you are having the problems you
describe, then try the same thing of pulling the desired data to the
local mdb as above.

Also, if your backend is another mdb, and it is approaching 500megs in
size and you are having these problems -- it is time to step up to sql
server (note: 500 megs is 0.0005% of the capacity of 1 sql server DB but
nearly 100% of the functional capacity of an mdb).

Rich

*** Sent via Developersdex http://www.developersdex.com ***

Re: Access has encountered a problem...

Lyn wrote:

>I would still like to find out (at least) whether removing an applied
>filter to redisplay the original recordset is somehow bad practice (if not
>illegal), or whether I am doing it in the wrong way (I have tried many
>variations, all with the same result).

I generally clear the filter (or set it to a zero length string) and setfilter = off.
That's worked for me for years.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Access has encountered a problem...

On Sat, 27 Oct 2007 01:54:26 GMT, Tony Toews [MVP] wrote:

> Lyn wrote:
>
>>I would still like to find out (at least) whether removing an applied
>>filter to redisplay the original recordset is somehow bad practice (if not
>>illegal), or whether I am doing it in the wrong way (I have tried many
>>variations, all with the same result).
>
> I generally clear the filter (or set it to a zero length string) and setfilter = off.
> That's worked for me for years.
>
> Tony

Yes, that was one of the first things I tried. There must be something
else that is odd about this form :-(

Lyn.