MS Access Report Fields overlap on print
I support an Access application and recently several new machines were added that are Win 7 with Access 2007. The new machines print several fields on top of each other overlapping on the page when printed, they look fine in print preview! I suspect this is a printer driver problem since I can print the report from Win 7 on my Canon printers but the customers HP Laser Jet 5200 Series PCL 5 prints the overlapping fields. The customer has been printing these reports for years (and still can) on XP machines even with the same printer. If anyone knows of anything that can be done from within access please let me know.
ASKER
Thanks for the idea, I'll try it but it will be a few days.
Also, what font(s) are you using?
ASKER
Good thought on the fonts, I'm pretty sure they are all windows standard fonts, but I'll check.
ASKER
I've requested that this question be closed as follows:
Accepted answer: 0 points for vtechdev's comment #a36601662
for the following reason:
because I have to clear this crap before asking another question and I pay good money for this service but no answer solved the problem totally unacceptable!
Accepted answer: 0 points for vtechdev's comment #a36601662
for the following reason:
because I have to clear this crap before asking another question and I pay good money for this service but no answer solved the problem totally unacceptable!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi Nick,
Thanks for the response, your ideas are good, but they are things I tried long before posting here. I realize that the community can only help if I keep providing detailed feedback, but when the suggestions are things at the beginning of my troubleshooting list I don't have time to keep dealing with them. My frustration isn't with you, it is with Experts Exchange. I pay them so I don't have to mess around with years old questions when something comes up.
I think it is about time to drop EE.
Thanks for the response, your ideas are good, but they are things I tried long before posting here. I realize that the community can only help if I keep providing detailed feedback, but when the suggestions are things at the beginning of my troubleshooting list I don't have time to keep dealing with them. My frustration isn't with you, it is with Experts Exchange. I pay them so I don't have to mess around with years old questions when something comes up.
I think it is about time to drop EE.
It is always hard to know the skill level of the Asker when a question first pops up, and you know what they say about assume. And in a troubleshooting volume defined by expense, difficulty, and likelihood of success, it is always good to start at free, easy and likely and move out from there. I have 'reports' -- mailing labels for Okidata continuous forms -- that get VERY pissy if they are opened on a machine without that printer installed. So much so that I have VBA code in place to force the driver, the paper size and all the margins on the damned things so that they work seamlessly for the end users -- but that is a very involved solution.
Intermediate to that is hooking your Win7 unit to the customer's HP physical printer to see if the problem follows the printer or the OS.
Other issues can include 64 bit vs 32 bit drivers and MS native drivers vs HP universal ones, so there are a lot of permutations that can result.
Other things to try are to share the Win7-HP printer. Install the shared printer on a good XP box. Then, from XP, share the shared printer, and install it back on the Win 7 box. Print to that back-forth arrangement. Does the job come out right when an XP box is in the loop for the print processing?
There are other possibilities to try as well -- but they are moving outward on the hassle/likelihood curve.
If the printer is shared on the Win 7 box, can the XP boxes print correctly to it over the network, or does it always bollux up the report regardless of where it comes form?
I have a good memory for detail, but not time flow. Was this Q really from 2011, or has EE messed up the dates?
Is it still an issue that you'd like to solve?
Intermediate to that is hooking your Win7 unit to the customer's HP physical printer to see if the problem follows the printer or the OS.
Other issues can include 64 bit vs 32 bit drivers and MS native drivers vs HP universal ones, so there are a lot of permutations that can result.
Other things to try are to share the Win7-HP printer. Install the shared printer on a good XP box. Then, from XP, share the shared printer, and install it back on the Win 7 box. Print to that back-forth arrangement. Does the job come out right when an XP box is in the loop for the print processing?
There are other possibilities to try as well -- but they are moving outward on the hassle/likelihood curve.
If the printer is shared on the Win 7 box, can the XP boxes print correctly to it over the network, or does it always bollux up the report regardless of where it comes form?
I have a good memory for detail, but not time flow. Was this Q really from 2011, or has EE messed up the dates?
Is it still an issue that you'd like to solve?
ASKER
The question really is that old, and the client has changed printers 2 or 3 times since!
I know Access can be very temperamental with print drivers and I'm familiar with how many variations there can be between OS, Microsoft vs HP etc.
If everything prints 8.5x11 the printer doesn't really matter with Access, but the second you have multiple reports in a project printing to multiple different printers in multiple sizes it all goes downhill pretty quick. The app in question has been ported to .NET against SQL Server so its a moot point. Thanks for taking the time to look into it, clearly you've been to same level of hell I had to visit.
I know Access can be very temperamental with print drivers and I'm familiar with how many variations there can be between OS, Microsoft vs HP etc.
If everything prints 8.5x11 the printer doesn't really matter with Access, but the second you have multiple reports in a project printing to multiple different printers in multiple sizes it all goes downhill pretty quick. The app in question has been ported to .NET against SQL Server so its a moot point. Thanks for taking the time to look into it, clearly you've been to same level of hell I had to visit.
No Problem!
Sorry that I could not have been of timely assistance.
"The app in question has been ported to .NET against SQL Server ..."
Ported, or re-written to provide the same functionality?
I have a big, sprawling LOB app in Access against SQL Server Express.
I've found that ASP.Net is a huge jump in terms of struggling with syntax to do things that are fairly straight-forward to do in Access. A desktop app in VB.Net might be simpler without the wrinkles of ViewState and postback. What kinds of tools did you use in porting the app?
And most importantly, how did you replicate the report functionality?
Sorry that I could not have been of timely assistance.
"The app in question has been ported to .NET against SQL Server ..."
Ported, or re-written to provide the same functionality?
I have a big, sprawling LOB app in Access against SQL Server Express.
I've found that ASP.Net is a huge jump in terms of struggling with syntax to do things that are fairly straight-forward to do in Access. A desktop app in VB.Net might be simpler without the wrinkles of ViewState and postback. What kinds of tools did you use in porting the app?
And most importantly, how did you replicate the report functionality?
ASKER
Rewritten actually
Used Telerik controls and Telerik reporting. Not perfect, but not bad, and we resolved some other issues so the net outcome is a big improvement.
Although there were some rough parts in the conversion.
Access is a very powerful tool while the total number of users is low.
Used Telerik controls and Telerik reporting. Not perfect, but not bad, and we resolved some other issues so the net outcome is a big improvement.
Although there were some rough parts in the conversion.
Access is a very powerful tool while the total number of users is low.
We're up near 30 users, two in remote sites, now, so on the odd day there is pain.
Dev's have been asking MS for years for tools to move up from Access.
They don't seem to be listening. They got their fingers stuck in their ears murmuring "SharePoint, SharePoint, SharePoint..." but that's something that I won't touch with a stick.
Dev's have been asking MS for years for tools to move up from Access.
They don't seem to be listening. They got their fingers stuck in their ears murmuring "SharePoint, SharePoint, SharePoint..." but that's something that I won't touch with a stick.
Try opening the problem report on an XP-HP box and make a small change.
Save
Undo the change.
Save.
Make sure it prints correctly on the XP-HP machine.
Then try on the Win 7 machine.
Ideally, the dev machine should be Windows 7 with BOTH printers installed.
The HP should be the default printer on the dev machine.
Give it a go, and post the results