1 2 Previous Next 15 Replies Latest reply on Jun 22, 2015 11:20 AM by rouelf_1

    Persistent ID - hit or miss

    vtdonn

      Title

      Persistent ID - hit or miss

      Post

      Before we deploy a solution we send clients a file (we call it the "initialization" file) that they open in FM Go and press a button that uses the Get (PersistentID) function. This populates a field with that value, and then the solution is emailed back to us. Here is the language we use to get their device ID-

      Set Variable [$id; Value:Get(PersistentID)]

      Set Field [PrefPersistentID; $id]

      This gives us a value of "13CBFB663FCC4948857D9E7E6A2D5BBF", for instance.

      That's it. PrefPersistentID is surfaced on the interface, and we simply open the file that is returned to us, copy/paste that value into their actual solution so their solution can only be opened on their device(s). The startup script simply checks device ID against a list of approved device IDs, as follows:

       

      Set Variable [$id; Value:Get(PersistentID)]

      Set Field [PrefPersistentID; $id]

      If[PrefPersistentID ≠ "13CBFB663FCC4948857D9E7E6A2D5BBF"

      Show Custom Dialog ["Incompatible Device"; "Software is not authorized for use on this device"]

      Close File [Current File]

       

      The problem is that it doesn't always work. Just yesterday I sent the initialization file to a client and they ran it on two devices. I delivered their solution with those IDs plugged in, and the solution opens on one device but not the other. Same thing happened last week- two devices were defined, and the solution only opens on one of the devices. PrefPersistentID is formatted as a text field. We were thinking it may have to do with "0" versus "O" in the IDs or something along those lines but cannot see any patterns.

      Does anyone know of any pitfalls to look out for when using the Get(PersistentID) function? I have a feeling there is some limitation that we aren't aware of. Or might there be a better way to prevent sharing their solution with unauthorized devices? As is often the case, folks have often figured out more elegant ways to solve problems than what we've thought of. So if anyone has suggestions, please share.  Thanks-

        • 1. Re: Persistent ID - hit or miss
          schamblee

          Make sure the user has the most current version of FMGo.  There were some issue in older versions of FMGo.   

          If the user reinstalls FMGo then the PersistentID can change.

          • 2. Re: Persistent ID - hit or miss
            vtdonn

            Thanks. I've asked for them to send their iOS and FMGo version numbers so we can look into that.

            Unfortunately, in FMGo14, behaviors changed in terms of tab ordering in our solution and we haven't reconfigured yet- we have to incorporate a new script to force tabbing behavior, and also switch to Drop Down Lists from Popup Menus- which really stinks, so we are on the fence about how to deal with that. As such, we've asked clients to hold off on upgrading to 14.

            • 3. Re: Persistent ID - hit or miss
              TSGal

              Donn Downey:

              Thank you for your post.

              Find out what value is being returned for Get(PersistentID) on that device.  FileMaker Go is using the MD5 value, and I know of one instance where a customer returned D41D8CD98F00B204E9800998ECF8427E, which is the MD5 value of nothing.  This would occur if the system was blocking FileMaker Go from obtaining this value, or possibly the queried information was not passed to FileMaker Go in time.

              TSGal
              FileMaker, Inc.

              • 4. Re: Persistent ID - hit or miss
                vtdonn

                In one case, the value from the successful device was "04B71CF344994D31BD22E29BB72CF664". The value from the unsuccessful device was "13CBFB663FCC4948857D9E7E6A2D5BBF".

                 

                • 5. Re: Persistent ID - hit or miss
                  schamblee

                  Here is more information persistentID.  Some issues dealing with different version of ios and fmgo  http://help.filemaker.com/app/answers/detail/a_id/12074/~/behavior-differences-of-get-%28persistentid%29-and-get-%28systemnicaddress%29-when-used

                  • 6. Re: Persistent ID - hit or miss
                    TSGal

                    Donn Downey:

                    What other values have you received from the unsuccessful device?


                    Stacy Chamblee:

                    Thank you for the link.  Knowledge Base Article #12074 does say that Get (PersistenID) can return incorrect values, but as the article points out, this was resolved in FileMaker 12.0v8.


                    TSGal
                    FileMaker, Inc.

                    • 7. Re: Persistent ID - hit or miss
                      schamblee

                      TSGAL

                      Yes, I read that those issue had been fixed in 12.0.8 but the version of FMGo or ios was not given in the post, so if it they are using older versions of the software then they will have issues.    I have clients using old software all the time.  I just had a customer to purchase software and he was still running Windows ME.  

                      • 8. Re: Persistent ID - hit or miss
                        philmodjunk

                        Also, have the user restart FM GO when the experience this issue.

                        The code I see here seems to have a number of unnecessary steps and is implemented in a fashion that could create upgrade nightmares for you should you need to deploy an updated copy of the file to your users in the future.

                        Don't see a need to set a variable to the value, then set a field to the value before comparing the ID to validate the current device. You might add code to confirm that the field actually gets a value as the older FM GO versions have a bug that can keep a field from retaining a value. (This bug may exist in 14, but my "trap" script has yet to identify it--perhaps because I am not using FM GO 14 a lot just yet...)

                        And then put the ID into a field instead of as literal text! This field can be hidden from the user so that they can't change it, but with it in a field, you can deploy an updated version that imports the user's data--including the ID so that you don't have to individually update every user's copy of this file should you need to deploy an updated copy to them to fix issues or add new features.

                        • 9. Re: Persistent ID - hit or miss
                          vtdonn

                          Thanks Phil- I knew someone would have better ideas. Yes, we set a slew of variables in many of our scripts, so we're just in that habit even though we could just set the field in this case. Great idea about just using the ID value in a field rather than coding it in, but in the case of many users, would we need a field for each possible device or could we use a long text string to get all the IDs into one field?

                          As far as the main issue of the PersistentID not working... we are still waiting to hear back from the clients.

                          • 10. Re: Persistent ID - hit or miss
                            philmodjunk

                            One of my concerns here is that if this known issue that I obliquely referred to kicks in, fields can refuse to retain new data until you restart the FM GO app and this would prevent your code from checking the result of this function against a stored value.

                            My understanding was that each copy of your solution was enabled for only one device. If so, only one record and one field in that record is needed.

                            If you wanted one copy to allow usage on more than one device--such as a customer with both an iPhone and an iPad, you'd set up a table with one record for each device. Then you can use one of several methods to query that table for a matching ID value.

                            • 11. Re: Persistent ID - hit or miss
                              vtdonn

                              I hear you. It sounds as though in the situation you describe, they could restart FMGo and then it would work. It isn't as though the field value would disappear entirely, right?

                              And that makes sense to have a new table where each device ID was a record. Thanks again-

                              • 12. Re: Persistent ID - hit or miss
                                philmodjunk

                                It only affects changing the value of a field. So if you set a field to the value returned by Get ( PersistentID ), no value is actually set to the field. When you then compare the value of that field to the stored ID, they won't match.

                                But previously entered data is not affected.

                                I use this test in a script to check for the "bug state":

                                Show All Records
                                If [ not Get ( FoundCOunt )  // no records in table ]
                                   New Record/request
                                End If
                                If [ GetField ( GetFieldName ( Table::PrimaryKeyField ) ) ≠ Table::PrimaryKeyField ]
                                   Show Custom Dialog [ "bug!!! please restart FM GO..."]
                                End If

                                PrimaryKeyField should be a field that auto enters a value and thus is never empty. Indirectly referring to the value of the field should return the same value as directly referring to it, so this if function should never be true except when it's a bug.

                                • 13. Re: Persistent ID - hit or miss
                                  rouelf_1

                                  My two cents here: You can easily reduce management logistics, sending files back and forth.
                                  In your main FM solution, create a table with its layout (e.g. name: Protect, two fields: PID 1, and PID 2.  Create a script like below. Then Perform this Script at the beginning from the first script that runs when the solutions opens. Then just send the main solution with the PID fields empty. The two fields obviously are for using the solution in two devices.

                                  Script Name: CapturePID

                                  Allow User Abort [ Off ]
                                  Set Variable [ $Layout_Last; Value:Get ( LayoutName ) ]
                                  Go to Layout [ “Protect” (Protect) ]
                                  If [ Get ( TotalRecordCount ) < 1 ]
                                      New Record/Request
                                  End If
                                  Set Variable [ $PID; Value:Get ( PersistentID ) ]
                                  Set Variable [ $PID; Value:Left ( $PID ; 17 ) ]
                                  If [ Protect::PID 1 = $PID ]
                                      Go to Layout [ $Layout_Last ]
                                      Exit Script [ ]
                                  Else If [ IsEmpty ( Protect::PID 1 ) ]
                                      Set Field [ Protect::PID 1; $PID ]
                                      Go to Layout [ $Layout_Last ]
                                      Exit Script [ ]
                                  Else If [ Protect::PID 2 = $PID ]
                                      Go to Layout [ $Layout_Last ]
                                      Exit Script [ ]
                                  Else If [ IsEmpty ( Protect::PID 2 ) ]
                                      Set Field [ Protect::PID 2; $PID ]
                                      Go to Layout [ $Layout_Last ]
                                      Exit Script [ ]
                                  Else
                                      Show Custom Dialog [ Title: "To Many Machines"; Message: "Exceeded The 2
                                          Devices Allowed For Running This Application.";
                                          Default Button: “OK”, Commit: “Yes” ]
                                      If [ Get ( LastMessageChoice ) = 1 ]
                                          Exit Application
                                      End If
                                  End If

                                   

                                  • 14. Re: Persistent ID - hit or miss
                                    vtdonn

                                    Thanks rouelf. This is a clever idea when we are working with just a couple users that are likely sending it back and forth, but if we are distributing to more than a small handful it might not work all that well. The file would need to be sent through every device and opened in each as it gets passed along. Otherwise, when it is first distributed, each user could still send it to any number of their (unauthorized) friends, and if they are only using it on one device the available PID records would never be exceeded, or am I missing something here?

                                    Thankfully, we have found the solution. Instead of opening the clone that we sent, the users opened the file from their partner, who already ran it and then emailed it to them. As such, there were already records/values in the ID fields, and for whatever reason they weren't getting changed. We seem to be getting proper results now. Thanks to all-

                                    1 2 Previous Next