There are at least two options I can think of right away:
1) Make your iPad database local only (no continuous connection to Server) with a sync / upload component. That is, when needed, the user taps a button that initiates a server connection, performs the data update / transfer, and then disconnects.
2) Use Custom Web Publishing to convert the "always on" application into a web page. By nature, web pages (without extra help) are stateless and do not require constant communication with the host.
I'd avoid peer-to-peer hosting. It's inherently less stable, less secure, and more error-prone than Server, and more likely to damage your database.
I've attached a copy of a white paper on sync strategies for your review.
FMI_Sync_Guide_EN_Oct_2012.pdf 930.1 K
You turned off reauthenticate? That should be on. It won't keep you from getting disconnected but it will make logging in much easier, especially with a high setting (fmreauthenticate10080).
I don't think this is a Server issue. The error message you're getting suggests network hiccups.
FMP likes an "open line" to its host. If the wifi goes down for 20 seconds, or the server takes a nap, or you switch apps, then FM will disconnect.
1 of 1 people found this helpful
I haven't tried this, but perhaps a an OnTimer script would stop the server from disconnecting you. (as long as the interval is less than the server timeout!!)
I guess I would have to go with Option 1, since I still want the ease of use for capturing pictures and signatures.
Thank you for the white paper and the suggestion.
Ok, I turned fmreauthenticate back on.
It could be network hiccups. Thanks for the idea
I do have an OnTimerScript, which all it does is take the file to a comepletely black layout (to prevent image/screen burning), but I think it gets uninstalled as soon as it gets to the layout. So I guess I could try one that runs continuously.
One thing that I've done in dealing with network hiccups is to create an opener file that runs as an OnTimer script. Every so often, it checks to see if the hosted file is open. If not, it opens it.
However, one weakness of that approach is that it depends on the user acknowledging the "disconnected" dialog. Might not be a huge issue in this case, but since that dialog hijacks the client, it'll stop the OnTimer script from processing.
Just a thought.
I don't think this is a server issue. It is probably an iPad issue or WiFi issue. Here are a couple of things to look at:
1. There is definitely a correlation beween how long it has been since the iPad was restarted and the number of problems you experience with FM Go. Suspect that FM Go has some memory management issues.
2. Is the iPad mobile? If yes, you might be experiencing WiFi drops. I'm assuming you are using WiFi. If you are using a cellular network then all bets are off. I would not trust a cellular network to maintain a consistent connection
3. FMGo should try to reconnect when it gets disconnected but there is a huge gotcha. If you have an uncommitted record you will end up in a revert from hell loop. Try to minimize any uncommitted records.
I initially thought the iPad going to sleep was the cause of these problems, but i could not confirm this through testing. If everythihg is working the way it should the iPad should just reconnect with no problem when it wakes. I think what you are seeing are network connection problems that occur during the sleep or just prior to sleep but were not a result of the iPad being asleep. So what happens is you might assume that the cause was the iPad sleeping since you can not reconnect when it wakes up.
The iPad does not move, and it is in a holder where none of the buttons can be pushed. (The worst that can happen is that it gets unplugged.) I put the iPad in kiosk mode so they can't touch things to even get out of the app. (like the top left and right areas).
It is connected by WiFi, not cellular, and it never goes to sleep.
It's new, not much is happening with it, and it is not that big, but it could be a memory management issue.
So it is probably a network hiccup issue, like other people have said.
It does try to reconnect, but gives that message before doing so.
Thanks for responding!
The log file can be a local file which eliminates the problem with the server. If needed you can push the data to the server as needed. Making the login file local solves your problem.
Login with this file and have buttons on it to open your server file.
You could pass the login info in the parameter of the script that opens on the server and save that to your server login in table and then open the appropriate script.
Perform script( On server; parameter $logindata; script to run after login recorded)