Counter that counts the number of printed copies of report (1 Viewer)

azhar2006

Registered User.
Local time
Today, 05:43
Joined
Feb 8, 2012
Messages
180
good evening, everybody .
I have a question, can we make a counter that counts the number of printed copies of a particular report daily, writes the number of copies in a table, and on the next day calculates the number of printed copies of the report on the date of the new day in another record of the table? If someone can help
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Today, 20:43
Joined
May 7, 2009
Messages
16,135
manually you'll have to hire a service of someone.
when a person will print a report, he need to notify this person
which report and how many will be printed.

this man then record it in his log book.
at the end of the day, he summarized the logs.
 

azhar2006

Registered User.
Local time
Today, 05:43
Joined
Feb 8, 2012
Messages
180
manually you'll have to hire a service of someone.
when a person will print a report, he need to notify this person
which report and how many will be printed.

this man then record it in his log book.
at the end of the day, he summarized the logs.
Is this true my friend or is it a joke?:):cool:
 

Gasman

Enthusiastic Amateur
Local time
Today, 13:43
Joined
Sep 21, 2011
Messages
10,354
Might be able to get that from the printer depending on how good it is?
Think about it, I select to print a report, the print dialog comes up. I select 10 copies.?
The access program can only tell it has been asked to print that report once?
 

azhar2006

Registered User.
Local time
Today, 05:43
Joined
Feb 8, 2012
Messages
180
Might be able to get that from the printer depending on how good it is?
Think about it, I select to print a report, the print dialog comes up. I select 10 copies.?
The access program can only tell it has been asked to print that report once?
Yes, very logical. But I meant that each record has an ID number. This number is unique. If a report bearing this ID number is printed, we will know over the course of the year or month that this ID number has been printed how many times a report has been printed for it. that is my point ...By the way, it's just an idea. Perhaps none of the professional programmers on this forum thought of it. Because we know that we always print two reports, the first for it to go to the side that requests it, and the other as a true copy for preservation in galaxies or archives.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 05:43
Joined
Oct 29, 2018
Messages
18,792
Yes, very logical. But I meant that each record has an ID number. This number is unique. If a report bearing this ID number is printed, we will know over the course of the year or month that this ID number has been printed how many times a report has been printed for it. that is my point ...By the way, it's just an idea. Perhaps none of the professional programmers on this forum thought of it. Because we know that we always print two reports, the first for it to go to the side that requests it, and the other as a true copy for preservation in galaxies or archives.
I think maybe you can only track the "intent" to print the record, but not whether it was actually printed or not, since the printer is outside of Access' control. In reality, you could probably only track how many times a record was "viewed."
 

isladogs

CID VIP
Local time
Today, 13:43
Joined
Jan 14, 2017
Messages
16,088
I agree. You can easily count the number of times the Print button is clicked as well as recording the date/time, workstation, username on each occasion. However it may not always physically get printed if e.g. There is a paper jam or ink has run out..
As already pointed out it will be harder to count the number of copies selected in the print dialog.
If despite all of the above, you think the data will be meaningful, then go ahead and save it. Your choice.
 

azhar2006

Registered User.
Local time
Today, 05:43
Joined
Feb 8, 2012
Messages
180
I agree. You can easily count the number of times the Print button is clicked as well as recording the date/time, workstation, username on each occasion. However it may not always physically get printed if e.g. There is a paper jam or ink has run out..
As already pointed out it will be harder to count the number of copies selected in the print dialog.
If despite all of the above, you think the data will be meaningful, then go ahead and save it. Your choice.
Yes that's good . I don't use the print preview button, but I use an event that prints directly. If a paper jam occurs, it happens once a week, I think. But we will come out with minimal losses. Meaning that we actually entered the number of times and when the report was withdrawn.I thought about something else, which is that the print command button performs two actions, the first is to print the report and it comes out of the printer, and the other event is that it also prints the report with a dummy printer (PDF) and exports the report inside the computer and saves it as an image or file (PDF)
 
Local time
Today, 13:43
Joined
Jul 25, 2020
Messages
64
Sure you can easily count the number of times the Print button is clicked as well as recording the date/time, workstation, username on each occasion. However it may not always physically get printed if e.g. "There is a paper jam or ink has run out.."

Can you not just interpret the print spooler to decide if the printer actually printed the file or not then if print unsuccessful -1 on the calculation?

See: Get the number of print jobs in a print que & more importantly check the status of the print maybe:-

 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:43
Joined
Feb 28, 2001
Messages
22,564
I'll concur with the others on this one. You can count only those things over which you have control.

If you queue up a report to the printer with a specific number of copies, it is possible to set the number of copies. You can record that number.

If you print to a PDF, someone could then queue up a print job of the PDF, which is now a file outside of your control. Access never sees that print job and therefore cannot count it.
 

azhar2006

Registered User.
Local time
Today, 05:43
Joined
Feb 8, 2012
Messages
180
I'll concur with the others on this one. You can count only those things over which you have control.

If you queue up a report to the printer with a specific number of copies, it is possible to set the number of copies. You can record that number.

If you print to a PDF, someone could then queue up a print job of the PDF, which is now a file outside of your control. Access never sees that print job and therefore cannot count it.
What you say is very logical. Thanks for all the opinions
 
Local time
Today, 13:43
Joined
Jul 25, 2020
Messages
64
This is something I will need in my application. Its a necessity not a nicety. The issue can also be linked to the inaccuracy of a printer being reported as on line when it's not. I am going to work on a solution for this; I cannot accept that we are unable to identify with accuracy the printer status or whether a print request was completed successfully. Wish me look lol
 
Last edited:

theDBguy

I’m here to help
Staff member
Local time
Today, 05:43
Joined
Oct 29, 2018
Messages
18,792
This is something I will need in my application. Its a necessity not a nicely. The issue can also be linked to the inaccuracy of a printer being reported as on line when it's not. I am going to work on a solution for this; I cannot accept that we cannot identify with accuracy the printer status or whether a print request was completed successfully. Wish me look lol
Hi. Good luck. Seriously, I hope you do find a working solution for this problem. I've seen so many discussions on this topic, not just in this forum, so I know a lot of people could benefit from it.
 

Uncle Gizmo

Nifty Access Guy
Staff member
Local time
Today, 13:43
Joined
Jul 9, 2003
Messages
14,464
I don't know much about big corporate printing machines, but I am aware that they have the ability to to monitor the number of reports/pages printed by department and the like. I'm pretty sure they can have security measures to stop people printing out confidential information, or at least recording who printed what when. I wondered if that might be a better route to solving your problem, take advantage of the inbuilt functionality of the printers.
 
Local time
Today, 13:43
Joined
Jul 25, 2020
Messages
64
I don't know much about big corporate printing machines, but I am aware that they have the ability to to monitor the number of reports/pages printed by department and the like. I'm pretty sure they can have security measures to stop people printing out confidential information, or at least recording who printed what when. I wondered if that might be a better route to solving your problem, take advantage of the inbuilt functionality of the printers.
Yes; i am aware and have successfully programmed a raspberry pi to do just this using the Unix print system CUPS software when the printer is not capable of storing such information or i need to enable a printer to work wirelessly when wireless capability is non existent out of the box. Corporate heavy workload printers similar to photocopiers I've come across have build in storage and use HTTP interface to manage the printer which is typical. The Windows Print Spool service was used historically by hackers therefore a series of patches were released to protect from this which will make a programming solution harder but not impossible as i will need to tap this service to achieve my goal.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:43
Joined
Feb 28, 2001
Messages
22,564
The modern printing machine has the ability to remember the number of pages it has printed and the number of jobs it has accepted. It may also have a log of some sort. But the machines that have detailed log capacity are very expensive. The U.S. Navy had some of those because we had classified machines on-site and sensitive machines all over the place - sensitive in the "security" sense of the word. They were "FOUO" - "For Official Use Only" and thus remembered what they did for regular reporting. To get those reports, we had to learn each printer's (usually proprietary) control language so that we could ask it for the information it had stored. "Budget" printers probably do not have those abilities.

@JasonH, print tracking may be a requirement for you, but unless you have the right equipment, it will be impossible to comply.

I agree with theDBguy that we have seen this problem before AND that it would be of benefit to many. It might be time to invest in some WINAPI books that might get you closer. But here is the final nail in the crate for this little problem. Autonomous network printers take a job and signal "OK" when you send the last print buffer. The PC's printer driver software has NO CLUE as to how many jobs can be backlogged on a networked printer because some office printers have small disk drives that can be used to store pending jobs. And once that print job leaves the PC, it leaves the scope of visibility to Access. Not trying to be Debbie Downer here, but you need to understand what you are facing in this problem.

EDIT: Your post and mine crossed ... so it appears that you DO indeed understand the complexity. All I can say is "Good luck."
 
Local time
Today, 13:43
Joined
Jul 25, 2020
Messages
64
Hi, yes, i fully understand the complexity and i also believe its likely impossible to be 100% accurate unless you have a dedicated printer as you refer to with the capability built in. Even then there's no guarantee the end result is legible due to fuser failure for laser printers of clogged ink heads. Almost all of the logging i require for my project can easily be gathered from manipulation of the database ie, day, time, report name, printer name, port, who requested the print, to which printer etc. including counting. The argument is that even after all this how do we know the print request was actioned and successful so we can identify unsuccessful thus not adding to the count with successful being that the printer printed the request. This logging combined with some simple checking of the spooler of the printer identifying the state of a printer spool JOBS and check for Status Error, Offline, Paper Out, Blocked would be enough. The fact that it successfully printed or not is not that important to me; more importantly is the fact that a request was made to print it in the first place therefore this is easily arbitrated. The fact it came out of the printer of not is irrespective however knowing this would help for sure. and this make the logging more accurate.

 

azhar2006

Registered User.
Local time
Today, 05:43
Joined
Feb 8, 2012
Messages
180
Hi, yes, i fully understand the complexity and i also believe its likely impossible to be 100% accurate unless you have a dedicated printer as you refer to with the capability built in. Even then there's no guarantee the end result is legible due to fuser failure for laser printers of clogged ink heads. Almost all of the logging i require for my project can easily be gathered from manipulation of the database ie, day, time, report name, printer name, port, who requested the print, to which printer etc. including counting. The argument is that even after all this how do we know the print request was actioned and successful so we can identify unsuccessful thus not adding to the count with successful being that the printer printed the request. This logging combined with some simple checking of the spooler of the printer identifying the state of a printer spool JOBS and check for Status Error, Offline, Paper Out, Blocked would be enough. The fact that it successfully printed or not is not that important to me; more importantly is the fact that a request was made to print it in the first place therefore this is easily arbitrated. The fact it came out of the printer of not is irrespective however knowing this would help for sure. and this make the logging more accurate.

Yes, that's why we are in 2021 and our institutions are still committed to working with paper archives, which is a very sophisticated system that the United Kingdom put in place for us in the twenties of the last century, and we are still working on this system, which I consider very complex, because it contains the keys to files and archives and many other things Consider it a relational database. Therefore, the second version of the report is sufficient evidence to withdraw this report.
 

Users who are viewing this thread

Top Bottom