Report Status Window
in [Help]
|
Prev: "This file might not be safe if it contains code..." message with runtime version.
Next: Hyperion Financial management (HFM), Jersey City, NJ
From: Arvin Meyer on 8 Aug 2010 13:53 "Phil" <phil(a)stantonfamily.co.uk> wrote in message news:QaSdnflS967b9MPRnZ2dnUVZ7sGdnZ2d(a)brightview.co.uk... > I also have slow reports with a lot of VBA running behind the queries. The > user wants to be sure something is happenining and the application has not > crashed or gone ito an endless loop. Hourglass will certainly not show a > problem with and ensless loop, but what about a crash? Is there a better > way > of showing the program is running than SysCmd(acSysCmdSetStatus and say > someone's name? If you open a small, "Please wait" form just before you open the report, then close the form in the report's open event. You may be able to get what you're looking for. You may have to adjust the time slightly of the report takes time to format. For that you can use Delay code: http://www.datastrat.com/Code/Delay.txt -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.accessmvp.com http://www.mvps.org/access Co-author: "Access Solutions", published by Wiley
From: Salad on 8 Aug 2010 14:12 Phil wrote: > On 07/08/2010 22:12:43, "David W. Fenton" wrote: > >>Salad <salad(a)oilandvinegar.com> wrote in >>news:hv-dnRk84Ii61sHRnZ2dnUVZ_qqdnZ2d(a)earthlink.com: >> >> >>> From Alberts' reply and from the OP's response it appears the OP >>> wanted >>>a message to display while the report ran. Similar to a "wait >>>window" in FoxPro. For most of us reports appear almost >>>instantly. I'm going to assume the report the OP was discussing >>>is sluggish and needs an substantial amount of time to process. >> >>And? I have plenty of reports like that. I was just troubleshooting >>one last week that takes about 2 minutes for the first page to come >>up and 15 minutes to preview the last page. The hourglass is fine, >>seems to me, so I'm not sure what is gained with a PLEASE WAIT >>notification -- that's precisely what the hourglass means across all >>Windows apps, i.e., "I'm busy now, but working on it." >> > > > I also have slow reports with a lot of VBA running behind the queries. The > user wants to be sure something is happenining and the application has not > crashed or gone ito an endless loop. Hourglass will certainly not show a > problem with and ensless loop, but what about a crash? Is there a better way > of showing the program is running than SysCmd(acSysCmdSetStatus and say > someone's name? > > Phil I was at a site once way back when. There was report took about 4 hours to run. It wasn't written in Access but FoxPro. It didn't use SQL for the recordsource and it lacked proper indexes. I implemented the SQL source and added the indexes and it dropped down to seconds. I was at a site that used A97 years later and they also had a report that took well over an hour. I got it down to seconds. Granted, I wasn't printing graphics, just text, but wow!...if I had a report that took a couple of minutes to display a page I'd have to take a look at that code and refine it, see what's causing the bottleneck.
From: David W. Fenton on 8 Aug 2010 16:19 Salad <salad(a)oilandvinegar.com> wrote in news:7d2dna-Jwqk1bsPRnZ2dnUVZ_gidnZ2d(a)earthlink.com: > Granted, I wasn't printing graphics, just text, but wow!...if I > had a report that took a couple of minutes to display a page I'd > have to take a look at that code and refine it, see what's causing > the bottleneck. In the case of the report I mentioned, I know exactly what causes the bottleneck -- it's that I'm denormalizing a list of categories for display, i.e., taking the N:N categories for each item and using a function to concatenate them into a comma-separated list for each item displayed. If I remove that from the printout, it pops up almost immediately. Also, it's important to note that the first page pops up after a couple of minutes, and you can start sending to the printer then (it doesn't reformat from scratch). The long wait was if you click the last page control, so I just trained the user (there's only one for this particular report) to not preview the last page. -- David W. Fenton http://www.dfenton.com/ contact via website only http://www.dfenton.com/DFA/
From: David W. Fenton on 8 Aug 2010 16:23 "Phil" <phil(a)stantonfamily.co.uk> wrote in news:QaSdnflS967b9MPRnZ2dnUVZ7sGdnZ2d(a)brightview.co.uk: > On 07/08/2010 22:12:43, "David W. Fenton" wrote: >> Salad <salad(a)oilandvinegar.com> wrote in >> news:hv-dnRk84Ii61sHRnZ2dnUVZ_qqdnZ2d(a)earthlink.com: >> >>> From Alberts' reply and from the OP's response it appears the >>> OP wanted >>> a message to display while the report ran. Similar to a "wait >>> window" in FoxPro. For most of us reports appear almost >>> instantly. I'm going to assume the report the OP was discussing >>> is sluggish and needs an substantial amount of time to process. >> >> And? I have plenty of reports like that. I was just >> troubleshooting one last week that takes about 2 minutes for the >> first page to come up and 15 minutes to preview the last page. >> The hourglass is fine, seems to me, so I'm not sure what is >> gained with a PLEASE WAIT notification -- that's precisely what >> the hourglass means across all Windows apps, i.e., "I'm busy now, >> but working on it." >> > > I also have slow reports with a lot of VBA running behind the > queries. The user wants to be sure something is happenining and > the application has not crashed or gone ito an endless loop. > Hourglass will certainly not show a problem with and ensless loop, > but what about a crash? Is there a better way of showing the > program is running than SysCmd(acSysCmdSetStatus and say someone's > name? I don't see how popping up a static form is any different than relying on the hourglass. It's one of those things that isn't going to change during the process, so it really doesn't indicate to the user if the app has locked up or not. I'd be reluctant to start shoving code to update the UI into the underlying code that drives the functions, as you're then slowing the report down even more, and there's no real way to choose anything sensible for those functions to be displaying. Another option would be to animate the popup form with a timer, but I'm not sure that's going to be any more useful, since it's possible for parts of Access to lock up while leaving the other parts running (though I'm not certain on that -- I'm just thinking in terms of how things run asynchronously). -- David W. Fenton http://www.dfenton.com/ contact via website only http://www.dfenton.com/DFA/
From: Salad on 8 Aug 2010 20:02
David W. Fenton wrote: > Salad <salad(a)oilandvinegar.com> wrote in > news:7d2dna-Jwqk1bsPRnZ2dnUVZ_gidnZ2d(a)earthlink.com: > > >>Granted, I wasn't printing graphics, just text, but wow!...if I >>had a report that took a couple of minutes to display a page I'd >>have to take a look at that code and refine it, see what's causing >>the bottleneck. > > > In the case of the report I mentioned, I know exactly what causes > the bottleneck -- it's that I'm denormalizing a list of categories > for display, i.e., taking the N:N categories for each item and using > a function to concatenate them into a comma-separated list for each > item displayed. If I remove that from the printout, it pops up > almost immediately. > > Also, it's important to note that the first page pops up after a > couple of minutes, and you can start sending to the printer then (it > doesn't reformat from scratch). The long wait was if you click the > last page control, so I just trained the user (there's only one for > this particular report) to not preview the last page. > David, I know you've been around the block more than once. I still might want to see "what can I do" to improve. Let's say you have a form. You select a few categores out of many, maybe filter on customer or employee or whatever. Maybe run a process prior to calling the report to "create filter" or whatever and update the table then. Then have a separate button to run the report. Or add a memo field to store the categories in when updating data entry input. In my mind, the more instaneous the data to the user the better, normalization be damned. . If it's like a monthly report, eh, who cares. But if it is run by one or more people on a daily basis...big difference, IMO. I don't know your situation. In my case where this report that I fixed to take seconds instead of 4 hours in FoxPro...that was 20 hours of wasted time per week, 1000 hours per year that I corrected. If I had to break a rule to save user time I'd do it in a heartbeat. In my case I didn't have to, I simply used the tools I had at hand. The other one in Access that took an hour+, the prior developer was slick with the subselects and didn't have enough, IMO, indexes. I modified so the subselects became their own queries and left joined on them and added some relevent indexes and the report flew. |