MAC network file path designation

[tomp]

I am setting up a shared-file solution for multiple user access at a site. When scripting the file 'open' step and specifying the network file path, can I us a 'set variable' step to define the path? Or does it have to be a fixed value? Since the solution will be deployed to multiple sites, the networks are unlikely to be set up identically.

[Vaughan]

I am setting up a shared-file solution for multiple user access at a site.

You're using FM Server, right? And not planning on putting the databases on a file share?

[tomp]

Does it make a difference? Some sites will have 2-3 users; other may have many more.

[Vaughan]

Indeed it makes a difference. FileMaker databases are NOT word processing documents. Putting them on a file share is a long way from optimal.

What "network file paths" are you exactly referring to?

[tomp]

In the script step 'Open File', when the 'Specify File'/'Add Filemaker Data Source' is chosen and the 'Remote' button is clicked, the 'Network File Path' is populated when the host/available file is chosen.

Can a variable, say $nfp, established in a 'set varibale' script step, be used as the 'Network File path' in the script step?

Such a technique works for exporting data and saving a file copy.

If not, and since the Network File Path will differ from company to company, how is this best managed?

[Wim Decorte]

Typicall all files are hosted on the same FileMaker server so there is no need for different file paths.

When you define your file reference just use "file:SomeFMfile.fp7".

This translates to: look for this file based on where I am. If the other file is hosted on the same server, it will find it.

[tomp]

I'm probably not making myself clear. I'll try again. I'm doing this in a 'shared file' environment - not FM server.

If I script the 'open file' step, and specify a remote file, I have to choose the host and file.

This results in a 'Network File Path' something like:

fmnet:/10.0.1.2/

The 10.0.1.2 is dependent on the configuration when I'm scripting the solution. When the solution is deployed to a user site, 10.0.1.2 is not likely (unless by chance) to be the host address. So an open error will occur.

How do I (or can I) prevent that error without having to re-script at the deployed site or not use the 'specify file' option in the script step (an unacceptable solution)?

How do I override the calculated value?

Or does FM server work differently and I can avoid the problem with FM server (don't have/haven't used Server before)?

[Wim Decorte]

You can't put a calc or variable in a file reference path.

So do yourself a favor and deploy filemaker server. It does away with this problem and makes your deployment "environment agnostic".

Plus, your current deployment is going to corrupt the files, it's just a matter of time. OS file sharing and filemaker sharing do not go well together.

[mweiss]

I may have misunderstood the OP, but I think he is talking about "sharing" using the built-in FM Network sharing, not OS-level sharing. This should not corrupt the file, as FM is written to provide this functionality natively. Deploying FM Server is expensive, and for many purposes is way overkill!

[Vaughan]

I'm doing this in a 'shared file' environment - not FM server

No, he's using OS file sharing.

[mweiss]

I'm still not sure. If my copy of FM Pro has an open database, and FM Network sharing is turned on, and other users can connect to my file, couldn't you call that a "shared file" environment?

I think we need the OP to clarify.

[Vaughan]

The database is on a file share. That is a shared file environment, yes, agreed.

That's BAD.

This shared file environment is different from a database hosted with FM Server or FMP as peer-to-peer. In both of these cases the users do NOT have direct access to the database files, they can only open them through FMP's open remote command.

BTW opening a database on a file share and sharing it peer-to-peer in FMP is very, very sub-optimal (and I am being very polite describing it). It may "work" and people often do it, but it is a real shame because they then think that all FMP database implementations are slow and unreliable.

FMP databases should never be on a file share. Never.

[tomp]

mweiss said:

"I'm still not sure. If my copy of FM Pro has an open database, and FM Network sharing is turned on, and other users can connect to my file, couldn't you call that a "shared file" environment?

I think we need the OP to clarify."

That's exactly what I'm doing.

Some of my installations will have just 2-3 users needing simultaneous access and the price tag for FM server is too high for them. They may have to endure sub-optimal performance

If I read the FM specs correctly, up to 7 users can share the file this way.

Am I running a risk of file corruption with this technique? The discussion is unclear to me.

If no risk of corruption, then it's still not clear to me how to handle scripting the 'open file/remote' where the file network path may differ between installations.

It looks like this will work: a 'front end' FM file installed on each user's computer with the sole function to open the remote database. A shortcut/alias to the file would be put on the user's desktop to launch FM and open the remote. This file would be customized for each installation and would be easily maintained should the network configuration change.

If there's a more elegant solution, I would be interested!

Please advise if the FM network sharing provides a higher risk of corruption than using FM server.

[Wim Decorte]

Am I running a risk of file corruption with this technique? The discussion is unclear to me.

Yes, if your files are in a folder that has OS sharing turned on (or one of its parent folders is shared).

If no risk of corruption, then it's still not clear to me how to handle scripting the 'open file/remote' where the file network path may differ between installations.

The only proper way to deploy non-FileMaker Server sharing/hosting is to have all the files together in one folder, on the machine that will act as a host. That host needs to have the files open before the guests can connect to it through "open remote".

The file references in the solution will just be

file:someFileName.fp7

There are no network paths involved here and there shouldn't.

So there is no adjusting required for the different deployments.

If you don't want users to have to manually click Open Remote then you can provide them with a launcher files.

The key is that the guests should not be able to locate the files except through "Open Remote".

If they can find them by browsing the network and using regular "file open" then that means that the files are in an OS-shared folder and that will lead to corruption.

[tomp]

good information. Thanks

[mweiss]

I'm sorry to stubbornly disagree with people much more experienced than I, but I think the question is still being misunderstood, and I believe the answer being given is wrong.

Look, consider this (hypothetical) situation:

I have a desktop computer in my office. On it is a copy of FMP (not FMS). On the hard drive of that computer there is a database ("Database Alpha") that is currently open. Filemaker sharing (not folder sharing or any OS-level sharing) is turned on. I access that database from my laptop using "Open Remote".

My colleague down the hall from me has a similar setup -- her desktop computer has a (completely different) database ("Database Beta") that she shares using FMP sharing, and accesses remotely from her laptop using "Open Remote".

This situation goes on for a while. Certainly there is no risk of file corruption yet, right?

Now it turns out that my colleague and I collaborate occasionally, so she decides to create an account in Database Beta for me, and I decide to create an account in Database Alpha for her. And to make things even easier I create a script inside Database Alpha that remotely opens Database Beta, and she creates a script inside Database Beta that remotely opens Database Alpha. (Sure, we could create a Launcher. But do we need one?)

So far everything is still great, right?

But we have two installations of FMP, on different computers, sharing files with each other. And if one of us moves our desktop computer to an office in a new building, they will even be on different network paths.

I think this is the kind of situation the OP is asking about. He never said ANYTHING about folder sharing or file sharing at the OS level, just that database files are being shared (which is, after all, exactly what the menu says: File > Sharing > Filemaker network...) on different computers with different network paths.

I can't see any reason why the above scenario requires FMS (as long as only 2 people are using the databases), or why the files need to be on a single computer, or why there is risk of corruption. Am I missing something?

Edited November 17, 2010 by Guest

[mweiss]

Just to be clear: The OP did not say he was using a file share. He said he was in a "shared file environment", which I think is a perfectly reasonable (if perhaps ambiguous) way of describing a situation in which Filemaker is sharing a file.

[Vaughan]

I'm probably not making myself clear. I'll try again. I'm doing this in a 'shared file' environment - not FM server.

The OP needs to define what they mean by "shared file environment". Specifically whether the database is on a hard disk local to the computer running FMP.

[Wim Decorte]

But we have two installations of FMP, on different computers, sharing files with each other. And if one of us moves our desktop computer to an office in a new building, they will even be on different network paths.

I think this is the kind of situation the OP is asking about. He never said ANYTHING about folder sharing or file sharing at the OS level, just that database files are being shared (which is, after all, exactly what the menu says: File > Sharing > Filemaker network...) on different computers with different network paths.

I can't see any reason why the above scenario requires FMS (as long as only 2 people are using the databases), or why the files need to be on a single computer, or why there is risk of corruption. Am I missing something?

As soon as you link the two files you have a functional solution.

I would say this is exactly the kind of situation that needs FMS. Having two different hosts for one solution is a potential nightmare.

- if you build your file reference using an IP address: desktops typically have dynamic IP addresses so they are likely to change

- if you build your file reference using a machine name, that can change when they decide to get a new desktop or move the files to another machine

- if either one is on holidays, away sick or just plain late, the linked file will not be open so you'd need a lot of unnecessary error trapping and handling in your solution to cater for that. The users would also need to quit out of the solution once the other person starts hosting to get the full functionality

- you will never be able to coordinate a backup that captures the solution state at any one moment

There's more but these are just what popped in my mind within 30 seconds of reading this...