` Printed Icetips Article

Icetips Article



Par2: Synchronizing
1999-01-21 -- Craig Ransom
 
Alexey Solovjev talked me through the problems with the Synchronizer.  It only wants 
things backwards, i.e. your OLD directory has to be your TARGET directory and your
NEW directory has to be your SOURCE directory. Plus some other peculiarities.

After my sig is what he told me to do. I'd added a SysID field to each of my files but 
couldn't get the conversion program to build correctly.


===================================
I've not found problems with your dictionaries. I think, your problems' roots are in not 
exact understanding how the Synchronizer works. Let me explain my steps.

1. Load IFMS.DCT as Source dictionary and OLDIFMS.DCT as destination one.
   This direction is correct. See my message dated November 25 in the topspeed.
    products.c5ee newsgroup under title "Re: Dictionary Synchronizer and the Convert 
    Program" for explanations why this is so.
2. Exclude unpaired (by sense) files from the synchronization by selecting
   "Ignore Differences" for them. This could be applied for such files as
    DemoControl, OldIFMSDate, etc.
3. Resolve conflicts step by step. You need understand that operations on
   structures (Files, Keys) can have side effect and born extra conflicts.
   Therefore the best way is to expand the whole sub-tree for the file and
   look what kind of conflicts are present. Then you need resolve these
   conflicts accordingly. I will try to explain on the example of the JobControl file.

- Add SysID field to Destination;
- Copy Type properties of fields to Destination; differences in other
  properties can be ignored, if your only goal is conversion program. 
Or,
  you can select Copy for whole Properties set (by hilighting the line with
  Properties word), if you want;
- Match keys which have not been matched automatically. E.g., hilight the
  line with KeyEqpcatF key, press the right mouse button and choose the
  correspondent key from the Match menu. Do the same for other unmatched
  keys. After finishing differences in Relations would be resolved too.
  The reason why keys (or fields, or relations) could remain unmatched
  automatically is in the rule used for matching (say, By Order Only, or
  By Components Only) and changes have been made for this key (or field,
  or relation);
===> At this point you have two keys not synchronized
- Select the Primary Key property for the X1JCTL key and perform the Copy
  operation; this key is synchronized now;
- Add KeySysID key to Destination.

JobControl file is synchronized. If to perform 2 last steps in other order,
you'll get extra conflict after first step because 2 keys in Destination
will have the Primary Key attribute set to TRUE. This is wrong by 
definition. But the second step would resolve this conflict.

If to Add KeySysID key to Destination before Adding the SysID field, 
you will have conflict because the Destination file has a key based on 
absent field. Etc.



Printed November 23, 2024, 2:22 am
This article has been viewed/printed 35209 times.