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. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|