Assuming a customer number reassignment happens on one of the other
boxes, and is propagated in with DataPropagator, could it happen
without tripping that code?

Chuck Pence replied:
Yes. As I recall, changes to the keys are implemented as
DELETE+INSERT. An UPDATE TRIGGER would not be invoked on the system
where the changes are propagated\applied.

Interesting. And dismaying. I'll note that the physical file isn't keyed at all; rather, one of the logicals is keyed on the customer number.

At any rate, if it's happening as a delete+insert (and I just got independent confirmation), that explains how changes aren't being processed when they're coming in via DataPropagator.

Unfortunately, that also means that we don't know the new customer number at the time of the delete, and we don't know the old customer number at the time of the insert, and so we don't know how to propagate the change into our CRM product. We can take a good guess, based on the customer name, but I don't like to depend on that, since it, too, can change.

Or we could set something up to automatically alert a human being of the change, so the human being could sort it out.

At this point, I'm open to suggestions, and grasping at straws. Maybe have the trigger log deletions that come from DataPropagator into a keyed PF, and then search that PF when an insertion comes from DataPropagator?

--
JHHL

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.