Shared Folder Problems

[wilko]

I'm currently having problems with splitting my database.

The situation as present it:

- I have a shared folder on my laptop, to which i have given full permission rights to a collegue, in this folder is the backend of the db which i split from a database also sat in the shared folder

- I can then go to the front end of my database either on my desktop or shared folder and update tables

- However, this is where the problems start. The copy of the front end that my collegue has (an exact replica of mine) cant access or open any tables. Even if he opens the exact front end that I'm successful with in the shared folder. The following error message appears

"Could not find the file 'D:\Test\db_be.mdb'"

the D drive on my computer is where the shared folder 'test' is stored.

Any hints or advice on why this isnt working?

Thanks in anticipation

Ross

 

[Moniker]

His copy of the DB is looking on his computer in his D:\ drive for the backend that's on your laptop.

You need to reference your computer correctly from his computer, usually something like this:

\\YourComputerName\YourFolderPath

To get the exact structure of that, have him look in your shared folder from Windows Explorer and look at the path in the title bar.

 

[wilko]

Thanks for the advice, much appreciated

 

[wilko]

Moniker, i fully understand where you're comming from, however what I'm not sure on is how to execute pointing the linked tables to the UNC path name rather than the drive on my PC.

When in the database splitter function, I'm assuming i go to network places and then select my shared folder. If i hover my mouse over this folder the path as such is shown

D:\database

I cant see how i get the linked tabled manager to point to the UNC Path rather than the folder sat on my computer,

any advice?

 

[wilko]

Apologies, just made another finding.

I added a new network place

\\mylaptop\folderpath

in the linked tabled manager i selected this directory to split my database too. However, when i then go and look at the path in the database instead of being

"\\mylaptop\folderpath"

its
"d:\folderpath\file"

frustrating! haha

 

[Moniker]

Right-click on "My Computer", go to the tab "Computer Name". In the Full Computer Name line is the first part of what you need. The second part of it is the folder\filepath combo on your machine. What's happening is that you're assigning drive letters on his machine, which is causing the confusion. For example, I have a K:\ drive that's actually a network link, but you can't tell that from the path it gives you.

 

[The_Doc_Man]

This is also helped if you make the links in the FE on YOUR database on YOUR machine first and test that using UNC references. Then and only then should you allow your colleague to copy the FE.

 

[wilko]

Thanks for the replies Moniker and Doc Man, apologies for the late reply. I'm still having a bit of bother trying to split this database.

Ive tested this out quickly on a one table database, to ensure that nothing in the larger more complicated db is causing the issues. My procedure:

- Created one table database
- Split database
- Saving the backend into my COLLEAGUES shared folder (via UNC path \\hislaptop\folder\db.be). I added his shared folder as a network place in 'my network places' and selected that location when splitting the db
- I can then use the front end db from my machine and update information into the back end on his shared folder (tried and tested, this works)
- HOWEVER
- Once I distribute the front end to my colleague the following error message appears, (he can open the db, this error message only appears once he tries to open the linked table)
- “The Microsoft Jet database engine cannot open
the file '(\\hislaptop\folder\db.be)'. It is already opened exclusively by another user, or
you need permission to view its data.”

After this error we decided to go through the same procedure, but instead he created the one table db on his machine and saved the back end in MY shared folder (via UNC path)
- He can then use his front end to input data and it updates the backend in my shared folder
- I then take a copy of his front end.... I can open the db and open the table... HOWEVER... I cant input any information into the table, I dont even have the ability to click on the cells

Would it make a difference if I converted the front ends into MDE’s rather than MDB’s? (Incidentally I did try that, and still not luck, but just wondered if it was standard practice to distribute the FE in MDE format?)

Another point of note: I did mess about with changing security and creating a new mdw file, however I have set both of our workgroup files back to the standard ‘system.mdw’ so cant see why this would be causing the issue.

Apologies for rambling on, any advice would be greatly appreciated

Regards

Ross

 

[wilko]

This is also helped if you make the links in the FE on YOUR database on YOUR machine first and test that using UNC references. Then and only then should you allow your colleague to copy the FE.

Doc Man, I was a bit slow in understanding where you were comming from, but the penny did drop after i wrote my long winded post!

I just acted on your advice, for clarification:

- created one table database
- split database onto my shared folder (located myshared folder by going through Entire Network>MS Windows Network>myspecific shared folder
- database successfully split!

Some interesting results.... I can open my FE db and also open the table. However, I cant input any information into the table, the table headers appear but no cells below to input information, (one of the problems experienced in post above)

Surely I have full admin rights to my folder (having just looking on security settings it appears I have.)

Any ideas as to why its going a bit wrong?

Thanks again

 

[The_Doc_Man]

While I can't be sure, this smells like a Windows security issue having to do with who owns the files. (Answer: The person who created the file owns the file... it is what comes next that is important here.)

Unfortunately, Access exposes a complex fact - {thick Shrek accent}: Security is like an onion. It's got layers. {Plaintive donkey voice in background} I like parfait!

When you properly secure an Access database, you provide information about who may touch the data inside the MDB file. This is because, to Access, the file has discernible structure. You are allowed to provide the workgroup with security guidelines for the fine structure of that file.

But Windows didn't roll over and play dead when you diddled with the workgroup. Windows security must also be appeased regarding the file as a whole. Not only that, but you are dealing with two Windows layers! The files of the database (MDB, LDB, WKG, and related external files) have security in and of themselves, as distinct and monolithic object.

THEN there is the domain-related security associated with network accesses. When you access a shared volume, you have to remember that Windows MINIMIZES security between the object and its share. That is, for any setting, you get the MOST RESTRICTIVE of the settings. Which is why, for a shared area for an Access database, you must set the share permissions to "anything goes." (Otherwise the minimization eats something.)

OK, NOW you have to set permissions on the individual files and the folder consistent with "coarse" setting Modify. There are posts you can find via the Search verb that would give you the detailed settings you need.

I would say that this kind of complex security setup work is exactly why security gurus get the big bucks. Except that they usually pay us less than the big bucks. But at least they allow us to torture our users with obscure security settings and make them jump through impossible hoops. Sort of like a cat playing with its food...

 

[wilko]

Doc Man,

Just a quick note to acknowledge your thorough reply, I'm going to have a look at this over the weekend. I'll report back any findings, hopefully success

Regards

Ross