Multiple instances of Access to allow for VPN useage

FizzyFish

Registered User.
Local time
Today, 04:18
Joined
Jun 16, 2006
Messages
26
I have a very elaborate Access 2000 application that uses three different SQL databases as the back end. Mostly the data is modified or selected via ADO connections.

The problem I am having is that recently users on Terminal Server are not able to open the application because for some reason the application is not allowing more than one copy of it to be opened at once. I checked everywhere and couldn't find anything that would not allow multiple instances but couldn't find anything.

Any ideas on what could be causing this? Any help is greatly appreciated
 
Last edited:
What error is it giving when you attempt to open multiple copies?
 
I'm getting a opned read-only because of one of the following occurred:
The file is locked for editing by another user, or the file (or folder in which it is located,) is marked as read-only, or you specified that you wanted to open this file as read-only.

Discovered it is happening on the PCs as well so it's not specific to VPN after all. It is an ade file that is causing the problem and I checked the directory which is not read only and the ade file is also not read only.
 
Well one thing is this, if all of your data is sent out to SQL backends, then the front end can be distributed to each of your Agents. Is this how you are doing it? Each Agent should grab his own copy of the front end and run it from his/her PC, I would think this would eliminate the problem.

Another factor that could be causing this is the record-locking type you are specifiying to access the back end databases. If you have it set to lock all records, then once someone establishes a connection to the database it will lock all of the records out for any other users.
 
All the data is in a SQL backend and the front end is distributed out to each of the PCs or Laptops. The front end runs totally independent of others.

I've tried to take a look at the record-locking but can't seem to find it. Isn't it supposed to be under Tools - Options - Advanced? The only sections that show there are DDE Operations, Default File Format, Client-server settings and the three fields (Command-line arguments, OLE/DDE Timeout, Refesh interval).
 

Attachments

  • AdvancedOptions.jpg
    AdvancedOptions.jpg
    32.9 KB · Views: 118
How is the data accessed from the Front End? Is it bound to a form? Do you use code to access it?
 
It varies but most of the forms are unbound. Some are partially bound.
 
Check how your startup form is accessing the database. If it is using code, check the code to see what kind of recordlocking there is. If it is bound, check the forms properties to see the recordlocking for it. I would assume that if this was the problem that it would be the initial form that loads that is causing it. Other than that, I'm stumped.

BTW - You were looking in the right place for the options, but I don't believe they are available to ADE files, just MDE and MDB. Here is a screenshot of the options from within an MDE and you can see it there. (Access 2003)
 

Attachments

  • untitled.jpg
    untitled.jpg
    44.3 KB · Views: 130
I want to clarify something I read to be sure you said what you meant.

It used to work. Now, after another VPN is involved, it doesn't work and is suddenly becoming read-only. Are you specifically saying that the users coming in through the VPN are having the problem and users from other paths are not?

If this is true, you might be looking at a permissions problem. If this is a formal domain environment, you must remember that a domain includes a set of permissions for the logged in user and ANOTHER set of permissions for the computer, which must have a domain account to log in to a domain.

Remember that VPNs and other network connections are slightly different in their methods of connection. Only slightly. It depends on where the VPN plunks itself down on the server side. I would review the permissions placed on the objects in question.= to see what is - and is not - allowed.

OK, I might be totally off base here. But that bit about adding a new network and a new VPN and suddenly having failures you didn't have before make my "permissions sniffer" twitch.
 
The Doc Man, it worked before the Domain Change a couple of weeks ago and not it is not working. My mistake saying it was VPN as the Network Admin just corrected what the users were telling me. It is actually when it is being run on Terminal Server that the problem occurs.

I was testing it out on the PCs as well and got basically the same error if I attempt to open more than one copy. Then I went back to a much earlier version (from Aug 2005) and it has exactly the same problem on the PCs so it's not really an issue for the PC users. The problem is the Terminal Server environment in that the users can not open even the initial application.

KernelK your information has been helpful. I have been unable to track down a problem in the application itself. The Main form that loads on startup contains multiple other unbound forms.
 
Last edited:
Terminal services environment? That might be a big problem in and of itself.

Where is Access installed? If it is on the central machine and you are using a terminal services method to "fake" multiple users, you are hosed. Access itself is open exclusively, in all likelihood.

Check your license for Access. I think you will find that, unless you have a specific kind of license, you are not allowed to run it this way. Paragraph 2 stands out in my memory as the critical clause. It could well be that Bill Gates has fixed so you CAN'T violate the licensing agreement. I wouldn't put it past him for a moment.

I also don't think it matters if you had Access licenses for everyone. The one running in the central machine only has a single-user license unless you bought a very special variant. I've heard of it but don't know much about it.

Another issue is this: If you are running via the terminal services, what user does it think each user is? I'm not sure you can do what you are doing because I'm suspicious of the account under which TS runs Access. If it runs as SYSTEM, you are screwed because that user probably has OpenExclusive rights. If you can prove that it is running as the logged-in user AT THE ACCESS LEVEL then you can look elsewhere. But basically I don't trust the TS environment when trying to share applications.
 
Thanks for the info Doc Man. I'm still struggling with this problem and it is becoming more of an issue here.

I don't think licensing is the issue since we have been running the exe on Terminal Services up to last fall with no problems. It is an ADP application ,utilizing Access2003, from which I create an ADE to run on the Terminal Server. Great tips on where to look though.
 

Users who are viewing this thread

Back
Top Bottom