Login
`
Templates, Tools and Utilities
|
||
Icetips Article
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
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.
Today is November 21, 2024, 3:51 am This article has been viewed 35205 times.
|
|