mzarin

Hi Dan, I compared the before and after Mobile files and, apart from a new field, TO/relationship, and portal, the main differences I could find are in the Pull Payload script. Since my main concern is with pushing and not pulling, though, I'm wondering if the techniques you've used (which I haven't delved into yet) are likely to help there. Also, am I right in assuming that, since you only posted an updated Mobile file, no changes are needed in the Hosted file to accommodate your updates? Thanks again for giving me some leads! Mike

Hi Dan, Are you talking about the FM_Surveys_Mobile_v1r3_DSMOD.fmp12 file about which you said "DO NOT USE IT IN PRODUCTION" or the one at https://github.com/dansmith65/FileMaker-EasySync/tree/dev which you described as a work in progress? I'll be honest, I saw the thread you pointed to and got overwhelmed trying to figure out how it related to the v1.3 release, I was mostly happy to just get v1.3 working. Can you point to the relevant content in that thread that will get me started? Thanks! Mike

Hi all, I've successfully deployed EasySync 1.3 and we're happy, but we'd be even happier if the sync were quicker. Since this deployment is strictly pulling a small data set and pushing a bunch of images, the suggestions elsewhere on this forum about using Javascript in a web viewer to do some processing don't apply, I'm pretty sure. By tweaking the "$$max_push_segment_size" client setting I was able to speed things up by ~25%, but my test data of 27 images still took ~9 minutes to upload. Does anyone have additional suggestions to speed things up? Thanks, Mike

I have the same need/feature request as Skin the Cat, can't wait to see what features you're coming out with for "Diff-ing." Mike

What I'm saying is, even when I know for a fact that a person (e.g. "Kong") has a Reg record, FM is not find the Reg. record when I search on that person's name. Any suggestions on how to narrow down what's wrong or fix the problem, short of rebuilding the Reg. file from scratch? -Mike

Hi Ernst and Anatoli, I wish it were that simple! No, the relationship goes from data field to data field (both of type = number), with no calculations involved. And the problem is, I _know_ Regs exist for Kong. Some results from testing: - Creating a fresh version of the relationship in my Regs file doesn't work. - Putting related fields on a fresh layout doesn't work. - I can create a brand new file, relate it to Person via PersonID, and the search-across-relationship works in the new file. -mz

I'm working on a system with lots of files, relationships, etc. but am stuck on one interaction in particular. Parent file (People) and child file (Registrations) related by PersonID. Users can see related parent data from the child records, but searches on those parent fields are failing. For example, user wants to search for all Reg. records for person with last name "Kong" from a form layout showing data from People|PersonID::name_last. User knows there are plenty of "Kong" Reg. records, in fact they're looking at one right now, say. Result: No records found. User can go to People file and successfully search for last name = "Kong". But not from Reg. Any idea what's going on, or how to fix this? -mz

Success!! All I did was change the field definition for the Number field from type=number to type=text. That was all it took. All the data stayed exactly the same. I was expecting FM to remove all the zero's as part of the field type conversion, which is why I didn't try that earlier. It makes no sense to me why this would work when all the NumToText and export stuff didn't, but there you are. -Mike

Unfortunately, I'm looking at a solution where the field has already been defined as type = number w/ ~30,000 records worth of data, or I'd definitely go with type=text. And the solution of making a number_text_format field w/ calc (text result) = NumToText (number_number_format) strips off the initial zeros. Nice try, though. -Mike

I there any way to have FM calculate the length of a number field that will also count any leading zero digits? Examples of what I'd like results to look like: Number field data: 0012345 w/ length = 7 Number field data: 012345 w/ length = 6 What comes out instead: Number field data: 0012345 w/ length = 5 Number field data: 012345 w/ length = 5 I've tried Length(NumToText(number_field)) and various permutations but can't seem to do this. Even exporting the data to a text (comma delimited, e.g.) file didn't work, as FM stripped the zeros during the export. I suspect this can't be done, but thought I'd check w/ y'all before giving up. -Mike