three server issues for a new user of Filemaker server

[jjjjp]

I have developed a database that, PM, the IT person at the college where I teach has finally mounted on our server. He is generally very knowledgeable about IT matters but is a relative neophyte as far as Filemaker goes. I know very little about Filemaker server and don't have any direct access to the server in any case. PM person created a rudimentary arrangement for me to upload and download files to and from the server, so that I can import data into the copy of the database that I develop on my own computer before putting it back up on the server.

I have three questions. I would be very grateful for any insight:

(1) Since going up on the server I and other users have experienced frequent disconnects. Am I right in assuming that this wouldn't be a problem with Filemaker Server but with the college server (which is new and may have some glitches that still need to be worked out)? Or can the settings on Filemaker Server be causing the frequent disconnects? Is there a simple way to find out who is the culprit? PM thought he resolved the issue at the level of the server a couple of days ago but it is back in full force.

(2) When I ask the file to close and download (via a non-Filemaker script that PM created) and there are users logged into the database who do not heed the warning to log out within X number of minutes, the file becomes damaged. Is there a way to close a file that either doesn't complete if users don't log out on time, or terminates their sessions in a more gentle manner.

(3) I have discovered that when a user gets disconnected while paused in a script, the program (if I understand this correctly) in effect keeps doing a Continue until the scripts are over. I believe that something similar must happen following a Force Quit. (I have Allow User Abort set to Off for all of my scripts, so I was kind of expecting the file to get damaged in both situations. I imagine a file will become damaged if you pull the plug on one of the computers, but I haven't worked up the nerve to test this out on a dummy file.) Does this mean that I must now go back to all of my scripts and program them to exit the program in a proper manner if the program tries to disconnect from outside? Generally, I set a global field to a text message via a button when I want to resume a script, and there is usually a "cancel" option, so I guess I would set the global field to "cancel" just before the Pause step. Still, a lot of code to comb over, so I want to be sure I am doing this right.

Thanks in advance for any help.

Jerry

[Vaughan]

This is the worst way to share a FMP database. I had to stop reading after point 1 it was so painful.

Get FM Server. Get somebody to set it up if you don't know how yourself. FMS is good and easy.

[Wim Decorte]

PM person created a rudimentary arrangement for me to upload and download files to and from the server, so that I can import data into the copy of the database that I develop on my own computer before putting it back up on the server.

Big problem! There is no such thing as an "arrangement" to upload and download files. Uploading can be done through the FMS admin console, downloading can't be done.

What you describe means that the PM guy enabled OS-level file sharing on the hosted files and that WILL corrupt your files. Keep good backups until this is solved!!

(1) Since going up on the server I and other users have experienced frequent disconnects. Am I right in assuming that this wouldn't be a problem with Filemaker Server but with the college server (which is new and may have some glitches that still need to be worked out)? Or can the settings on Filemaker Server be causing the frequent disconnects? Is there a simple way to find out who is the culprit? PM thought he resolved the issue at the level of the server a couple of days ago but it is back in full force.

As per above, the FMS box is not set up correctly, disable the OS-level file sharing on the files. You and any other guests should only access the files through the File -->> Open Remote mechanism

(2) When I ask the file to close and download (via a non-Filemaker script that PM created) and there are users logged into the database who do not heed the warning to log out within X number of minutes, the file becomes damaged. Is there a way to close a file that either doesn't complete if users don't log out on time, or terminates their sessions in a more gentle manner.

Totally expected given your current setup. You should only close the files through the admin console or through the command line interface on the server itself, wait for confirmation that the file is closed properly and then move the file somewhere.

That means waiting for ALL clients to disconnect properly.

If you want to automate the closing of a file, check out the VBscript on my website and adapt it to your needs: http://www.connectingdata.com/downloads

(3) I have discovered that when a user gets disconnected while paused in a script, the program (if I understand this correctly) in effect keeps doing a Continue until the scripts are over. I believe that something similar must happen following a Force Quit. (I have Allow User Abort set to Off for all of my scripts, so I was kind of expecting the file to get damaged in both situations. I imagine a file will become damaged if you pull the plug on one of the computers, but I haven't worked up the nerve to test this out on a dummy file.) Does this mean that I must now go back to all of my scripts and program them to exit the program in a proper manner if the program tries to disconnect from outside? Generally, I set a global field to a text message via a button when I want to resume a script, and there is usually a "cancel" option, so I guess I would set the global field to "cancel" just before the Pause step. Still, a lot of code to comb over, so I want to be sure I am doing this right.

The hosted files will typically not get damaged if a client loses or force quits its connection. The damage you are seeing comes from the bad FMS deployment, not from anything the clients are doing.

While the file may not get damaged from what the clients do, it will almost certainly wreck havoc on your data integrity (incomplete records, aborted processing,...) so it's not a good thing.

Fix the deployment, follow best practices and then we can work out how to do what you need done.

[jjjjp]

This is the worst way to share a FMP database. I had to stop reading after point 1 it was so painful.

Get FM Server. Get somebody to set it up if you don't know how yourself. FMS is good and easy.

Sorry if I was unclear, but it is being hosted on FM Server.

[jjjjp]

What you describe means that the PM guy enabled OS-level file sharing on the hosted files and that WILL corrupt your files. Keep good backups until this is solved!!

Thanks so much. I will test this out ASAP. The file that always goes back up on the server is one that I develop locally, and I usually have Network Sharing set to On in Sharing->Filemaker Network Settings under the File menu. Do I need to remember to change this manually to Off each time before it goes up on the server? Or are you saying that the proper setting in the FMS server box will override whatever the setting is in the original file?

If you want to automate the closing of a file, check out the VBscript on my website and adapt it to your needs: http://www.connectingdata.com/downloads

I will ask my IT person, PM, to check these scripts out. Right now I don't have access to the console. Only he does.

[Vaughan]

The file that always goes back up on the server is one that I develop locally, and I usually have Network Sharing set to On in Sharing->Filemaker Network Settings under the File menu. Do I need to remember to change this manually to Off each time before it goes up on the server? Or are you saying that the proper setting in the FMS server box will override whatever the setting is in the original file?

No, this setting is not relevant to this issue. You need to manage your version control differently.

Rather ironically, the procedure you're currently using is orders of magnitude riskier than doing direct development on the production file.

Firstly, get the file sharing removed from the FMS Data folder. Maybe leave it on the backups folder, but definitely remove it from the live hosted files. Nothing and nobody should be touching the hosted files, ever, except FMS itself.

Secondly, get the FMS remote administration tool working and use it to disconnect users, close and open databases and upload new files to the server. It ensures the file permissions are set correctly. This runs from your local machine so you don't need access to the console.

Lastly, read up on the FMS best practices. The fact that your IT person knows nothing about FMP and FMS is a real worry. Make sure that anti-virus and disk indexing software isn't touching the hosted FMP files.

I'd also be concerned that your current databases are already harbouring corruption. Save compressed copies and run the consistency check on them, and consider re-building those that have problems.

[jjjjp]

Thank you very much for your suggestions.

Lastly, read up on the FMS best practices. The fact that your IT person knows nothing about FMP and FMS is a real worry. Make sure that anti-virus and disk indexing software isn't touching the hosted FMP files.

In fairness to my IT person, he insisted that I explore hosting the site at another college where the IT person was an experienced FMServer user. When that fell through, he reluctantly agreed to take on the responsibility of hosting the database on our new server, which was a considerable favour to me, his FM inexperience notwithstanding. The options were very limited.

I'd also be concerned that your current databases are already harbouring corruption. Save compressed copies and run the consistency check on them, and consider re-building those that have problems.

I ran the check, and the file is harbouring corruption. I went back to a version prior to these server issues, and there was also a problem with it, though there appear to be far fewer than with the file that has sustained multiple interruptions on the server. I don't know how long the earlier file has been harbouring corruption, possibly a long time. I have had no problem with how it has functioned, so I never suspected it might be corrupt, but I will plan to check for consistency regularly going forward. I get a message, however, that I should not use the recovered file going forward. There is one bad block. I don't have a clue how to rebuild the file based on the somewhat cryptic (to my eyes) error codes and messages.

I am attaching relevant files and messages for the earlier version. Anyone can log in as guest1; password is also guest1. Basing the latest file on this one will be no problem; the new data can even be entered manually. If the attached files provide obvious clues to someone with experience, please let me know if there is a straightforward way forward. If you can point me to relevant online help, that would also help.

recovery guest1.zip

[jjjjp]

Vaughan and Wim Decorte, I passed your suggestions on to my IT person, and he insists that "OS level file share is not being used on live copies and all open and close statements are being done using the filemaker command line." So the problem must lie elsewhere. Does this eliminate the setup on FM Server as the cause of frequent interruptions, or could there be something else FM-related? If the former, I guess I must leave it to PM to investigate this once more from the perspective of the server and networking.

Agreed that the "close and download" script is still problematic in that it could bump a user who doesn't log out in the time buffer he provides. (Right now I go into the file beforehand and check number of users, but I could forget, or someone could log on before I manage to execute the script.) PM will work on making the script less risk prone (e.g., by not closing if not everyone logs out within the buffer), and he will work on getting the remote administration tool working. He said that when he tried, the reference to the installer didn't yield up the promised file.

I'd also be concerned that your current databases are already harbouring corruption. Save compressed copies and run the consistency check on them, and consider re-building those that have problems.

I think I'm starting to get this, but I want to make sure I have it right. I don't actually need to decipher the codes in the consistency check, just observe whether there are any non-zero error codes. Then I save as compacted, and then? Run recover on the compacted file, import all of the tables from the recovered file into my potentially compromised file, and see if the file works and I get no more errors when I run another consistency check? Or is there something else I need to do as well?

I don't quite understand what the compacted folder is all about (nor does the FM help file try to explain), and I notice that the Save as Compacted takes about a second rather than overnight, but there are some things I am willing to take on faith! Still, is there any chance this procedure will mess up my file, which at least now works??

[Vaughan]

If a file is corrupted and saving a compressed copy doesn't resolve the issue, then either import the data into a known-good backup, or re-build the file.

Copying and pasting objects between the old and new files can speed the development, but it also risks introducing the corruption back into the new file.

The Save a Compressed copy command basically re-builds a new file on disk from the old file, rather than just blindly copying it.

[Wim Decorte]

he will work on getting the remote administration tool working. He said that when he tried, the reference to the installer didn't yield up the promised file.

There is no installer for the remote admin tool. You get to the start page by using the browser to go to http://<theFMSserverDNSnameOrIPaddress>:16000

and from there you run the admin tool. After you run it the first time it will create a shortcut for you.

[jjjjp]

If a file is corrupted and saving a compressed copy doesn't resolve the issue, then either import the data into a known-good backup, or re-build the file.

I believe compressing resolved the issue. Or at least no issues on the consistency check. But is one supposed to check just for consistency or also do a recovery and see if any problems were noted? There seemed to be one problem for me at that second level (attached). Do I need to import data from the recovered file into the file I started out with?

And can you explain what you mean by rebuild?

Thanks!

Archive.zip

[jjjjp]

There is no installer for the remote admin tool. You get to the start page by using the browser to go to http://<theFMSserverDNSnameOrIPaddress>:16000

and from there you run the admin tool. After you run it the first time it will create a shortcut for you.

Thanks very much. I have passed this on to my IT support. Since the page doesn't load, he'll no doubt need to do some groundwork on permissions.

[jjjjp]

I see now from FM Help that recovery is not advised unless the file won't open, so I think I'm OK now. Thanks again, both, for your help.

[Steven H. Blackwell]

I see now from FM Help that recovery is not advised unless the file won't open, so I think I'm OK now. Thanks again, both, for your help.

You might want to take a look at the White Paper on File Recovery on the FMI web site. It explains the process and what happens at each of the 16 stages of recovery. Please do overlook the author's idiosyncratic musings.

Steven

[jjjjp]

You might want to take a look at the White Paper on File Recovery on the FMI web site. It explains the process and what happens at each of the 16 stages of recovery. Please do overlook the author's idiosyncratic musings.

Steven

Sorry, I'm not sure where to find this. I don't know what the I in FMI stands for. Is there a url I can go to? My file is now perfectly fine but I'd like this for future reference. Thanks.

[Vaughan]

FMI = FileMaker Inc. It's the mother ship.