FileMaker Server and FileMaker Pro on same server problem

[Matt Klein]

Hi All -

I know that the general rule of thumb is to NOT run the FileMaker Pro client on the same server as Filemaker Server. We sort of break this rule by installing FileMaker Pro Advanced on our client's servers and use it only for support. No regular/normal use on the server.

As of FileMaker Server 11, we skipped over Server 10, I am noticing a pretty annoying problem that is becoming a great inconvenience to our clients. I thought it was isolated to our Mac installs, but has now shown it's face on several of our Windows Server installs.

The problem is that if we try to open our app in FMPA, on the server that is hosting the files, via our startup file, we get a message that the files can't found even though the files are clearly open and hosted by Server and the other workstations have no problem finding the files.

A restart of the server clears that problem up. However, this is a major inconvenience for our clients as they all have to exit an app that, to them, is running just fine. I have not been able to find a solution to this with out having to get the clients out of the app.

Does anyone know what causes this and if there is a way to remedy it when it happens without booting clients?

[Steven H. Blackwell]

The problem is that if we try to open our app in FMPA, on the server that is hosting the files, via our startup file, we get a message that the files can't found even though the files are clearly open and hosted by Server and the other workstations have no problem finding the files.

Does anyone know what causes this and if there is a way to remedy it when it happens without booting clients?

Yes, FMP is having trouble with the file references since both are running on the same machine. This has happened in prior versions, and it continues to happen today.

Steven

[Matt Klein]

Thanks Steven. Do you have any idea why it is remedied by a simple restart of the server or why it works for a while and then stops working?

[Steven H. Blackwell]

Thanks Steven. Do you have any idea why it is remedied by a simple restart of the server or why it works for a while and then stops working?

Sorry, no. This has been on my list of things to test and to work on for a while, but other items, namely client projects, intervened.

Steven

[Simon Brown]

A similar (same?) issue occurred to me as well on some WS 2008 based systems (has not occurred for me on OSX). The initially selected file opens fine, but any FMP datasources on the same server can't be found.

What worked for me was adding a hosts entry for the hostname as used in the data source (I think the path is something like C:WindowsSystem32driversetchosts). There seems to be something odd about how the data source host names are resolved by FMP, and this fixed it for me.

Simon

[Matt Klein]

A similar (same?) issue occurred to me as well on some WS 2008 based systems (has not occurred for me on OSX). The initially selected file opens fine, but any FMP datasources on the same server can't be found.

What worked for me was adding a hosts entry for the hostname as used in the data source (I think the path is something like C:WindowsSystem32driversetchosts). There seems to be something odd about how the data source host names are resolved by FMP, and this fixed it for me.

Simon

Hi Simon -

Thanks for the feedback. We use the wildcard in the fmnet: reference. So, our file reference looks like this : fmnet:/*/FileName.fp7. If I am reading your solution correctly, it requires that an actual host name be used. So, it would something like: fmnet:/FMServer/FileName.fp7.

Am I correct or is there an entry to be made in the "hosts" file that takes care of the "*"?

[IdealData]

fmnet:/*/FileName.fp7

Why are using the wildcard in the file reference? The correct format is:

fmnet:/hostIPAddress/filename

the "*" cannot resolve anything.

As this is obviously a solution for many different clients then you will need to manually configure the fmnet: reference to the IP address of the FM Server in that particular location.

If any client has a DNS server available then you could try using a common fmnet: reference and provide a domain name for to resolve the IP address.

The "hosts" file allows the local machine to do IP address resolution before looking for DNS, but this would be undesirable as all ( * ) references would be redirected back to the local machine. You could use the "hosts" file to perform DNS for a domain - but you must still correct the fmnet: reference in the first instance - thus the "hosts" file is redundant for your purpose.

[Matt Klein]

the "*" cannot resolve anything.

Actually, that is not true. The wildcard("*") actually dynamically checks the subnet for FileMaker Server instances. This is very convenient for our multi client solution and it works for all of our clients except those who have their server on a different subnet from the workstations.

[Wim Decorte]

The "*" is totally unnecessary and comes from the fp5 days. In Matt's example, even with the server on a different subnet than the workstations, then all file references inside the solution would be simple "file:myfile.fp7" references.

You only need fmnet references for:

- any starter/launcher files that live on the workstations

- any references in your solutions to files that live on a different FMS box (if your solution is spread over more than 1 FMS installation)

But even then you would not use a "*" but either the DNS name or the IP address of the targeted FMS box

[Matt Klein]

Wim...thanks for the tip about the not needing the fmnet references inside hosted files. I always assumed that you needed to have the fmnet reference for hosted files. That's a great bit of info and I appreciate it.

Regarding the use of "*"....you guys seem pretty dead set against it. It may not have a broad based use to it, but in our situation, where we have a vertical market product that gets installed at many locations and we have a local GUI file, it is much easier and useful for us to reference the hosted files via the fmnet reference using the "*". This works perfectly for all of our clients that have their server on the same subnet as the workstations which comprises the vast majority of our clients. We do have a very small number of clients where we do have to replace the "*" with the DNS or IP address.

I actually agree that the best practice is to not use the "*". In our situation it actually works out better than referencing the DNS or IP Address of the server hoping that the client's IT folks never change the DNS name or IP Address of the server.

Thanks again Wim. Your tip actually will save us a bunch of time when we do run into a client that requires us to enter the DNS name or IP Address of the server into the references. Previously, we would change the references in all files of the solution. Now, I know that we can remove the fmnet references entirely from the hosted files and only have fmnet references in our startup and GUI files.