Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 3704 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I want to remove certain field names from a text string.  The company needs the ability to specify the fields to exclude in a sync process on a per table basis.  I do not want to hard-code the field names for obvious reasons, nor do I want to preface each field with 'EXCL_' which is currently required by EasySync so I created a cf which allows management to insert the field names and then get the object IDs from them.  The same cf is a toggle, switching from the object ids to the names and back.  What will be stored in a field is the field object ids.

 

Then during sync, I need to take the field names and append them with [1]<field> to create the identical match to the text string so they can be removed.  

 

Here is where I am a bit stuck ... if I use Substitute(), and there are several tables in the string (current example shows two tables but many tables will be included) and if the same field name exists in other tables (such as ID), it removes them all.  I only want to remove the field from the associated table.

 

I would rather not modify the original scripted process but instead remove the exclude fields immediately after the sync script gathers them into its single variable.  If I continue on this path, my next step would be to split the tables apart so the Strip script only looks to the current table's field names and thus removes only a single ID instead of them all.  

 

I've created a single file for demo purposes to show what I am after if anyone is willing to take a look.  It is in fp7 format since it does not require higher versions and those with lesser versions may be interested.  This may be the wrong approach so I've decided to regroup and get a reality check here from forum members.  

removeFields.fp7.zip

Posted

BTW, I know that the If[] test as to whether it is displaying numbers or names is a kludge - it is just for the demo.  :-)

Posted

Well, this:

Let ( segments = Substitute ( users::theString ; "</field>" ; ¶ ) ; segments )

... gives me:

<tables>users

ID[1]
position[1]
name_first[1]
name_last[1]
salary[1]
</table>companies
ID[1]
type[1]
company_name[1]
phone[1]
</table></tables>
 
... so pulling the table out would not be difficult (and I could even store its object id for translation when I need to compare here also).  But instead of using Substitute(), maybe I should just loop (similar in theory to a recent changelog script which was done).  Or maybe I should just modify the EasySync script.  I really want to keep the existing EasySync scripts standardised and as intact as possible because these pieces we change and our own modifications will need to be replicated in future EasySync updates and it is simpler if they are chunk code instead of changing this field name here and that variable there etc.
 
Another issue I just realised is that it would break on repetitions.  I could swear to high heavens that I NEVER EVER use repetitions for data so it would simply never apply but I have learned my lesson there; never say never.  So if repetition, I will need to test and loop the reps to list each one separately (I think).
 
AFAIK, an empty clone's tables still holds the same field ids and they are never reused so we are safe there.  If I found out differently, it wouldn't be difficult to include a process during migrations to switch any of those strings back to text for the export and then after import in new empty clone, switch them back to the object ids.  I feel it is pretty safe.  It just feels like I'm taking something apart that I had originally put together (EasySync) and that always feels ... well, just wrong.
 
Everything is a trade-off ... the EasySync script is lightening fast and I do not believe this will make much of a difference except that the ability to slide it this adjustment will offer more control and might save from updating fields which do not need to be updated.

This topic is 3704 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.