Solved

Access 2000 Report Will Not Save Legal Paper Size Paper Setting And Reverts Back To Letter Size

Posted on 2011-09-12
15
812 Views
Last Modified: 2012-05-12
I have a Access 2k Front-End application with some legal size reports. From years ago, I know there is a known bug with Access reports and saving the legal paper size selection when a legal report is modified and the application redistributed.  The modified report will revert back to letter.  Has something to do with saving the settings with the printer driver, etc. ... don't remember exactly but that the issue.  The work around has always been .... In the new Front-End, once distributed, print the modified legal report to the screen first then do Page ----> Setup and change the paper size to legal.  Click ok and the report will print on legal paper correctly from then on.

Now, I have a client machine (Windows XP Pro / Office 2003) the Front-End is still Office 2000 and it will not save or retain the paper size once it's changed.  I even opened the report manually in "Design" mode, made the change and check it and it goes right back to letter.

I'm thinking that it's the printer driver???  May have to uninstall and reinstall the printer and printer driver???

Any ideas or help will be appreciated.

Thanks

ET
0
Comment
Question by:Eric Sherman
  • 7
  • 3
  • 3
  • +2
15 Comments
 
LVL 84

Accepted Solution

by:
Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 400 total points
ID: 36525190
It's very possible that the printer driver on that machine is the culprit. Can you recreate the issue on other machines with the same OS and Office version? If you can, then I'd say there is an issue with that combination. If you cannot, then it would stand to reason that the machine is the issue (and the best place to start is with a reinstall of the default printer driver).
0
 
LVL 19

Author Comment

by:Eric Sherman
ID: 36525231
The client notified me there's one other machine with the same O/S and Office 2003 that's experiencing the same problem.  It's a network printer but should still have a local printer driver.  That's probably a good place to start.

Thanks,

ET
0
 
LVL 21
ID: 36525259
IIRC, Access 2000 had lots of issues with  printers.  In Access 2002 there was the  introduction of a new printer object that works much better.

One trick I use is to set up the same print multiple time with different default paper sizes. I then make the report use the specific printer.  This is very easily handles in Access 2002 and later.
0
 
LVL 19

Author Comment

by:Eric Sherman
ID: 36525340
Yes ... ITA ... but the application is very large and the client doesn't want to convert it to a later version.  I been trying to get them to move it up to somthing like 2003 to no avail which is very stable.  I think the major hold off is one of the managers wants what the Access Front-End is currently doing to be a web application without realizing just how much development work that would be.  Web apps are great and serve a great purpose these days but the F/E App above is primarily a data entry, manipulation, data interaction and reporting system.  Unlike a typical run a query and return the results back to the screen.

ET Sherman
0
 
LVL 19

Author Comment

by:Eric Sherman
ID: 36525349
I think it also could be a network permission issue as well.  Different administrators will restrict the end users local rights thus causin problems like the one above.  

I will have to check that as well.

ET
0
 
LVL 26

Assisted Solution

by:Nick67
Nick67 earned 100 total points
ID: 36525402
I have a problem report in A2003--it's a label.
Getting the report and the printer to believe that the printer can actually print to the paper size I want is always a chore.
Once I actually get it printing correctly one a machine where it will work properly, if I save the changes and THEN push out a copy to the problem machines, it workd ok until someone opens it in design view.

The Printer object was new after A2000, so there's no point posting code, but for this report I code the paper-size in OnOpen(), Detail_Format() and OnClose() and that tends to keep Access's attempts to resize things because 'you can't print to paper that size' (they're tractor-feed labels on an OkiData ML390) activity from screwing things up.

Maybe the first question to ask is "will this computer print anything to legal on this printer?"
0
 
LVL 19

Author Comment

by:Eric Sherman
ID: 36525633
<<<<Maybe the first question to ask is "will this computer print anything to legal on this printer?" >>>>

Good point Nick67 ... I will for sure check that out.  Just open an Excel Sheet and see if it will print to legal.

Maybe I can find some code to put in the Report's OnOpen() Event to specify Legal Paper Size.

ET
0
Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

 
LVL 74

Expert Comment

by:Jeffrey Coachman
ID: 36525837
This seemed to work for me in many posts, ...what the heck...worth a shot...

Open the report in Design view make a small change to the design.
Save the report.
Change the Printer setting to landscape and immediately make another small design change to the Report.
Save.
Compact Repair

Test the report.
0
 
LVL 19

Author Comment

by:Eric Sherman
ID: 36525929
Problem is on that machine ... when you select Legal Paper Size .... then click OK .... it doesn't change ... it stays on Letter.

ET
0
 
LVL 74

Expert Comment

by:Jeffrey Coachman
ID: 36527037
OK
0
 
LVL 19

Author Closing Comment

by:Eric Sherman
ID: 36535655
The problem was a Printer Driver issue ... caused by a change in printers in the Development Environment.  Since this is an Access 2000 application, I have a Windows XP machine with only Office 2000 on it dedicated to maintain, make modifications and support it.  I used to have a fancy Cannon InkJet printer but recently change it to a Brother B/W LaserJet printer.  Got tired of purchasing expensive color ink cartridges.

I modified two Legal Paper Size reports with the Brother LaserJet as the Default Printer and distributed the application.  The Windows 7 machines at the client's site did not have a problem and could File ---> Page Setup then change the paper size to legal and it would be saved.  The Windows XP Professional machines for some reason did not like whatever settings Access saved with the report from the Brother Printer Driver.  

I changed the Default printer back to the Cannon, Saved the report in Access and re-distributed it to the client's site.  All machines can now save the legal paper size with the report.

Thanks all for your input.

ET
0
 
LVL 74

Expert Comment

by:Jeffrey Coachman
ID: 36536973
OK, thanks for the info
0
 
LVL 26

Expert Comment

by:Nick67
ID: 36537251
Ok,
So the dreaded "the report was formatted for Printer X which was not found, would you like to use the default Printer Y" thing came into play?
Or Access tried hard to hide that from the end-user and in the end didn't quite succeed?

I know in the old days, it was recommended to have something with a bulletproof and fairly simple driver installed on the Dev machine like an HP LaserJet IV PCL 6 Driver.
You'd use that as the default driver, even if a physical printer didn't exist, as you developed.
When you pushed out the app to a diverse printing environment, Windows/Access did a fairly good job of seamlessly moving to whatever the end users' printer was.

Sounds like the Canon was generic and universal enough, and the Brother wasn't.
Been a long time since I had to think like that!
0
 
LVL 19

Author Comment

by:Eric Sherman
ID: 36537359
Yep ... You are "Spot On" Nick67.  One of the reasons I've been trying to years to get the client to upgrade the application to at least 2003 but no luck yet.  As mentioned earlier ... One Mgr. wants a web app to do what this Front-End is doing so and as long at it runs successfully like it does ... no major changes are in the near future.

It's kind of involved and to fully re-develop it into a web application would take at least a year to complete not to mention the development cost!!!

ET
0
 
LVL 26

Expert Comment

by:Nick67
ID: 36537395
The Access 2010 runtime is free.
For anybody not developing in Access, cost shouldn't be a barrier to upgrade for Access, at least.
And a web app is a poor sister compared to an Access application.
Just watch everyone lose their minds as you carry on with the old habit of typing part of a string in a combo box ... and instead of getting progressively closer to your desired value, it jumps around with each letter typed.
0

Featured Post

Complete Microsoft Windows PC® & Mac Backup

Backup and recovery solutions to protect all your PCs & Mac– on-premises or in remote locations. Acronis backs up entire PC or Mac with patented reliable disk imaging technology and you will be able to restore workstations to a new, dissimilar hardware in minutes.

Join & Write a Comment

Most if not all databases provide tools to filter data; even simple mail-merge programs might offer basic filtering capabilities. This is so important that, although Access has many built-in features to help the user in this task, developers often n…
In Debugging – Part 1, you learned the basics of the debugging process. You learned how to avoid bugs, as well as how to utilize the Immediate window in the debugging process. This article takes things to the next level by showing you how you can us…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…
In Microsoft Access, when working with VBA, learn some techniques for writing readable and easily maintained code.

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now