Clients listed twice with duplicate Databases

[steveald]

I am running FMS 10 with generally less than a dozen Clients connected, each running FMP 9, 10, or 11; and all running Mac OS X v.10.x (except one on Windows XP). Each Client usually has 18 databases open - 5 for regular use and 13 as hidden lookup files. This setup has slowly evolved over several years, so there is obviously some collateral code lingering around that is either untouched or slows things down unnecessarily.

That said, my issue is with most of my Clients showing up in the FMS Administration screen twice - once with all the open databases listed, and once with duplicates of a few of those databases. Which databases are duplicated appears to be related to which ones each Client uses frequently.

The problem it creates is that I run out of licenses. I am licensed for 15 FMP Clients and it only takes 8 Clients logged in to exceed that number when they are doubled up. For some reason this has only become an issue since we started trying to convert to FMP 11. I can't open our databases at all with my single license of FMPA 11 since it creates a second instance of me as a Client through routine use.

I can make the problem happen by starting up FMP and running the script that open all of our databases. One database immediately appears duplicated under a second instance of my Client entry in FMS. On my local computer, the duplicated database now shows up under Show Window with the database name in parentheses and no Server name shown (instead of seeing it listed by it's name with the Server name in parentheses, as is normally the case). When I try to select the hidden duplicated database under Show Window, it flashes on the screen and disappears. Then a second instance of the database appears - but in the format of (Server)-1. Then, when I attempt to view either instance of the duplicated database, they each appear normally.

Further, creating a new record in our primary database (the one with most of the Relationships to the hidden databases) results in a duplicated database in FMS; as does simply entering data in that database (triggering a lookup in one of the hidden databases).

Something else that has cropped up recently has to do with scripts that are set up to take data from a record in one database and create a new record in another database with that data. This has worked flawlessly until recently. Now, it results in a second instance of the target database opening (as if New Window were selected) and the new record with the transferred data appears there. This happens regularly now with one of the Mac's running FMP 10, as well as others.

I realize this is a lot of information, but I believe it is all somehow related. Any suggestions would be greatly appreciated. And more details can be provided, if necessary. Unfortunately, the ideal scenario of taking the whole system down and rebuilding it from the ground up is not possible - as it would require shutting down our business for the duration.

[Ocean West]

I am curious do the machines access via WIFI and Ethernet or have multiple NICs?

Edited June 2, 2010 by Guest

[bruceR]

This is almost certainly a file reference error. Look at all the file references (external data sources). For a served solution they must all be in the simple format and must include no IP addresses.

file:Contacts

NOT

fmnet:/111.222.33.44/Contacts

NOT

file:/somefolder/Contacts

[steveald]

Ocean West,

About half of the clients are on the same ethernet network as the server FMS is loaded on. The other half access the databases over the internet.

I forgot to mention before, all the remote clients show the same IP address (68...) for both Client entries in FMS, while all local clients show a local IP (192...) for the first Client entry and a remote IP (75...) for the duplicate entry.

[bruceR]

Ocean West,

About half of the clients are on the same ethernet network as the server FMS is loaded on. The other half access the databases over the internet.

I forgot to mention before, all the remote clients show the same IP address (68...) for both Client entries in FMS, while all local clients show a local IP (192...) for the first Client entry and a remote IP (75...) for the duplicate entry.

Not relevant.

Check the file references for each database.

[steveald]

BruceR,

As you'll see from my previous response, I have to use IP addresses for remote clients to access the databases (as far as I know).

I had recently acted on a suggestion that there were circular references between the databases causing the duplicate Client/Database entries (causing the problem with FMP 11), so I made sure all external data sources were in the format "fmnet:/66.xx.xxx.xx/filename". And, while there are a few instances of one database having a relationship established with another database (and, in one case, two databases), there are no instances of circular relationships established between any two databases.

One thing does come to mind though, while every client needs to be able to access every primary database - some remotely - the relationships between databases (a primary database needs to do a lookup on a hidden database) are all on one machine hosted in FMS. Am I looking at this wrong? If most clients don't actually need to see the hidden lookup databases, do these clients actually need to load the hidden databases for the relationships to work? Or is it sufficient for them to load the primary databases only. This would allow for a local file reference for these lookup databases. I would still need to be able to access all databases - including the hidden lookup databases - as needed, though.

Unfortunately, this probably won't address the duplicate client/database issue. I'm looking at the Administration screen now and all the duplicated databases one client has are the primary ones everyone needs to be able to access - including remotely. And that, I assume, means I need to use IP address-based external data sources.

Am I incorrect in this assumption?

Edited June 3, 2010 by Guest
Additional information added

[bruceR]

BruceR,

As you'll see from my previous response, I have to use IP addresses for remote clients to access the databases (as far as I know).

I had recently acted on a suggestion that there were circular references between the databases causing the duplicate Client/Database entries (causing the problem with FMP 11),

Am I incorrect in this assumption?

No. You are not correct.

Like I said - the location of your client machines is completely irrelevent..

Remove ALL the IP addresses and convert to simple file:filename format. The IP addresses very clearly CREATE the problem you are experiencing.

I connect to client systems all over the world, with multiple databases on a aingle server at the various locations. File references are always in the simple form and everything works without any of the problems you are experiencing.

Edited June 3, 2010 by Guest

[steveald]

I had seen something a while back that used the server's domain name instead of IP addresses. Is that what you are referring to? I need some way for remote clients to know where to find where the databases are hosted.

Thanks.

Edited June 3, 2010 by Guest

[bruceR]

I had seen something a while back that used the server's domain name instead of IP addresses. Is that what you are referring to? I need some way for remote clients to know where to find where the databases are hosted.

Thanks.

You are mixing up two completely different things.

All the files on your FileMaker Server must refer to each other using local simple external references.

A user running FileMaker and opening one of your databases must know the IP address of your server; or its domain name. How are your external users connecting - do you have a VPN or have you opened the required port in your firewall?

Edited June 3, 2010 by Guest

[bruceR]

I had seen something a while back that used the server's domain name instead of IP addresses. Is that what you are referring to? I need some way for remote clients to know where to find where the databases are hosted.

Thanks.

But they already know that!

They're connected!

That isn't the issue!

We are talking about changing the files themselves; going to each and every file and changing the external file references to the simple form.

[steveald]

My apologies. You are absolutely correct. I was mixing up two unrelated issues. The remote clients connect using a "launcher" database that consists of a single script containing Open File commands using the format of fmnet:/filemaker./. It used to have the actual IP address of the host server instead of the domain name, but I was told this was much more efficient. I believe the appropriate port was opened in the firewall.

That said, since all the databases are hosted on the same machine, I'll change all external data sources to the format file:filename.

Does it sound like it finally sank in? Thanks again.

Would I be correct in assuming the "launcher" databases (not hosted, everyone has their own copy on their computer) need to retain an external data source path containing either the domain.name or IP address format (preferably the domain.name format)?

Edited June 3, 2010 by Guest
additional question

[bruceR]

My apologies. You are absolutely correct. I was mixing up two unrelated issues. The remote clients connect using a "launcher" database that consists of a single script containing Open File commands using the format of fmnet:/filemaker./. It used to have the actual IP address of the host server instead of the domain name, but I was told this was much more efficient. I believe the appropriate port was opened in the firewall.

That said, since all the databases are hosted on the same machine, I'll change all external data sources to the format file:filename.

Does it sound like it finally sank in? Thanks again.

Would I be correct in assuming the "launcher" databases (not hosted, everyone has their own copy on their computer) need to retain an external data source path containing either the domain.name or IP address format (preferably the domain.name format)?

Whew!. Glad it sunk in, let us know the results. Right; if the file truly is "pointing somewhere else" then it needs to know the IP or domain address of the host it is pointing to. Of course now with FM11 you can use a snapshot link as a startup file. And you can also have and fmp7 link in an email or web page. fmp7://serverIP/main.fp7 works as a link on a web page.

[steveald]

I had a feeling that all those issues were related.

I am now running all of our databases successfully using my single license for FMPA 11, with no hangups so far. Everyone else that has quit and restarted FMP is only showing up once under Connected Clients in FMS 10. The data transfer script is no longer opening 2nd copies of the target database. The whole thing may even be working discernibly faster!

Thanks again.

One more question though. Since the lookup databases are accessed locally by the primary databases, do all of my clients need to open the lookup databases for everything to work? Or can they just open the primary databases and let the databases do their lookups locally as needed.

Edited June 3, 2010 by Guest
Additional question

[bruceR]

Any referenced databases will always be opened automatically and it is not necessary to open them ahead of time. This will usually happen when you go to a layout in file A that references data from file B; or a script in A that calls file B.

However, it is fairly common though to use a "home" file and have it use an opener script that opens files B, C, D, etc. Often these are set to open hidden. The opener script may also call startup scripts in B, C, D.

But maybe you should be specific about what you mean by "opened locally". My expectation would be that ALL files (except opener files) are on the server; is this the case?

Edited June 3, 2010 by Guest