Printing Current record (1 Viewer)

Garcimat

Member
Local time
Today, 11:31
Joined
Jun 7, 2022
Messages
67
Hi guys
When I finish to collect the data in a form, I make the button to save the data available, I save the data as a new record, close the form and open a first page form….
I need to print only this “form” record. I have tried docmd.printout and current but prints all the records from the data table.
Is there a way to print only the current record that is showing in my form ?
I was thinking in save the record collect some unique values (SWO_Number and PTF_Number or Max ID value) in global variables and use a sql query and then print it, but I don’t know how to do it.
Thanks in advance
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 17:31
Joined
Oct 29, 2018
Messages
21,358
Have you tried using a report? When you print a report, you can specify only one record to print.
 

Garcimat

Member
Local time
Today, 11:31
Joined
Jun 7, 2022
Messages
67
That would work if I could use a global var as criteria in the query… Or get the highest ID (auto number field)
I don’t know how to do this
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:31
Joined
Feb 19, 2002
Messages
42,981
If you are printing from the current form, you have the autonumber that was just generated. Use it in the OpenReport's where argument.

Technically, you can print forms but only if they are single record. Subforms will not paginate like they do in a report. Also, forms tend to be colorful and take a lot more ink to print than reports so most people just make a report and print that.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:31
Joined
Feb 19, 2002
Messages
42,981
Don't take my advice on anything. What do I know? Not sure why you decided to add that comment to an old thread but fine although his forum isn't like FB where you report what you are having for dinner and post pictures.
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Today, 08:31
Joined
May 7, 2009
Messages
19,169
docmd.printout
there is another "missing" argument to this command which is acSelection.
Code:
'make sure to focus on the current record
DoCmd.RunCommand acCmdSelectRecord
'print the current record
DoCmd.PrintOut acSelection
 

twgonder

Member
Local time
Yesterday, 19:31
Joined
Jul 27, 2022
Messages
177
Don't take my advice on anything. What do I know? Not sure why you decided to add that comment to an old thread but fine although his forum isn't like FB where you report what you are having for dinner and post pictures.
I've followed your past advice on several things. For some reason the old post showed up to me in the daily list. It was a topic I'm interested in. I didn't find a solution here, but did search and thought to share a possible solution, if not for the original poster, then anyone else that might find the post as I did. I don't see my dinner selection being posted, nor any vacation photos.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:31
Joined
Feb 19, 2002
Messages
42,981
You have said several times that you want to learn how to use Access. Well consider this. If Forms and Reports had the same properties and methods, why would both exist? Perhaps because Forms are best for interactive viewing and Reports are best for printing?? Just because you can print a form doesn't mean the results will be optimal. Also, if you have subforms, they will not paginate so you will only see the first page. Just one of the many reasons to use the objects of Access as the Access application designers intended. And finally, you can save a Form as a Report. That won't get rid of the color but it will account for all the controls and you can take it from there. Open the Form in Design view. Go to File/Save As/Object and choose Report.
 

twgonder

Member
Local time
Yesterday, 19:31
Joined
Jul 27, 2022
Messages
177
You have said several times that you want to learn how to use Access. Well consider this. If Forms and Reports had the same properties and methods, why would both exist? Perhaps because Forms are best for interactive viewing and Reports are best for printing?? Just because you can print a form doesn't mean the results will be optimal. Also, if you have subforms, they will not paginate so you will only see the first page. Just one of the many reasons to use the objects of Access as the Access application designers intended. And finally, you can save a Form as a Report. That won't get rid of the color but it will account for all the controls and you can take it from there. Open the Form in Design view. Go to File/Save As/Object and choose Report.
Look at the Northwind Traders DB and tell me MS designed one way to get things done. 🤣
(I'm laughing at the Northwind Traders, not you.)
Thanks for the form tip, but I've already solved the print one record on a form challenge.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:31
Joined
Feb 19, 2002
Messages
42,981
MS did design ONE way to do things. They just don't always prevent you from doing something different. Sometimes, it will just be harder. Sometimes you will think your method works because you didn't test thoroughly and because you don't understand the event model but there is a problem waiting to bite you. You can learn best practices from the experts which is boring and a lot like defensive driving but which will save you a lot of problems over time or you can be sloppy and take shortcuts and then flail and complain how bad and backward Access is.

I came to Access from IMS/CICS/COBOL/DB2/Oracle on the IBM mainframe where I developed applications for thousands of concurrent users and processed millions of rows of data when working with batch processes. Switching from functional thinking to event driven logic took some doing. I am 100% self taught regarding Access but at least I already understood good programming practices and Relational database design so I didn't have those hurdles also. I found Access to be such a productive tool compared to COBOL that I transitioned from main frame work to almost totally Access development with mostly SQL Server (or other RDBMS depending on the client's needs) as the BE. I find that the hardest people to train to use Access are people who have been programmers using other platforms. For some reason, they think they are smarter than Access and resist learning the "Access way" because they think it is somehow inferior. I guess it is all that bad press you see on the internet. However, if you read those articles closely, and you know what Access actually is (it is NOT a database engine), you will see that the people who rail against Access don't even know what Access is. Their complaints are always about the limitations and shortcomings of Jet and ACE which are the desktop database engines closely associated with the RAD tool "Access". Access is a RAD tool. It is NOT a general purpose development platform. You would never use it to develop web pages or video games. Nor would you use it to write channel programs (low level programs that connect the OS to various external drives). Access does what it does and it does it superbly. You just need to understand what its target application is and make sure that it works for you. If it doesn't, find yourself a different tool that will allow you to twiddle the bits you want to twiddle. Just because Access isn't a tool for all uses, doesn't make it bad. It actually makes it better since it is targeted. I far prefer to use my camera to take photos than to use my cell phone. My cell phone is a jack of all trades but a master of none. My old flip phone was far better as a phone than is my current, very expensive "smart" phone. My smart phone is a pretty bad flashlight but since I rarely have a flashlight in my purse, I use the poor tool that I do have and I don't complain.

From my perspective, I've written my million lines of code and I don't need the practice. Therefore, my last inclination is to write code rather than my first. I use property settings, Access methods, and queries. I use VBA for validation in the FORM's BeforeUpdate event to ensure that I don't save bad data or empty records. Then I write VBA if none of the other options get me to where I need to go for the rest of the logic I need to implement.

You would do well to find the list of VBA functions organized by category and keep it close at hand. The alpha list is useless since if you are looking for a function, you are unlikely to know its name. Then find the documentation for form and control events. Most of it is lousy but there are some gems out there.
 

twgonder

Member
Local time
Yesterday, 19:31
Joined
Jul 27, 2022
Messages
177
MS did design ONE way to do things. They just don't always prevent you from doing something different. Sometimes, it will just be harder. Sometimes you will think your method works because you didn't test thoroughly and because you don't understand the event model but there is a problem waiting to bite you. You can learn best practices from the experts which is boring and a lot like defensive driving but which will save you a lot of problems over time or you can be sloppy and take shortcuts and then flail and complain how bad and backward Access is.

I came to Access from IMS/CICS/COBOL/DB2/Oracle on the IBM mainframe where I developed applications for thousands of concurrent users and processed millions of rows of data when working with batch processes. Switching from functional thinking to event driven logic took some doing. I am 100% self taught regarding Access but at least I already understood good programming practices and Relational database design so I didn't have those hurdles also. I found Access to be such a productive tool compared to COBOL that I transitioned from main frame work to almost totally Access development with mostly SQL Server (or other RDBMS depending on the client's needs) as the BE. I find that the hardest people to train to use Access are people who have been programmers using other platforms. For some reason, they think they are smarter than Access and resist learning the "Access way" because they think it is somehow inferior. I guess it is all that bad press you see on the internet. However, if you read those articles closely, and you know what Access actually is (it is NOT a database engine), you will see that the people who rail against Access don't even know what Access is. Their complaints are always about the limitations and shortcomings of Jet and ACE which are the desktop database engines closely associated with the RAD tool "Access". Access is a RAD tool. It is NOT a general purpose development platform. You would never use it to develop web pages or video games. Nor would you use it to write channel programs (low level programs that connect the OS to various external drives). Access does what it does and it does it superbly. You just need to understand what its target application is and make sure that it works for you. If it doesn't, find yourself a different tool that will allow you to twiddle the bits you want to twiddle. Just because Access isn't a tool for all uses, doesn't make it bad. It actually makes it better since it is targeted. I far prefer to use my camera to take photos than to use my cell phone. My cell phone is a jack of all trades but a master of none. My old flip phone was far better as a phone than is my current, very expensive "smart" phone. My smart phone is a pretty bad flashlight but since I rarely have a flashlight in my purse, I use the poor tool that I do have and I don't complain.

From my perspective, I've written my million lines of code and I don't need the practice. Therefore, my last inclination is to write code rather than my first. I use property settings, Access methods, and queries. I use VBA for validation in the FORM's BeforeUpdate event to ensure that I don't save bad data or empty records. Then I write VBA if none of the other options get me to where I need to go for the rest of the logic I need to implement.

You would do well to find the list of VBA functions organized by category and keep it close at hand. The alpha list is useless since if you are looking for a function, you are unlikely to know its name. Then find the documentation for form and control events. Most of it is lousy but there are some gems out there.
I hear ya' and been there with you (in a parallel db universe.) Now that's funny, one of the flavors of the db I used was called Universe. It had many names. Rocket Software has bought up most of the licenses to corner the revenue stream from legacy systems still in use.
 

Users who are viewing this thread

Top Bottom