Confused On the PRTDevMode

[jwells1145]

I am trying to change the default paper size in a report. I have been trying to follow the code examples in the help file and ones that I have found online. I can't get it to work.
Here is my problem. I have 4 computers that are printing to identical label makers on COM1:. Two out of the four change the label type when printing. Need to set label type in code when print button is pressed.
If you have an example of how to do this, can you explain how the code works so I can understand what and how it works.

Thanks

Justin

 

[BobJacksonNCI]

Justin,

You can set the paper characteristics using VBA code IF you have a .MDB or an .ADP ... The logic requires opening the report in design view, so it won't work with .MDE or .ADE.

Also, this is an area that was addressed by Microsoft for Access XP. You may not have to use the code if you have that version. (I don't, so no details on it.) Also, the first thing you should do is turn off Auto Correct, if it is on (Access 2000) and see if that resolves the problem.

If you still need the code, roll up your sleeves and dig into thread702-560490



HTH,
Bob

 

[jwells1145]

Ok. Thanks. I'll try it and see what happens.

 

[jwells1145]

The code worked great Bob. Thank You.

I have another problem now. The database size is about 60MB and I am having a compiling issue. If I don't complie it takes a week and a day to open the database. Is there a way to change just the papersize and margins. I need it to work on NT 4.0, 2000, XP in Access 97 and 2003.

I have been working on this problem for way too long. I am stuck.

Thanks for the help.

Justin

 

[BobJacksonNCI]

Justin,

I don't think cutting down that logic will help.

Is the database slow to open on all flavors of Windows or selected one(s)? Especially if the issue is when using Access 2000 or XP, be sure to turn off Auto Correct.

If the problem still exists, review faq702-3742

Best I can do...
Bob

 

[jwells1145]

Thanks for the help Bob. That puts us one step closer to solving the problem.

The database is slow because we have shortcuts on our desktops pointing to our server. This is for ease of upgading and fixing problems with the mdb. Our data is in SQL. We need a fix that will work in Access 97 if at all possible. We have several copies of Access 2003 that we are testing, so if there is a fix that will only work in 2003 I am willing to try it.

The problem behind opening the report in design mode is that we have 4 users that could use the same report at the same time. The design mode locks everybody out but one and I am not willing to put up with that greif. I need a soultion for a network database. The problem is at one site on a LAN.

Our database is all custom. It has been built from scratch. Changing code or forms is not an option that we want to consider (It would take to long to go through all the code and forms).

Anybody got any ideas.

Justin

 

[BobJacksonNCI]

I work with Access 2000 interfacing with SQL 7. If you are going to develop Access Projects (Access front end direct to SQL for data), moving to Access 2003 will cut down on you aspirin, tylenol, ibuprofen, allieve bill substantially.

The problem behind opening the report in design mode is that we have 4 users that could use the same report at the same time.

That sounds like you have one copy of the front end that is being shared. If so, the solution to speed it up is to put a copy of the front end on each User's C: (local) drive. Then, they won't be sharing one printer definition. Certainly, that means effort to ensure Users are working with current copies. And you need more to do, right?

Assuming I'm right on having a single front end, the following links may be of interest:

faq705-3579

faq705-2010

I'm not sure where I came across the following, but it seems to be one of the simplest, if not as robust.

AUTOMATED FILE ROLLOUT EXAMPLE
Hi,
I have an adp which I distribute around the office by the use of a batch file..

Like the following..
1. make a batch file like this on your server

Update.bat
------------------------------------------------------
rem make the directories (no harm if they're already there)
c:
cdcd "Program Files"
mkdir "OrderEntry Database"
cd "OrderEntry Database"

rem If the latest version file is on the PC, just start the database
if exist "OrderEntry_Database.1.24.txt" goto Startup

copy "\\ServerName\Databases\webImport\Orders.lnk"
copy "Orders.lnk" "C:\Documents and Settings\All Users\Start Menu\Orders.lnk"
copy "Orders.lnk" "C:\Documents and Settings\All Users\Desktop\Orders.lnk"

rem Copy a new front end
copy "\\ServerName\Databases\webImport\Orders.adp"
copy "\\ServerName\Databases\webImport\OrderEntry_Database.1.24.txt"
copy "\\ServerName\Databases\webImport\dll\ImportSpec\SpecDB.mdb"
copy "\\ServerName\Databases\webImport\dll\ImportSpec\TsiImpExp100.mde"

:Startup
rem fire it up
"C:\Program Files\Microsoft Office\Office10\msaccess.exe" "c:\Program Files\OrderEntry Database\orders.adp"

exit
---------------------------------------

2. make an empty text file like OrderEntry_Database.1.24.txt
Place this on the server also.

3. Make a Shortcut that points to the batch File.

Copy this shortcut to the local computer and run it.


What Happens.

1. The shortcut executes the batch file.
The batch file check if the file OrderEntry_Database.1.24.txt exists on the server. If it does, it copies down the other files to the local server. Then executes the adp file.

The beauty of this is that you can work locally on you dev version, then when your ready to update your live version, all you do is
Update the batch file with the new file name like

OrderEntry_Database.1.24.txt to
OrderEntry_Database.1.25.txt

and then change the file named OrderEntry_Database.1.24.txt to OrderEntry_Database.1.25.txt

 

[jwells1145]

Thanks again Bob. I talked to our Sr programer and he doesn't like the idea of having to do have a script to keep a report (or in our case reports) on the users PC. We may have to consider it later, but for now we are wondering if there is any other way. If not that is OK. Again I thank Bob for all the help. It has gotten us closer than we had been.

Justin

 

[BobJacksonNCI]

You're welcome!

Regret we didn't come up with a satisfactory solution.

The process of keeping a front end .MDB on the User's drive is fairly common because it removes the contention that occurs when everyone is using the same copy - and reduces network traffic. The trick is to have the "master" copy on the server and then make sure each User gets a new copy when changes are implemented. I understand the reluctance to manage more copies, but at some number of concurrent Users it will be necessary to improve performance. At that time, the choices will be to replace the front ends entirely with a higher performance application, or distribute copies...

HTH,
Bob