A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Setting Up & Running Reports
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Unhandled exceptions during report outputs to snapshot files



 
 
Thread Tools Display Modes
  #21  
Old August 4th, 2006, 09:50 PM posted to microsoft.public.access.reports
strive4peace
external usenet poster
 
Posts: 1,670
Default Unhandled exceptions during report outputs to snapshot files

Hi Peter,

you're welcome

Since Graph should close before you do another report, you may want to
loop until that has happened...

Find out if an application is currently running, by Dev Ashish
http://www.mvps.org/access/api/api0007.htm



Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Thanks very much for all your comments. Let me offer a brief
explanation of what the DelayApp was for.

When I run this report, I notice in TaskMgr that there are as many as 4
instances of GRAPH.EXE (one for each chart object in the report). As
the reports generate, you can see the GRAPH.EXE instances come and go.
Between file exports, sometimes one or more of the GRAPH.EXE instances
stays in the TaskMgr list, as if the reports were being generated so
quickly that the GRAPH.EXEs couldn't shut down before another report
was being generated.

I SPECULATED that maybe this was causing the problem, so I did the
DELAYAPP function to slow things down between reports and allow all the
instances of GRAPH.EXE to shutdown gracefully before the next report
got generated.

I will try your other suggestions. As you and Tom can see, this is a
vexing problem for me. I can't reproduce the error "on command", and I
don't have any witnesses, either (in spite of your efforts - thanks for
taking the interest).

I will keep you both posted.
strive4peace wrote:
Hi Peter,

another note about DoEvents... you may want to put a counter in your
loop to generate the reports and only execute DoEvents once every 50 or
so times... throwing that in every now and then may help -- I have seen
systems where that was necessary...


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

I looked at your code. I see you have a sub to DelayApp that does
DoEvents (prob only need to do this once instead of a bunch of times)
...and I also see you commented it out. You might try just one DoEvents
statement

another thing you might try is creating the filename as a variable in
LoopReport instead of constructing it in your Access.DoCmd.OutputTo
statement

ie:

dim mFilename as string

mFilename = "c:\AccessBug\A" & VBA.Format(i, "0000") & ".snp"

it might also be good to test if the file is there
DIR(mFilename)
and KILL it first -- if is does not disappear, then use another filename


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

Tom sent me your database and I tested it too -- ran fine in about 20
minutes with the points and number of graphs specified. Then I
increased the points to 100 and the number of graphs to 1000 -- took
about 3-1/2 hours, but it never failed

It is hard to suggest a solution for a problem that doesn't happen for
me, but I will look at the code and see if I see anything that you
might want to change...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Peter,

I have tested the sample database that you sent to me, using two
different PC's. In both cases, all 1000 snapshot files were created
without any problem. At this time, I am unable to reproduce the
failures that you are experiencing.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Tom Wickerath" wrote:

Hi Peter,

Are you going to be able to send any type of a cut down sample DB to
me, which replicates the problem on your PC?


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Peter B" wrote:

Update - I added some VBA code to my test database to export the
snapshots one file at a time. This is also part of my automated
process that is bombing on me. This also gets away from any TEMP
space
issues associates with huge snapshot exports.

I started the export process before I left work yesterday. If
successful, I would have 1000 snapshot files parked on my c: drive in
the morning. Well, got here this morning, and after only 34
exports, I
have the same Access unhandled exception on my screen. I shut down,
relaunched Access and tried to export again, and after 70 exports,
Access bombed out on me.

I am going to try to repeat this a few times, and if I can, I can then
make changes to see what fixes it.


  #22  
Old August 8th, 2006, 01:00 AM posted to microsoft.public.access.reports
strive4peace
external usenet poster
 
Posts: 1,670
Default Unhandled exceptions during report outputs to snapshot files

Hi Peter,

did you get it resolved? ... just checking in!

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

you're welcome

Since Graph should close before you do another report, you may want to
loop until that has happened...

Find out if an application is currently running, by Dev Ashish
http://www.mvps.org/access/api/api0007.htm



Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Thanks very much for all your comments. Let me offer a brief
explanation of what the DelayApp was for.

When I run this report, I notice in TaskMgr that there are as many as 4
instances of GRAPH.EXE (one for each chart object in the report). As
the reports generate, you can see the GRAPH.EXE instances come and go.
Between file exports, sometimes one or more of the GRAPH.EXE instances
stays in the TaskMgr list, as if the reports were being generated so
quickly that the GRAPH.EXEs couldn't shut down before another report
was being generated.

I SPECULATED that maybe this was causing the problem, so I did the
DELAYAPP function to slow things down between reports and allow all the
instances of GRAPH.EXE to shutdown gracefully before the next report
got generated.

I will try your other suggestions. As you and Tom can see, this is a
vexing problem for me. I can't reproduce the error "on command", and I
don't have any witnesses, either (in spite of your efforts - thanks for
taking the interest).

I will keep you both posted.
strive4peace wrote:
Hi Peter,

another note about DoEvents... you may want to put a counter in your
loop to generate the reports and only execute DoEvents once every 50 or
so times... throwing that in every now and then may help -- I have seen
systems where that was necessary...


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

I looked at your code. I see you have a sub to DelayApp that does
DoEvents (prob only need to do this once instead of a bunch of times)
...and I also see you commented it out. You might try just one
DoEvents
statement

another thing you might try is creating the filename as a variable in
LoopReport instead of constructing it in your Access.DoCmd.OutputTo
statement

ie:

dim mFilename as string

mFilename = "c:\AccessBug\A" & VBA.Format(i, "0000") & ".snp"

it might also be good to test if the file is there
DIR(mFilename)
and KILL it first -- if is does not disappear, then use another
filename


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

Tom sent me your database and I tested it too -- ran fine in about 20
minutes with the points and number of graphs specified. Then I
increased the points to 100 and the number of graphs to 1000 -- took
about 3-1/2 hours, but it never failed

It is hard to suggest a solution for a problem that doesn't happen for
me, but I will look at the code and see if I see anything that you
might want to change...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Peter,

I have tested the sample database that you sent to me, using two
different PC's. In both cases, all 1000 snapshot files were created
without any problem. At this time, I am unable to reproduce the
failures that you are experiencing.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Tom Wickerath" wrote:

Hi Peter,

Are you going to be able to send any type of a cut down sample DB to
me, which replicates the problem on your PC?


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Peter B" wrote:

Update - I added some VBA code to my test database to export the
snapshots one file at a time. This is also part of my automated
process that is bombing on me. This also gets away from any TEMP
space
issues associates with huge snapshot exports.

I started the export process before I left work yesterday. If
successful, I would have 1000 snapshot files parked on my c:
drive in
the morning. Well, got here this morning, and after only 34
exports, I
have the same Access unhandled exception on my screen. I shut
down,
relaunched Access and tried to export again, and after 70 exports,
Access bombed out on me.

I am going to try to repeat this a few times, and if I can, I
can then
make changes to see what fixes it.


  #23  
Old August 8th, 2006, 02:27 PM posted to microsoft.public.access.reports
Peter B
external usenet poster
 
Posts: 9
Default Unhandled exceptions during report outputs to snapshot files

Crystal,

No resolution yet, inspite of putting a 3 second delay loop between
reports. But, I could try your suggestion about waiting for all
instances of GRAPH to be gone. I haven't looked at what you sent me,
but I'm guessing it's a WMI approach (??). We'll see. I've programmed
that before in VB Script to query the process list to see if something
is running.

I'll give that a try.

strive4peace wrote:
Hi Peter,

did you get it resolved? ... just checking in!

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

you're welcome

Since Graph should close before you do another report, you may want to
loop until that has happened...

Find out if an application is currently running, by Dev Ashish
http://www.mvps.org/access/api/api0007.htm



Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Thanks very much for all your comments. Let me offer a brief
explanation of what the DelayApp was for.

When I run this report, I notice in TaskMgr that there are as many as 4
instances of GRAPH.EXE (one for each chart object in the report). As
the reports generate, you can see the GRAPH.EXE instances come and go.
Between file exports, sometimes one or more of the GRAPH.EXE instances
stays in the TaskMgr list, as if the reports were being generated so
quickly that the GRAPH.EXEs couldn't shut down before another report
was being generated.

I SPECULATED that maybe this was causing the problem, so I did the
DELAYAPP function to slow things down between reports and allow all the
instances of GRAPH.EXE to shutdown gracefully before the next report
got generated.

I will try your other suggestions. As you and Tom can see, this is a
vexing problem for me. I can't reproduce the error "on command", and I
don't have any witnesses, either (in spite of your efforts - thanks for
taking the interest).

I will keep you both posted.
strive4peace wrote:
Hi Peter,

another note about DoEvents... you may want to put a counter in your
loop to generate the reports and only execute DoEvents once every 50 or
so times... throwing that in every now and then may help -- I have seen
systems where that was necessary...


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

I looked at your code. I see you have a sub to DelayApp that does
DoEvents (prob only need to do this once instead of a bunch of times)
...and I also see you commented it out. You might try just one
DoEvents
statement

another thing you might try is creating the filename as a variable in
LoopReport instead of constructing it in your Access.DoCmd.OutputTo
statement

ie:

dim mFilename as string

mFilename = "c:\AccessBug\A" & VBA.Format(i, "0000") & ".snp"

it might also be good to test if the file is there
DIR(mFilename)
and KILL it first -- if is does not disappear, then use another
filename


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

Tom sent me your database and I tested it too -- ran fine in about 20
minutes with the points and number of graphs specified. Then I
increased the points to 100 and the number of graphs to 1000 -- took
about 3-1/2 hours, but it never failed

It is hard to suggest a solution for a problem that doesn't happen for
me, but I will look at the code and see if I see anything that you
might want to change...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Peter,

I have tested the sample database that you sent to me, using two
different PC's. In both cases, all 1000 snapshot files were created
without any problem. At this time, I am unable to reproduce the
failures that you are experiencing.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Tom Wickerath" wrote:

Hi Peter,

Are you going to be able to send any type of a cut down sample DB to
me, which replicates the problem on your PC?


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Peter B" wrote:

Update - I added some VBA code to my test database to export the
snapshots one file at a time. This is also part of my automated
process that is bombing on me. This also gets away from any TEMP
space
issues associates with huge snapshot exports.

I started the export process before I left work yesterday. If
successful, I would have 1000 snapshot files parked on my c:
drive in
the morning. Well, got here this morning, and after only 34
exports, I
have the same Access unhandled exception on my screen. I shut
down,
relaunched Access and tried to export again, and after 70 exports,
Access bombed out on me.

I am going to try to repeat this a few times, and if I can, I
can then
make changes to see what fixes it.


  #24  
Old August 8th, 2006, 04:10 PM posted to microsoft.public.access.reports
Peter B
external usenet poster
 
Posts: 9
Default Unhandled exceptions during report outputs to snapshot files

Crystal,

Just implemented the "make sure GRAPH.EXE instances are gone before
proceeding to next report" + a 3 second delay between report exports,
and I still got the bomb. Didn't take long to manifest (#!@*&^!).

This is worth mentioning. I have two other types of reports that I
generate as part of this process. One has no OLE objects embeded,
while the other does (charts). Neither of these reports give me any
trouble, and I export thousands of snapshots for this.

The report with the problem is composed of 4 sub-reports. I call it a
combo report. In the combo report, two of the sub-reports are the ones
I mention above, including the one with the embeded OLE chart. What's
strange is that the combo report (which will not work correctly) is
composed of other reports that, individually, work fine. The VBA code
that runs when I export the individual reports also runs as part of the
combo report.

I can control which reports get exported. When I EXCLUDE the combo
report, I don't have any problems. Any time the combo report is part
of the process, chances are high that I'll have this problem.

So, I just don't understand what the problem is, unless the combo
report is simply too complicated for Access. I have diligently been
sending the error reports to MS, and I just wish someone would pay
attention. But, I'm not holding out hope.

Sigh.

strive4peace wrote:
Hi Peter,

did you get it resolved? ... just checking in!

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

you're welcome

Since Graph should close before you do another report, you may want to
loop until that has happened...

Find out if an application is currently running, by Dev Ashish
http://www.mvps.org/access/api/api0007.htm



Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Thanks very much for all your comments. Let me offer a brief
explanation of what the DelayApp was for.

When I run this report, I notice in TaskMgr that there are as many as 4
instances of GRAPH.EXE (one for each chart object in the report). As
the reports generate, you can see the GRAPH.EXE instances come and go.
Between file exports, sometimes one or more of the GRAPH.EXE instances
stays in the TaskMgr list, as if the reports were being generated so
quickly that the GRAPH.EXEs couldn't shut down before another report
was being generated.

I SPECULATED that maybe this was causing the problem, so I did the
DELAYAPP function to slow things down between reports and allow all the
instances of GRAPH.EXE to shutdown gracefully before the next report
got generated.

I will try your other suggestions. As you and Tom can see, this is a
vexing problem for me. I can't reproduce the error "on command", and I
don't have any witnesses, either (in spite of your efforts - thanks for
taking the interest).

I will keep you both posted.
strive4peace wrote:
Hi Peter,

another note about DoEvents... you may want to put a counter in your
loop to generate the reports and only execute DoEvents once every 50 or
so times... throwing that in every now and then may help -- I have seen
systems where that was necessary...


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

I looked at your code. I see you have a sub to DelayApp that does
DoEvents (prob only need to do this once instead of a bunch of times)
...and I also see you commented it out. You might try just one
DoEvents
statement

another thing you might try is creating the filename as a variable in
LoopReport instead of constructing it in your Access.DoCmd.OutputTo
statement

ie:

dim mFilename as string

mFilename = "c:\AccessBug\A" & VBA.Format(i, "0000") & ".snp"

it might also be good to test if the file is there
DIR(mFilename)
and KILL it first -- if is does not disappear, then use another
filename


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

Tom sent me your database and I tested it too -- ran fine in about 20
minutes with the points and number of graphs specified. Then I
increased the points to 100 and the number of graphs to 1000 -- took
about 3-1/2 hours, but it never failed

It is hard to suggest a solution for a problem that doesn't happen for
me, but I will look at the code and see if I see anything that you
might want to change...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Peter,

I have tested the sample database that you sent to me, using two
different PC's. In both cases, all 1000 snapshot files were created
without any problem. At this time, I am unable to reproduce the
failures that you are experiencing.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Tom Wickerath" wrote:

Hi Peter,

Are you going to be able to send any type of a cut down sample DB to
me, which replicates the problem on your PC?


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Peter B" wrote:

Update - I added some VBA code to my test database to export the
snapshots one file at a time. This is also part of my automated
process that is bombing on me. This also gets away from any TEMP
space
issues associates with huge snapshot exports.

I started the export process before I left work yesterday. If
successful, I would have 1000 snapshot files parked on my c:
drive in
the morning. Well, got here this morning, and after only 34
exports, I
have the same Access unhandled exception on my screen. I shut
down,
relaunched Access and tried to export again, and after 70 exports,
Access bombed out on me.

I am going to try to repeat this a few times, and if I can, I
can then
make changes to see what fixes it.


  #25  
Old August 8th, 2006, 09:01 PM posted to microsoft.public.access.reports
strive4peace
external usenet poster
 
Posts: 1,670
Default Unhandled exceptions during report outputs to snapshot files

Hi Peter,

rather than just looping for a time, put the check to see if Graph is
still open in your loop -- and let that be your determining factor for
moving on...

Also, you do not want to just loop on DoEvents... too many DoEvents is
not such a good thing ... check to see if Graph is done, do a complex
calculation -- or just count to some number whose variable you set --
check Graph, etc

"I haven't looked at what you sent me, but I'm guessing it's a WMI
approach (??)."

here is some info on API:

http://en.wikipedia.org/wiki/API

and a little bit from the top:

"An application programming interface (API) is the interface that a
computer system, library or application provides in order to allow
requests for services to be made of it by other computer programs,
and/or to allow data to be exchanged between them." ... and so on...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

No resolution yet, inspite of putting a 3 second delay loop between
reports. But, I could try your suggestion about waiting for all
instances of GRAPH to be gone. I haven't looked at what you sent me,
but I'm guessing it's a WMI approach (??). We'll see. I've programmed
that before in VB Script to query the process list to see if something
is running.

I'll give that a try.

strive4peace wrote:
Hi Peter,

did you get it resolved? ... just checking in!

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

you're welcome

Since Graph should close before you do another report, you may want to
loop until that has happened...

Find out if an application is currently running, by Dev Ashish
http://www.mvps.org/access/api/api0007.htm



Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Thanks very much for all your comments. Let me offer a brief
explanation of what the DelayApp was for.

When I run this report, I notice in TaskMgr that there are as many as 4
instances of GRAPH.EXE (one for each chart object in the report). As
the reports generate, you can see the GRAPH.EXE instances come and go.
Between file exports, sometimes one or more of the GRAPH.EXE instances
stays in the TaskMgr list, as if the reports were being generated so
quickly that the GRAPH.EXEs couldn't shut down before another report
was being generated.

I SPECULATED that maybe this was causing the problem, so I did the
DELAYAPP function to slow things down between reports and allow all the
instances of GRAPH.EXE to shutdown gracefully before the next report
got generated.

I will try your other suggestions. As you and Tom can see, this is a
vexing problem for me. I can't reproduce the error "on command", and I
don't have any witnesses, either (in spite of your efforts - thanks for
taking the interest).

I will keep you both posted.
strive4peace wrote:
Hi Peter,

another note about DoEvents... you may want to put a counter in your
loop to generate the reports and only execute DoEvents once every 50 or
so times... throwing that in every now and then may help -- I have seen
systems where that was necessary...


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

I looked at your code. I see you have a sub to DelayApp that does
DoEvents (prob only need to do this once instead of a bunch of times)
...and I also see you commented it out. You might try just one
DoEvents
statement

another thing you might try is creating the filename as a variable in
LoopReport instead of constructing it in your Access.DoCmd.OutputTo
statement

ie:

dim mFilename as string

mFilename = "c:\AccessBug\A" & VBA.Format(i, "0000") & ".snp"

it might also be good to test if the file is there
DIR(mFilename)
and KILL it first -- if is does not disappear, then use another
filename


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

Tom sent me your database and I tested it too -- ran fine in about 20
minutes with the points and number of graphs specified. Then I
increased the points to 100 and the number of graphs to 1000 -- took
about 3-1/2 hours, but it never failed

It is hard to suggest a solution for a problem that doesn't happen for
me, but I will look at the code and see if I see anything that you
might want to change...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Peter,

I have tested the sample database that you sent to me, using two
different PC's. In both cases, all 1000 snapshot files were created
without any problem. At this time, I am unable to reproduce the
failures that you are experiencing.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Tom Wickerath" wrote:

Hi Peter,

Are you going to be able to send any type of a cut down sample DB to
me, which replicates the problem on your PC?


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Peter B" wrote:

Update - I added some VBA code to my test database to export the
snapshots one file at a time. This is also part of my automated
process that is bombing on me. This also gets away from any TEMP
space
issues associates with huge snapshot exports.

I started the export process before I left work yesterday. If
successful, I would have 1000 snapshot files parked on my c:
drive in
the morning. Well, got here this morning, and after only 34
exports, I
have the same Access unhandled exception on my screen. I shut
down,
relaunched Access and tried to export again, and after 70 exports,
Access bombed out on me.

I am going to try to repeat this a few times, and if I can, I
can then
make changes to see what fixes it.


  #26  
Old August 8th, 2006, 09:54 PM posted to microsoft.public.access.reports
strive4peace
external usenet poster
 
Posts: 1,670
Default Unhandled exceptions during report outputs to snapshot files

Hi Peter,

how much memory do you have?

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Just implemented the "make sure GRAPH.EXE instances are gone before
proceeding to next report" + a 3 second delay between report exports,
and I still got the bomb. Didn't take long to manifest (#!@*&^!).

This is worth mentioning. I have two other types of reports that I
generate as part of this process. One has no OLE objects embeded,
while the other does (charts). Neither of these reports give me any
trouble, and I export thousands of snapshots for this.

The report with the problem is composed of 4 sub-reports. I call it a
combo report. In the combo report, two of the sub-reports are the ones
I mention above, including the one with the embeded OLE chart. What's
strange is that the combo report (which will not work correctly) is
composed of other reports that, individually, work fine. The VBA code
that runs when I export the individual reports also runs as part of the
combo report.

I can control which reports get exported. When I EXCLUDE the combo
report, I don't have any problems. Any time the combo report is part
of the process, chances are high that I'll have this problem.

So, I just don't understand what the problem is, unless the combo
report is simply too complicated for Access. I have diligently been
sending the error reports to MS, and I just wish someone would pay
attention. But, I'm not holding out hope.

Sigh.

strive4peace wrote:
Hi Peter,

did you get it resolved? ... just checking in!

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

you're welcome

Since Graph should close before you do another report, you may want to
loop until that has happened...

Find out if an application is currently running, by Dev Ashish
http://www.mvps.org/access/api/api0007.htm



Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Thanks very much for all your comments. Let me offer a brief
explanation of what the DelayApp was for.

When I run this report, I notice in TaskMgr that there are as many as 4
instances of GRAPH.EXE (one for each chart object in the report). As
the reports generate, you can see the GRAPH.EXE instances come and go.
Between file exports, sometimes one or more of the GRAPH.EXE instances
stays in the TaskMgr list, as if the reports were being generated so
quickly that the GRAPH.EXEs couldn't shut down before another report
was being generated.

I SPECULATED that maybe this was causing the problem, so I did the
DELAYAPP function to slow things down between reports and allow all the
instances of GRAPH.EXE to shutdown gracefully before the next report
got generated.

I will try your other suggestions. As you and Tom can see, this is a
vexing problem for me. I can't reproduce the error "on command", and I
don't have any witnesses, either (in spite of your efforts - thanks for
taking the interest).

I will keep you both posted.
strive4peace wrote:
Hi Peter,

another note about DoEvents... you may want to put a counter in your
loop to generate the reports and only execute DoEvents once every 50 or
so times... throwing that in every now and then may help -- I have seen
systems where that was necessary...


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

I looked at your code. I see you have a sub to DelayApp that does
DoEvents (prob only need to do this once instead of a bunch of times)
...and I also see you commented it out. You might try just one
DoEvents
statement

another thing you might try is creating the filename as a variable in
LoopReport instead of constructing it in your Access.DoCmd.OutputTo
statement

ie:

dim mFilename as string

mFilename = "c:\AccessBug\A" & VBA.Format(i, "0000") & ".snp"

it might also be good to test if the file is there
DIR(mFilename)
and KILL it first -- if is does not disappear, then use another
filename


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

Tom sent me your database and I tested it too -- ran fine in about 20
minutes with the points and number of graphs specified. Then I
increased the points to 100 and the number of graphs to 1000 -- took
about 3-1/2 hours, but it never failed

It is hard to suggest a solution for a problem that doesn't happen for
me, but I will look at the code and see if I see anything that you
might want to change...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Peter,

I have tested the sample database that you sent to me, using two
different PC's. In both cases, all 1000 snapshot files were created
without any problem. At this time, I am unable to reproduce the
failures that you are experiencing.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Tom Wickerath" wrote:

Hi Peter,

Are you going to be able to send any type of a cut down sample DB to
me, which replicates the problem on your PC?


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Peter B" wrote:

Update - I added some VBA code to my test database to export the
snapshots one file at a time. This is also part of my automated
process that is bombing on me. This also gets away from any TEMP
space
issues associates with huge snapshot exports.

I started the export process before I left work yesterday. If
successful, I would have 1000 snapshot files parked on my c:
drive in
the morning. Well, got here this morning, and after only 34
exports, I
have the same Access unhandled exception on my screen. I shut
down,
relaunched Access and tried to export again, and after 70 exports,
Access bombed out on me.

I am going to try to repeat this a few times, and if I can, I
can then
make changes to see what fixes it.


  #27  
Old August 9th, 2006, 10:23 AM posted to microsoft.public.access.reports
strive4peace
external usenet poster
 
Posts: 1,670
Default Unhandled exceptions during report outputs to snapshot files

Hi Peter,

added note:

My machine has 1.5 GB DDR memory, 2.8GHz Intel processor, running Access
2003 under XP Pro SP-2 but Tom ran it on older machines...

Tom said, "I've been thinking that what he might need is an older PC to
run his mega-snapshot generation code on. After all, I've tested it on
two PC's without any failure. My PC is 5 years old, and my step-dad's is
4 years old. So, they are not the speed demons they once were,
especially since they're running fairly new software (Windows XP Pro.
SP-2 / Office 2003 with SP-2) that has a lot more lines of code in it
than Windows 2000 / Office 2000 likely had 5 years ago (more lines of
code --- slower running, especially for older machines [aka bloat code])."

If you have plenty of RAM, another question I have is this: have you run
spyware checkers such as Ad-Aware, Spybot, etc lately? What else is
running that may be taking your resources?

What version of Access are you using?

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

how much memory do you have?

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Just implemented the "make sure GRAPH.EXE instances are gone before
proceeding to next report" + a 3 second delay between report exports,
and I still got the bomb. Didn't take long to manifest (#!@*&^!).

This is worth mentioning. I have two other types of reports that I
generate as part of this process. One has no OLE objects embeded,
while the other does (charts). Neither of these reports give me any
trouble, and I export thousands of snapshots for this.

The report with the problem is composed of 4 sub-reports. I call it a
combo report. In the combo report, two of the sub-reports are the ones
I mention above, including the one with the embeded OLE chart. What's
strange is that the combo report (which will not work correctly) is
composed of other reports that, individually, work fine. The VBA code
that runs when I export the individual reports also runs as part of the
combo report.

I can control which reports get exported. When I EXCLUDE the combo
report, I don't have any problems. Any time the combo report is part
of the process, chances are high that I'll have this problem.

So, I just don't understand what the problem is, unless the combo
report is simply too complicated for Access. I have diligently been
sending the error reports to MS, and I just wish someone would pay
attention. But, I'm not holding out hope.

Sigh.

strive4peace wrote:
Hi Peter,

did you get it resolved? ... just checking in!

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

you're welcome

Since Graph should close before you do another report, you may want to
loop until that has happened...

Find out if an application is currently running, by Dev Ashish
http://www.mvps.org/access/api/api0007.htm



Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Peter B wrote:
Crystal,

Thanks very much for all your comments. Let me offer a brief
explanation of what the DelayApp was for.

When I run this report, I notice in TaskMgr that there are as many
as 4
instances of GRAPH.EXE (one for each chart object in the report). As
the reports generate, you can see the GRAPH.EXE instances come and go.
Between file exports, sometimes one or more of the GRAPH.EXE instances
stays in the TaskMgr list, as if the reports were being generated so
quickly that the GRAPH.EXEs couldn't shut down before another report
was being generated.

I SPECULATED that maybe this was causing the problem, so I did the
DELAYAPP function to slow things down between reports and allow all
the
instances of GRAPH.EXE to shutdown gracefully before the next report
got generated.

I will try your other suggestions. As you and Tom can see, this is a
vexing problem for me. I can't reproduce the error "on command",
and I
don't have any witnesses, either (in spite of your efforts - thanks
for
taking the interest).

I will keep you both posted.
strive4peace wrote:
Hi Peter,

another note about DoEvents... you may want to put a counter in your
loop to generate the reports and only execute DoEvents once every
50 or
so times... throwing that in every now and then may help -- I have
seen
systems where that was necessary...


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

I looked at your code. I see you have a sub to DelayApp that does
DoEvents (prob only need to do this once instead of a bunch of
times)
...and I also see you commented it out. You might try just one
DoEvents
statement

another thing you might try is creating the filename as a
variable in
LoopReport instead of constructing it in your Access.DoCmd.OutputTo
statement

ie:

dim mFilename as string

mFilename = "c:\AccessBug\A" & VBA.Format(i, "0000") & ".snp"

it might also be good to test if the file is there
DIR(mFilename)
and KILL it first -- if is does not disappear, then use another
filename


Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



strive4peace wrote:
Hi Peter,

Tom sent me your database and I tested it too -- ran fine in
about 20
minutes with the points and number of graphs specified. Then I
increased the points to 100 and the number of graphs to 1000 --
took
about 3-1/2 hours, but it never failed

It is hard to suggest a solution for a problem that doesn't
happen for
me, but I will look at the code and see if I see anything that you
might want to change...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Peter,

I have tested the sample database that you sent to me, using two
different PC's. In both cases, all 1000 snapshot files were
created
without any problem. At this time, I am unable to reproduce the
failures that you are experiencing.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Tom Wickerath" wrote:

Hi Peter,

Are you going to be able to send any type of a cut down sample
DB to
me, which replicates the problem on your PC?


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Peter B" wrote:

Update - I added some VBA code to my test database to export the
snapshots one file at a time. This is also part of my automated
process that is bombing on me. This also gets away from any
TEMP
space
issues associates with huge snapshot exports.

I started the export process before I left work yesterday. If
successful, I would have 1000 snapshot files parked on my c:
drive in
the morning. Well, got here this morning, and after only 34
exports, I
have the same Access unhandled exception on my screen. I shut
down,
relaunched Access and tried to export again, and after 70
exports,
Access bombed out on me.

I am going to try to repeat this a few times, and if I can, I
can then
make changes to see what fixes it.


  #28  
Old August 9th, 2006, 06:46 PM posted to microsoft.public.access.reports
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default Unhandled exceptions during report outputs to snapshot files

Hi Crystal & Peter,

My 5-year-old PC, which uses the Windows 2000 Server operating system with
Access 2003, SP-2, has a measly (by today's standards) 512 MB of RAM. The
processor is a AMD K7 1.2ghz. I think (although I'm not positive) that my
stepdad's PC also has 512 MB of RAM. His processor speed is a bit faster,
since his PC is one year newer than mine.

Now you know why I haven't attempted to load Vista / A2007 beta, smile
since my system isn't "good enough" to support Virtual PC (and I refuse to
load beta software on a system that is working perfectly well right now,
thank you).


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"strive4peace" wrote:

Hi Peter,

added note:

My machine has 1.5 GB DDR memory, 2.8GHz Intel processor, running Access
2003 under XP Pro SP-2 but Tom ran it on older machines...

Tom said, "I've been thinking that what he might need is an older PC to
run his mega-snapshot generation code on. After all, I've tested it on
two PC's without any failure. My PC is 5 years old, and my step-dad's is
4 years old. So, they are not the speed demons they once were,
especially since they're running fairly new software (Windows XP Pro.
SP-2 / Office 2003 with SP-2) that has a lot more lines of code in it
than Windows 2000 / Office 2000 likely had 5 years ago (more lines of
code --- slower running, especially for older machines [aka bloat code])."

If you have plenty of RAM, another question I have is this: have you run
spyware checkers such as Ad-Aware, Spybot, etc lately? What else is
running that may be taking your resources?

What version of Access are you using?

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com


  #29  
Old August 9th, 2006, 07:43 PM posted to microsoft.public.access.reports
strive4peace
external usenet poster
 
Posts: 1,670
Default Unhandled exceptions during report outputs to snapshot files

Hi Tom,

here is what I did to load the beta (it is running under XP SP-2) and it
seems to be working very well

1. get another drive (and more memory too if you can since that is the
cheapest thing you can do to increase performance)

2. unhook the cables on your current drive and hook up the new drive

3. install Windows and then the beta on the other drive

4. then, hook your first drive back in -- use it for your work

5. when you want to use the Beta version, go into the BIOS menu (ie:
press DELETE when your computer boots) and change the boot drive. Change
it back again to do your work.

My son loaded Vista yesterday on another drive in his computer (and we
do the BIOS drive switching thing for that too) ... from what he has
said, I think I will stick with XP for awhile -- among other things, it
seems to be menu-cumbersome. On a positive note, it was very easy to
connect to the Internet...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com
*



Tom Wickerath wrote:
Hi Crystal & Peter,

My 5-year-old PC, which uses the Windows 2000 Server operating system with
Access 2003, SP-2, has a measly (by today's standards) 512 MB of RAM. The
processor is a AMD K7 1.2ghz. I think (although I'm not positive) that my
stepdad's PC also has 512 MB of RAM. His processor speed is a bit faster,
since his PC is one year newer than mine.

Now you know why I haven't attempted to load Vista / A2007 beta, smile
since my system isn't "good enough" to support Virtual PC (and I refuse to
load beta software on a system that is working perfectly well right now,
thank you).


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"strive4peace" wrote:

Hi Peter,

added note:

My machine has 1.5 GB DDR memory, 2.8GHz Intel processor, running Access
2003 under XP Pro SP-2 but Tom ran it on older machines...

Tom said, "I've been thinking that what he might need is an older PC to
run his mega-snapshot generation code on. After all, I've tested it on
two PC's without any failure. My PC is 5 years old, and my step-dad's is
4 years old. So, they are not the speed demons they once were,
especially since they're running fairly new software (Windows XP Pro.
SP-2 / Office 2003 with SP-2) that has a lot more lines of code in it
than Windows 2000 / Office 2000 likely had 5 years ago (more lines of
code --- slower running, especially for older machines [aka bloat code])."

If you have plenty of RAM, another question I have is this: have you run
spyware checkers such as Ad-Aware, Spybot, etc lately? What else is
running that may be taking your resources?

What version of Access are you using?

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com


  #30  
Old August 9th, 2006, 08:04 PM posted to microsoft.public.access.reports
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default Unhandled exceptions during report outputs to snapshot files

Hi Crystal,

Step 5 should not be necessary. You can configure what is commonly known as
a "dual boot" or "multiple boot" configuration. In Windows 2000, see the help
topic titled "Installing more than one operating system on your computer".
I'm not sure if it is listed under the same topic in WindowsXP, since I'm not
using WindowsXP on my main PC (I do have it on my laptop PC, but that's
currently in the Baltimore area with Cindy).


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/ex...tributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"strive4peace" wrote:

Hi Tom,

here is what I did to load the beta (it is running under XP SP-2) and it
seems to be working very well

1. get another drive (and more memory too if you can since that is the
cheapest thing you can do to increase performance)

2. unhook the cables on your current drive and hook up the new drive

3. install Windows and then the beta on the other drive

4. then, hook your first drive back in -- use it for your work

5. when you want to use the Beta version, go into the BIOS menu (ie:
press DELETE when your computer boots) and change the boot drive. Change
it back again to do your work.

My son loaded Vista yesterday on another drive in his computer (and we
do the BIOS drive switching thing for that too) ... from what he has
said, I think I will stick with XP for awhile -- among other things, it
seems to be menu-cumbersome. On a positive note, it was very easy to
connect to the Internet...

Warm Regards,
Crystal
*
(: have an awesome day
*
MVP Access
Remote programming and Training
strive4peace2006 at yahoo.com


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 03:32 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.