Joshua Willing Halpern

  • Content count

  • Joined

  • Last visited

  • Days Won


Joshua Willing Halpern last won the day on September 14 2016

Joshua Willing Halpern had the most liked content!

Community Reputation

6 Neutral

About Joshua Willing Halpern

  • Rank

Profile Information

  • Gender
  • Location
    Los Angeles, CA
  • Interests
    Music, Filemaker, Cats, Dogs, and Estate Sales.

FIleMaker Profile

  • Profile Updated
  • FM Application
    14 Advanced
  • Platform
    Mac OS X El Capitan
  • Skill Level
  • Title
    Nice Person

Recent Profile Visitors

1,754 profile views
  1. Hey, try adding this line (including the quotation marks) at the end of your SQL statement: "AND ( \"_kf_uuid_companys\" = ? )" Please note the \" around the field name--You'll need these since your field starts with _. Then include $additional_settings as the argument in your ExecuteSQL calculation like so (See attached image). Alternatively you can embed the variable right in the SQL text: "AND ( \"_kf_uuid_companys\" = '" & $additional_settings & "' )" P.S. This doesn't matter at all, but I believe it's spelled companies.
  2. Hey, I want to create invoices with three different types of line items, 1) rental items, 2) people for hire, and 3) rental add-ons. Should I place all three in a single products table with extra child tables for each's type-specific info or should I create three different foreign keys in the line items table and create relationships to all three tables?
  3. Did you determine the cause?
  4. Glad it's working for you! You may want to read tmr_slh's comment a couple entries up and verify that this modification works on all platforms you need it for. If not his suggestions look promising though I haven't tried them and I don't know that they all have the same linear complexity. Cheers.
  5. Why don't you want to run sync check? If a record is deleted on server, it won't be deleted from client without sync check. Maybe I misunderstand your question? Why don't we continue via email. Look in the easysync scripts for my email or message me directly.
  6. Hey Jonathan, DELETIONS The reason your records are being deleted is because Sync check will also exclude records with the ES_Exclude flag. In your case, to fix this you'll need to update $$additional_sync_check_info in the client settings to include your state list. In the server-side sync check script set the $States_Selected variable again so that the ES_Exclude flags are correct when the server uuid list is assembled. 1. Copy the calculation from $$additional_pull_info into $$additional_sync_check_info. 2 then add this line to the server sync check script: Set Variable [ $States_Selected ; Substitute ( $additional_sync_check_info ; "-" ; ¶ ) ] after the line Set Variable [$additional_sync_check_info] EXCLUDE Your ES_Exclude seems to be working to me. Try this: Select a state or two in your global picker. Then click the utilities button at bottom and wipe and reset. Your client db should be empty now. Click sync and the records that are pulled down should only be from those two states. That's how your ES_Exclude is currently setup. Records that don't match your selected states will be excluded during pull.
  7. It sounds like your ES_Exclude calculation is not working. If you're trying to exclude records that match the value lists, maybe use the calculation: PatternCount ( $additional_settings ; <field> ) > 0. It would help to know what you specifically need. As for the accidental deletion problem. You need to ensure your users don't accidentally delete things without logging the deletion in a payload record. If that means removing delete from the menu, then do that. To get around the ES_Device_ID problem I changed the field calculation to include either the system or host ip address depending on whether the user has accessed the local or hosted file. I had to modify the scripts to accommodate this change and prevent round-tripping. That's a subject for another thread though. More about exclusions; there are 2 ways to exclude records from the sync. 1) Use the ES_Exclude field. Any record with an ES_Exclude value that evaluates to true will be excluded from the push or pull payloads. You can see that in the Push Payload script here: 2) The second way to exclude records is by modifying the $dyn_sql SELECT statement in "Prepare Payload For Client." Modify this however you want. Want to exclude all Georges from the Pull?... Add "AND name <> 'George'" to the end of the SELECT statement. To exclude values that match your value list, maybe create a loop that adds a clause each time -- E.g. & " AND field <> " & GetValue ( $additional_info ; $i )" is added with each loop. You could technically add more conditions to the Push Payload SELECT statement too, but It's probably better to push all new/edited records and only pull what you need. J
  8. Or for simplicity: 1. Set Variable [ $expression ; " Let ( [ $i = $i + 1 ; $start = $end + 10 ; $end = Position ( $settings ; \"</setting>\" ; 1 ; $i ) ; $end = If ( $end = 0 ; Length ( $settings ) + 1 ; $end ) ]; If ( $i ≠ 1 ; Middle ( $settings ; $start ; $end - $start ) ; Left ( $settings ; $end - 1 ) ) ) " ] 2. Set Variable [ $i ; 0 ] 3. Change each of the following 12 set variable calculations to Evaluate ( $expression )
  9. It bugs me that the "Process Payload From Client" script was substituting "</setting>" delimiters with ¶. This diminishes the usefulness of the delimiter in the first place, and instead of only having to worry about "</setting>" appearing in our data we also have to worry about any stray ¶s. ¶ is MUCH more common than "</setting>". So I changed the script to parse the $settings variable without substitution. Just 2 steps. 1. In "Process Payload From Client", add the following before the Set Variable [$field_delimiter] step: Set Variable [ $i ; 0 ] 2. Then for each of the following 12 Set Variable steps, from $field_delimiter to $additional_settings, change the calculation to: Let ( [ $i = $i + 1 ; $start = $end + 10 ; $end = Position ( $settings ; "</setting>" ; 1 ; $i ) ; $end = If ( $end = 0 ; Length ( $settings ) + 1 ; $end ) ]; If ( $i ≠ 1 ; Middle ( $settings ; $start ; $end - $start ) ; Left ( $settings ; $end - 1 ) ) ) Hopefully that saves someone a future headache. J
  10. First of all, "Prepare Payload For Client" is part of the PULL process and therefore not relevant to the PUSH procedure. You originally asked about sending additional information to the server so I'll address that. (Let us know if you also need to send additional info back to the client.) On second look, I think you're right that ¶ won't work in your additional_push_info variable. This is because in "Process Payload From Client", the server replaces every "</setting> end tag with "¶" and then uses GetValue to parse the different settings including the additional info. If your value list has ¶ characters in it, the script will only grab the first value of the first value list : /. Sooo, I think the best way to handle this would be to take both value lists and substitute a different character/string for every carriage return before putting it into the $additional_info variable. Make sure to use a string that you know won't appear in your value lists, e.g. $$additional_push_info = Substitute ( <value list 1> & ¶ & <value list 2> ; ¶ ; "¥" ). Or you can employ Tim's html-esque method and use "</vl>". Then, in "Process Payload From Client", to convert back to value list format, change the calculation in this script step: to Substitute ( GetValue ( Substitute ( $settings ; "</setting>" ; ¶ ) ; 12 ) ; "¥" ; ¶ ) Your $additional_settings variable should now read as your two value lists originally did back to back, separated by ¶. If you want to keep the two lists separate, use a different separator in the $$additional_push_info step. Oh, haha, right when I finished. Glad you got it working!
  11. The settings portion of the payload, which includes any additional info you send, is delimited by the end tag "</setting>", not by carriage returns. My hunch is that your value lists should work as is. Have you tried including them and seeing if the sync works? If that proves problematic, why not change the value list delimiter to a different character which you could parse? And... there are debug steps built into the server scripts, but you need to change the "$$use_psos_during_*" settings in the client-side settings script to 0 so that the server scripts run on the local machine.
  12. No problem pfry. Good luck.
  13. Excellent advice from @Josh Ormond. However, we should be ok in this case because we're refreshing a plain black window with literally one text object on it. Good rule of thumb though is to use refresh object when it will suffice.
  14. Actually, you can go through all the client sync scripts and change the refresh objects steps to refresh window if you want to make sure the status changes correctly. Refresh Object seems inconsistent. Remember that too many window refreshes can slow things down a hair, but I think the actual behind-the-scenes stuff is what takes the longest so no worries. In the video you'll see that requesting payload from server takes the longest on my system, but this won't be shown unless you change those refresh steps.
  15. Mine takes about 14 seconds. I have a large number of tables with a large number of fields to sync, and a lot of records to query. The "EasySync is go for launch..." step includes the push step and the sync status won't change unless the system finds records to push. This could make it seem like it's hanging for a while even though it's gathering table and field names and records to push. One thing you should do is go into the "Sync With Server" script. Change the 'Refresh Object' script step with 'Refresh Window' where it says "Pulling Data from Server...". It needs to be a refresh window to work, but I think Tim (and I) forgot to change that one. This will break up the monotony, but won't actually speed things up.