Hi Folks,

I'm having some issues in that the mobile file sometimes loses connection after the network check but before pushing/pulling table contents i.e during the pull metadata and settings / check GTRR portions of the scripts.

The Issue is that if connection is lost at this point we get "There was an error with the GTRR setup. Please take another look at the script \"Setup Go To Related Records (TOName)\"." error message. Now i realise that this can be caused and probably is by connecting over 3g / poor connection's ect.

The problem is that when the file is next synced it pull's down every record in every table regardless of whats already on the mobile file. However in our case we are syncing 40 tables and this full resync is 20,000 records. Is there a way of modifying it so that it doesn't have to do this full resync after the GTRR or if it must reset it only has to reset the first table it failed on.

i.e
pull metadata for TO 1 - OK
pull metadata for TO 2 - OK
pull metadata for TO 3 - Failed - error displayed and sync attempt halts
pull metadata for TO 4 - Not Run

Next time a sync is run.

pull metadata for TO 1 - OK
pull metadata for TO 2 - OK
pull metadata for TO 3 - Last run failed so full resync of this table is performed
pull metadata for TO 4 - OK

One explanation (maybe the only explanation) would be that the LastTimeZync field in the "TableOccurrences" record for that TO in GoZyncMobile is somehow being cleared (that's what would happen if you were to click the Reset button). I'm not sure why that would happen, but you can check the log for it after you have one of those interruptions (before the next sync). I assume this is only happening to iPad users? Can you reproduce it in your development files on your desktop?

Jeff

Hi Jeff,

This is happening on both ipad and desktop versions. from that i can see after this occurs instead of one record for each gzh_ and each gzm_ table the TableOccurrences table only has 1 record in it and that record has a fully qualified foreign key of ?::
This suggests to me that we are getting a partial query result back from the SQL query when the connection is getting interrupted. Which is meaning $CountOfTOs has a value of 1, This allows the Loop to run and marks one record in the TableOccurrences table, this will allow the section of the Pull Metadata and settings down from host script that removes records that weren't updated to delete them. This will then cause the "Connect TOs to sync engine" section to error.

the log shows

10/23/2013 8:13:09 AM - Started

Split Total
---------------------------------------------------------
0:00:00 - 0:00:00 - Connecting to server...
0:00:02 - 0:00:02 - Network Check complete
0:02:42 - 0:02:44 - On Connection from Mobile Complete
0:00:01 - 0:02:45 - Getting settings from Host...
0:00:00 - 0:02:45 - Selecting tables in GZH TOs Greater than 0
0:00:00 - 0:02:45 -
0:00:00 - 0:02:45 - Completed Record Marking
0:00:00 - 0:02:45 - Remove Records greater than 0
0:00:01 - 0:02:46 - Removed Records that were not updated
0:00:00 - 0:02:46 - Connecting ?

0:00:00 - 0:02:46 - problem connecting TO's to sync engine.
0:00:03 - 0:02:49 - There was an error with the GTRR setup. Please take another look at the script "Setup Go To Related Records (TOName)".

0:00:00 - 0:02:51 - All Done

Can you send me your files, along with full-access login information, and a detailed description of how I can reproduce this situation? Send the files to [email protected].

Hi Jeff,

Unfortunately due to the NDA we are working under with the client i can't send you the files, The issue is intermittent anyway and is not easily reproducible. I believe what is happening is that the connection is being interrupted during the sql query in the pull metadata and settings down from host script. This is causing the sql to return a single broken response which triggers the loop to mark records for deletion. Thereby causing the reset to occur.

I have added a check to the script which errors the script out an finishes the sync with an error if the $TO_Count variable is below a specified number. This will allow the sync to error out without reseting and force the user to rerun the sync again which should prevent it doing a full resync.

Sounds like a good solution. I'll leave the offer open to review your files if you'd like me to do that.