Updating a Table after Printing (Access 97/SR2)

Topic

New Reply

I’m looking for alternative suggestions for recording data and updating data after a report has printed as I am not 100% satisfied with my method. I have a table which contains client id’s and a type field which can either be ‘O’ or ‘P’. When the type is changed from ‘O’ to ‘P’ the record will appear on a label report. It is required to record that a record has been printed and when. My method includes running an update query which records the date the report was printed. The update query also changes a yes/no field from no to yes to show that the record has been printed. That’s probably redundant but that’s the way they want it. Originally the report was printed directly to the printer without previewing. I created a small procedure called from a switchboard button that prints the report and then runs the update query. Now they want to preview the report before printing – a reasonable request – but it introduces a variable into the process and that is the possibility of closing the report preview without running the report. I looked for a unique event that occurred either during the report printing or after the report was printed. The best I could do was the report page event. But this event occurs also when the report is previewed. So, I created a global variable which I increment by one each time the event occurs. Then in the close event of the report I check the value of the global variable and if it is greater than one I run the update query. I’ve tested it and it works but I’m not entirely comfortable with it. I would interested in hearing any alternative suggestions or comments. TIA.

Reply | Quote

Replies

There is, unfortunately, no way to do this. The only thing I can suggest is that you define a custom toolbar and menubar for the report, so that a Print option is not provided if they Preview it. This way, users will be forced to select your normal print routine to get it printed.

Reply | Quote

Actually, you could put a print button on a custom toolbar that only displays when you preview the report. That’s what I generally do, since I don’t allow the built-in toolbars and menus to be available. That could be used to call a routine to log the print job after the command to print the report.

It still isn’t perfect, especially on a network where the report may be spooled to a printer but never actually get printed.

Reply | Quote

Good idea. However, you still need to keep user from selecting the File | Print option.

Reply | Quote

He can’t select it if the menu isn’t available. I use only custom menubars in my apps, and the reports have their own menubar that includes a Print button. It only appears when the report is open, which means, in effect, open in preview. Otherwise, they’re working with a menu that doesn’t include the print option. In fact, the main menu I display has nothing on it but an Exit button unless I use menus instead of a switchboard.

Reply | Quote