Report printing issue

[esmithbda]

We have an Access application here that is used by about 10 people. They each have Access on their machines, and the application itself resides on a networked drive.

The application - say we call that "Program", when opened connects to a database (also Access) - call that "Database". Both of these reside on the same shared network drive.

At most, 10 people are using "Program" at any one given time (although that would likely cause problems - the fewer using it, the better).

We have recently (past few months) seen an issue that no matter what a person's local default printer is set to on their machine, when they use "Program" and want to print - it will print to a somewhat arbitrary printer (we have about 7 printers in the office, and it chooses 1 of 3 to print to) and I can't figure out why.

I am assuming that the issue is because more than one person is running the program at any given time, so that if they want to print to one machine, it then retains that info and overrides anyone else?

Is this a common issue? Are there easy fixes so that when someone prints (via a report button that executes "DoCmd.OpenReport 'report name' acViewNormal".

My experience with database applications is more on the web client side instead of another Access client going into the database - not to mention multiple people running that same client at the same time over the network.

thanks

 

[RoyVidar]

Hi!

I don't know exactly why, but am assuming you're on the right track concerning more than one user on the same db (program) at the same time.

If it is possible, I think you should consider either
1 - each user has "their own" program locally on their harddrive
2 - each user has "their own" program on a/the network share

This might of course raise other issues, but is a "generally accepted" way of distributing info using access front end (program) against any backend (database).

Roy-Vidar

 

[esmithbda]

Yesterday one of the users couldn't print at all. When I ran the same query on my machine, I got an error that said that the printer it was defaulting to wasn't available (even though it technically was available).

It then allowed me to change where I wanted to send it via a setup dialog box.

After doing that, it then let me print there.

When I went back to the user's machine, I did the same thing and was not given the option to select.

I made a local copy of the program for her (still attaching to the network drive for the global database) and tried again - still no luck.

This printer had new drivers on it, so I suspected that she hadn't had the updated drivers yet.
I closed out of the program and then deleted the printer that was causing her issues. I then reinstalled the printer and then restarted her printer spool service.

When we tried again in the program, we still didn't get any messages, but this time it showed that it was printing to that printer - but then it never actually printed there.

I have thought about setting it up so that they each had their own copy over the network.
This desing is IMHO truly horrible, but it was working when I got here, so the fact that it is now not working makes it look in the eyes of everyone else, like something I did (even though it isn't in anyway related to anything I did).


I am wondering if it is related to patches/updates that our HFNetChkPro is downloading and pushing out to the client machines.
It worked with our original install of Office (2000 Pro), so I am tempted to do a reinstall of Office on her machine to see if that resolves it (perhaps just Access).

This is made especially frustrating because three people prior to me wrote this program, but there are no comments in it at all and it is a total mishmash of hacked code that barely works.
I am supposed to keep it running and also somehow improve on it.

I want to move it to a distributed web application system sine this particular project would be perfect in that sense - but they are giving me no time to do that.
Perfect really.