Jump to content

FileMaker Pro 6 sharing broken


This topic is 6444 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Previously this client (of mine) was able to share databases. Recently even though a database is open on one computer, the second user can only open it as readonly. However sharing has been defined for the database. The client does not know what happened to change this ... any ideas what could prevent sharing?

In the Sharing preferences the file is defined as Multi-User.

Link to comment
Share on other sites

I should have added this info:

When the second person (on the remote machine) attempts to open the file they get a message that they are about to become host ... but then they get a message that the file was not closed properly and filemaker performs a consistency check. But this file has not been closed ... so clearly some indicator is telling the second computer that the file is closed which is why they attempt to open as host.

Link to comment
Share on other sites

It sounds like the second computer is opening the file from a network drive, not through FileMaker networking (i.e. "Open Remote...") Have your client disable File Sharing on the host computer, and show them how to use Open Remote, or provide a launcher file that does it automatically.

It's also not a bad idea to move the data into a clean clone, as opening files on a network drive like that is a frequent source of file corruption.

Link to comment
Share on other sites

I can certainly check this but my I don't think they have changed the way that they opened the file. I am also a bit confused about when it is necessary to use Open Remote vs. Open. I thought that normal Open would still do the necessary sharing.

(Excuse me if I am not expressing myself properly ... I only work on FM when the client has a problem ... and that is not frequently.)

Link to comment
Share on other sites

Well, "Open" start the user out looking at the file structure on their own computer. There's an "Open Remote" button on that screen, but if the files ARE shared on a network volume, and the user navigates to that network volume in the Open Dialog, you still have the same problem. It's one step easier, and less chance of confusion to use the "Open Remote" command under the File menu.

Link to comment
Share on other sites

There seems to be some static in the line.

If I understand you correctly they both function the same way. It is mainly a performance issue.

I can't tell what "they" and "It" refer to. "Open Remote" via the File menu and "Open Remote" via the Open dialog DO perform the same way. My point was that by telling users to use Open Remove via the File menu, you make things one step easier for them and avoid a possible problem of opening a file on a network volume. Of course, using an opener file is even better.

The client does not have duplicate copies of the databases and the same thing happened when I opened the database by double clicking the database file icon in Finder.

The client having duplicate copies was not the issue I pointed to. And if the remote clients are double-clicking the actual database files in the Finder, they are doing something wrong. It is not merely a question of performance. FileMaker databases get corrupted from being shared via File Sharing. There are a number of past threads about this, as well as notes in FileMaker's Knowledge Base.

Link to comment
Share on other sites

Sorry for the dumb questions ... I have trouble keeping the terminology correct.

Let's see if I have it this time ... If they use the FM File|Open command they are using OS X file sharing and not FileMaker sharing? If they use FM File|Open Remote ... that is using FileMaker sharing?

If they used the OS X file sharing would it ever have behaved correctly with them being able to share databases?

(I did not configure this and the only file sharing I got involved with was on a Windows platform :P .)

According to the users this originally worked correctly with the first person opening being host and the second being guest with update privileges.

Link to comment
Share on other sites

If they use the FM File|Open command they are using OS X file sharing and not FileMaker sharing?

Only if they are then navigating into a network volume to open the database. They could use File->Open and then hit the Open Remote button.

If they used the OS X file sharing would it ever have behaved correctly with them being able to share databases?

The OS and the application may have allowed connecting in this way, and even share the remote file via FileMaker sharing, but this is NOT an acceptible practice. To repeat, File Sharing should be turned off on the host, and the host should only host the local databases. Connecting clients then connect through Open Remote, or via an opener file.

Link to comment
Share on other sites

I'm getting totally confused ...

The OS and the application may have allowed connecting in this way, and even share the remote file via FileMaker sharing, but this is NOT an acceptible practice. To repeat, File Sharing should be turned off on the host, and the host should only host the local databases. Connecting clients then connect through Open Remote, or via an opener file.

What is the purpose of FileMaker sharing then? Are you talking about FileMaker Network Sharing or something else? I THOUGHT that one couldn't access a database via the Open Remote command unless the database was defined for Network Sharing. That is the way that I interpret the FM Help on sharing databases.

Link to comment
Share on other sites

I THOUGHT that one couldn't access a database via the Open Remote command unless the database was defined for Network Sharing. That is the way that I interpret the FM Help on sharing databases.

Correct. But that's not what the users are trying to do. They are not accessing the file through FileMaker Pro. They are accessing it thru the OS level file sharing. That will sooner rather than later destroy their file.

I recommend you get a professional developer in the Toronto area to come in and fix this for you.

Steven

Link to comment
Share on other sites

The OS and the application may have allowed connecting in this way, and even share the remote file via FileMaker sharing, but this is NOT an acceptible practice. To repeat, File Sharing should be turned off on the host, and the host should only host the local databases. Connecting clients then connect through Open Remote, or via an opener file.

I think my confusion is when you talk about File Sharing being turned of. Now I believe that you mean OS File Sharing when you say that. Unfortunately I can't turn it off because the 2nd user needs access to other files on the host computer. However, I can make the database files less accessible. Unfortunately the way that this user has set up their users/directories on both systems makes it very difficult to do this. I am going to try to reorganize that but that is a separate complicated task. This is a small charity that can't afford a "professional" so they will have to do with what I can do for them.

Thanks for all of your feedback. It has cleared the fog.

Patricia

Link to comment
Share on other sites

I think my confusion is when you talk about File Sharing being turned of. Now I believe that you mean OS File Sharing when you say that.

Of course. Glad we're on the same wavelength now. :P

Periodically we hear the excuse about funding being the reason for a poor setup, but it really should be thought of in terms of how important the data is. For most organizations, the data is critical, and loss or corruption of that data would be a big problem.

Even if they have a recent backup or paper copies, the time and labor required to get everything restored, plus loss of productivity in the mean time, could easily exceed the cost of a separate computer (even used) running FileMaker Pro with an additional license of FileMaker.

Link to comment
Share on other sites

I understand your point about the importance of data. And I think the user does but they have to understand what they are doing wrong before they will act.

BTW, I have decided to move all of the data that both computers need access to into the first user's Public folder. That will permit guest access to the shared files. I have to change permissions to allow read-write access to the files in that directory. Having done that I will remove access to the other files and define a host so that they can use Open Remote to access their databases. I hope that solves the problem.

But I still do not know what caused the problem of the second computer not knowing that the database was already open. Do you know where FM stores that information? I'd like to repair that. It might be a problem with permissions. Do you know if the status is stored in the database or in a separate file? :confused:

Thanks again.

Link to comment
Share on other sites

BTW, I have decided to move all of the data that both computers need access to into the first user's Public folder. That will permit guest access to the shared files.

[color:red]You know, I am violating my own and FMI's policy here about support for older versions of the products. But you are going to toast your files if you keep this up. I am surprised that they haven't been damaged already. Do not--repeat DO NOT--attempt to share FileMaker Pro files, especially older ones, through OS level sharing. And that's exactly what you are doing with this public folder and file permissions business.

If a user has FileMaker Pro opens a file on one computer, but only if that user opens it, another user--up to 2 or 3--can access it by opening his or her own copy of FileMaker Pro and accessing the already opened and hosted file via File-->Open-->Remote. That is the correct process.

I do not recommend peer to peer sharing. But it will work in these controlled instances.

Steven

Link to comment
Share on other sites

Oops ... I guess I did not express myself very well there. Mea culpa.

What I was trying to say was that I plan on moving all [color:orange]non FileMaker data into the [color:orange]public folder so that I could remove OS File Sharing access to the FileMaker databases. At present the second user has access to all of the files in the first user's directory. In order to enforce use of Open Remote ... I need to stop this full access.

Then I will use an opener script to do the Open Remote.

Does that make more sense? Sorry to cause you both to blow a fuse :P

Edited by Guest
Link to comment
Share on other sites

But I still do not know what caused the problem of the second computer not knowing that the database was already open. Do you know where FM stores that information? I'd like to repair that. It might be a problem with permissions. Do you know if the status is stored in the database or in a separate file?

Given the outrage that I caused by my previous poor wording, I wonder if anyone is willing to answer this part of my question. If you have any ideas I'd really like to hear them.

Thanks

Link to comment
Share on other sites

When a file in an older version of FileMaker Pro opened it expected to be either a host or a guest. FileMaker Pro told itself that.

One of the problems with using the OS level sharing to access the physical file and send it an event was that if had already been opened as the host in the first instance by another copy of FileMaker Pro, then you had two copies of the application each thinking it was the host.

Particularly in the Macintosh OS and particularly in earlier versions of OS X, a process called byte range locking would also interfere with the proper usage of the file.

So the answer to you question is this:

If FileMaker Pro opened the file thru the File-->Open Remote the Status(CurrentUserCount) function of the calculation engine kept track of how many users there were. And a certain limited number of sockets (IIRC 204 to be precise) were available for peer to peer hosting. These got used up rather quickly.

OTOH, if attempts were made to open the file via the OS level sharing several times over, FileMaker Pro had no idea how many guests or hosts there were, who had locking, or who owned the file. And therein was the source of untold misery and unbelievable file corruption.

In FileMaker Pro 7, several changes were made to lessen the likelihood of file damage.

So, my "...blowing a fuse..." was to prevent your blowing up your file.

Upgrade to FileMaker Pro 8.5.

Steven

Link to comment
Share on other sites

This topic is 6444 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.