4 Replies Latest reply on Aug 2, 2013 8:02 AM by mclasen@mclasen.com

    Issue with errant network at Client


      Here is the comment from their IT staff. Your comments are appreciated.I'm especially skeptical of their assessment of Filemaker Go

      You input is appreciated.


      The issue Julia is mentioning is a cosmetic bug in iOS. It is not actually connected to or trying to connect to SG3371. We have confirmed by checking IP addresses and other network settings that the device is connected to UCSF-Clinical. Even if it were the case, both wireless SSIDs are served through the same wireless access points so if SG3371 is online and reachable by a device then UCSF-Clinical is online and reachable. But that is not the case, because SG3371 uses a different authentication protocol and source of authority, so it is impossible for Julia’s device to connect to the network.

      This error only ever shows up on iOS devices and never on PCs, Macs, or Android devices. It is separate from the issue of losing data in FileMaker Go, which we believe is due to the way FileMaker Go writes data to the server. In a typical app that relies on wireless connectivity, the app will establish a connection to a server and use a local buffer for storing user-entered data which is flushed to the server at a regular interval. FileMaker Go appears to do two things badly: first, it does not periodically flush to the server and instead only flushes the data when the user is completely done entering it; two, it makes only one attempt to write to the server and does not retain the local buffer until it has confirmed the server received the data. This is an example of bad coding by FileMaker and does not have any bearing on the wireless network.

      The problem comes down to one of three things: a bug in iOS that we can’t fix and have no control over, a bug in FileMaker Go that we can’t fix and have no control over, or the wireless network that we have had outside consultants design, map, and validate. We are confident that it is not the network.



      here is the original problem


      My client is a big hospital and are using iPads to make their rounds. The iPad keeps switching to a "test" network set up by the Hospital IT staff rather than the Clinical WiFi network it needs to be connected to. They are unable to select Forget Network in the settings. Any suggestions would be helpful.



        • 1. Re: Issue with errant network at Client

          Well, the assessment of Go is basically ... wrong.


          If your issue is that users are losing data because the iOS device is switching networks (and therefore losing connection to the server), that has to do with the client-server nature of FileMaker in general, and specifically the local cache / record commit behavior of databases (not specifically FileMaker, but databases in general). Once a record is locked by a user, the changes remain local until the record is committed, at which point they're written back to the server. There is no "periodic flush" to the server. To do so would risk leaving the records in a partially-edited state with potentially disastrous results.


          If your network is wonky, you basically have two choices:


          1) Run an OnTimer script trigger that forces commits on some regular frequency. Risky, because you may end up with users committing changes they really didn't want to commit, and, if you have a lot of users, you may wind up with another user jumping on top of the record before the first user can open it back up again.


          2) Move away from a network-connected model and move to a mobile-with-sync model instead. This would allow you to have the staff walking around with their iPads without relying on the flaky network. Of course, it involves a significant investment in coding and reconfiguration.


          In the meantime, I suggest you train users to commit records on a regular basis by tapping outside all fields as soon as they are done entering data to minimize the issue.





          • 2. Re: Issue with errant network at Client

            Or using "edit record" & "cancel / save" buttons and blocking normal browse mode entry on your main layout (making a separate layout for data entry). I use this in addition to mike's #1 point above, except REVERT the record and return the user with a dialog that their changes were not saved.

            • 3. Re: Issue with errant network at Client

              The transactional model is a good thing. Just be aware that, if the connection drops while the record is open, the user will still lose their edits when Go terminates the connection (and closes the database). So it may not really solve the problem (assuming I'm reading the OP correctly).


              I tend to lean in the direction of local-with-sync for that reason in these sorts of situations.


              Just my $0.02.



              • 4. Re: Issue with errant network at Client

                Thanks for your comments, they have proved useful. Yesterday I found out that the problem can be solved by loggi g in and "forgetting" the bad network. I'm sugghesting thjey make the test network hidden so in low accvess artes as they move to new rooms they can easily reconnect. We are also looking in Sync solutions.