Link to home
Start Free TrialLog in
Avatar of rodomahony
rodomahony

asked on

Cannot open MS Access on a Novell network drive from a Windows 7 client PC

We have a single-server network running Novell OES Small Business Edition. Our client PCs are all XP (SP3) except for one recently-purchased Windows 7 machine. Our Sales order processing is done in a Microsoft Access database, with the program installed locally on the PCs but the database on a mapped network drive. The database is split into a front and back end. It's in .mdb rather than the new .accdb format, as the client PCs run a mix of Access 2000 and Access 2007.

All works fine in this setup with the XP clients, but we are unable to open the database using the W7 machine. When attempting to do so we get an error message saying 'Could Not Update; Currently Locked'. Clicking OK to this brings up the revolving circle that has replaced the hourglass in Windows 7, then after a few seconds the message reappears. After doping this 3-4 times the program freezes and has to be closed using Task Manager.

I'm guessing this is something to do with Windows 7 security controls, but disabling UAC doesn't seem to help.
Avatar of Scott McDaniel (EE MVE )
Scott McDaniel (EE MVE )
Flag of United States of America image

In most cases this is a matter of Folder permissions. Are you certain that your Windows 7 machine is properly connected to the network, and is a member of the correct Windows Workgroup? Also insure that your users have Full permissions on that folder.

If the Win7 machine is running Access 2007+, also make sure that the folder holding that backend file is setup as a Trusted Location. This can be done directly in Access - click the Office button - Access Options - Trusted Locations. Add the folder location to the Trusted Locations sites.
Avatar of rodomahony
rodomahony

ASKER

Hi,

Thanks for the response. To answer your questions:
1) yes, the W7 machine is properly connected to the network, and I'm able to open Excel, Word etc. files on network drives from it.
2) There's only one Workgroup set up on the network, and the W7 machine is a member.
3) I'm not sure whether you mean Windows or Novell permissions. If the latter, then the answer's yes - I'm testing this logged in to Novell in my user name, which has full access to all mapped drives. If you mean Windows Folder permissions, I'm not sure - where would I check this in W7?
4) The folder holding the database (front and backend) is already set up as a trusted location in Access 2007 on the W7 machine.
Regarding #3:

Locate the folder on the Win7 box using Windows Explorer. Right click on the folder, select Properties. Assuming you have sufficient permissions to do so, you can review and manage the Security tab of the folder, which is where you set permissions.

However, given this is on a Novell network, I'm not sure exactly how permissions and such are managed. You may need to do something via the Novell interface. However, given that you are using an account with Full Permissions, I'm not sure this is the trouble.

Is the Windows 7 machine a 64-bit machine?
Hi,

When I right-click on either the mapped drive, or the folder within it which contains the database, and select properties, I don't see a 'Security' tab - only General / Previous Versions / Customise / Novell Info / Novell Rights. The last of these shows all the necessary rights to view, create, open, edit, delete files etc., inherited from Group membership in Novell.

The W7 machine is 32-bit.
I see. I'm not familiar with Novell networking, so unfortunately cannot assist you with those rights.

Where is the program installed on the Win7 box? In most cases, you should install an Access database to one of the Documents folders. Installing to Program Files on a machine can cause some issues (although disabling UAC generally can cure that).
Access is installed as part of Office 2007 in the default C:\Program Files location. However I don't have any problems with Access databases if opened on the local hard drive, so my assumption is that the problem lies somewhere in the interaction between Windows 7, Access and Novell.

  A simpler check on security: using explorer, navigate to the folder with the DB, right click and try to create a new text file.

  Then double click on it, edit, and save.

  Then try deleting the file.

  If you can do all three, there is no security issues and it's something else.

JimD.
Hi,

No problem with any of that.
What version of Novell client is installed?
FYI:

Byte-range locking fails in database applications
http://www.novell.com/support/viewContent.do?externalId=7005097&sliceId=1

  It's a bug and a client patch has been released.

JimD.
Hi,

The machine is running Novell client 2 SP1 for W7.

Although the error message matches that in  the link from JimD, our situation isn't comparable to that described on the Novell site in that
1) it refers to the problem affecting various versions of Windows including XP, but our XP machines are unaffected by it;
2) it describes the problem as occurring when a second workstation tries to access a database already opened by another - we're getting the problem when the first user tries to open it; and
3) it says the problem is fixed by the client version which we're already running.

  I haven't worked with Novell in some time, but the only other issue I'm aware of with Novell that would generate this type of message is that the maximum lock level specified in Novell is being exceeded.

  However since this is simply with opening the DB, it really sounds like it has to do more with the client as we've already eliminated the security angle.

  I would check on the Novell site for the most recent client and update as a start.

 
<<1) it refers to the problem affecting various versions of Windows including XP, but our XP machines are unaffected by it;>>

  No it does apply to OS's other then XP:

"Novell Client for Windows Vista/2008"

  And that article is fairly recent, so Novell is having issues in that area.  

<<2) it describes the problem as occurring when a second workstation tries to access a database already opened by another - we're getting the problem when the first user tries to open it; and>>

  If you read a bit closer, it's not only that situation, but ones where it should work and does not:

"Although there are also situations where an application may legitimately have specific ranges of a data file locked to prevent other users from concurrently modifying sections of the file, instances are being observed where users of an application are being denied access to a byte range even when the byte range should be unlocked and available."

<<3) it says the problem is fixed by the client version which we're already running. >>

  I'd double check that and if there are any updates.

JimD.
ASKER CERTIFIED SOLUTION
Avatar of Jim Dettman (EE MVE)
Jim Dettman (EE MVE)
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi,

I realise that the problem as described by Novell affects other OS's as well as XP - my point was that XP was described as one of those affected, but our XP machines don't experience any problem.

Re whether Novell are assuming that the problem only occurs with more than one concurrent user; I can see that the passage you quoted above could be interpreted as implying other situations also, but the article as a whole does seem to me to imply that as the trigger.

The article also says that the problem was fixed in client 2 SP1 IR1 or later. I'm pretty sure ours is later than that, having been installed in October - however I'll try the latest IR5 release and let you know how I get on with that.

Rod
Hi,

The updated client seems to have resolved the problem with Access - many thanks for your help.

Mind you, it has brought back an earlier (though more minor) problem, which is that the client won't map network drives when logging in at bootup, only after waiting 5 minutes or more.

I logged this on Experts Exchange last year when I first tested a W7 machine, and the solution suggested was to set up an alternative login profile with the tree and context left blank, and the server defined by IP rather than name. That worked at the time; I've done it with the new client, but using the alternative profile it won't log in at all for the first 5 minutes or so after bootup. If I use the default profile, identifying the tree and server, it will log in, but doesn't map the drives unless I then leave it 5 minutes or so and log in again (after which it's fine until next boot).

This is irritating, but much more minor than the Access issue in the scheme of things, and I guess I can live with it if I have to.

Rod
<<The updated client seems to have resolved the problem with Access - many thanks for your help.>>

  Well that's good to hear!  As you said, the Access specific issue shows it was resolved in R1, which was a while back.

  Never know with patches though.  Many times I don't think everything they address (or maybe it's not always obvious) is listed.

<<Mind you, it has brought back an earlier (though more minor) problem, which is that the client won't map network drives when logging in at bootup, only after waiting 5 minutes or more.>>

  That's a bummer.  What amazes me is how many bug fixes Novell is doing on that client.   I went through the release notes and there were a lot.  

   You would think after all these years, they'd know the in's and out's of writting a client, although like any company, I'm sure they've turned over personel many times, so past lessons and wisdom may not be around any longer.

  Makes me really leery of where the space program is going to end up; lot's of knowledge and experience is heading out the door with the shutdown of the shuttle program.

  Sorry, getting side tracked<g>  Well at least you have a situation you can live with.

JimD.