|
Hello,
In our case, we had to make sure that the changes were applied on the
target machine in the same order as on the production machine.
The software we use (Vision) has the option of specifying multiple "apply
queue" to speed up the replication. We had to restrict ourselves to one
apply queue per replication "group" to avoid the possibility of a detailed
record being updated before the corresponding header which would create an
integrity violation.
With our setup, we never get error related to constraint.
Hope this help
Denis Robitaille
Chef de service TI - Solution d'entreprise
Infrastructure et opérations
CASCADES CENTRE DES TECHNOLOGIES
412 Marie Victorin
Kingsey falls(Québec) Canada J0A 1B0
Tél : 819 363 6100 Poste :52130
Cell : 819 352 9362
-----Message d'origine-----
De : MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de
Rob Berendt
Envoyé : 4 mai 2017 15:41
À : midrange-l@xxxxxxxxxxxx
Objet : Database features vs software replication
Due to our legacy software we're not doing a whole lot of referential
integrity within the database itself. For example, do not allow an order
line created without a corresponding order header. Therefore we're not
using much (if any) foreign key constraints such as:
create table ordhead (
Ordernumber int as identity,
customernumber int,
primary key(ordernumber)
);
create or replace table ordline (
ordernumber int not null,
orderline int not null,
itemNumber int,
ordqty dec (15,5),
constraint ordline_ordheadFK foreign key (ordernumber) references ordhead
(ordernumber), constraint ordlinePK primary key (ordernumber, orderline) );
I've heard from someone that this can be problematic at times with
software based replication. I am trying to get clarification but I think
it had something to do with getting the order of the parent/child updates
reversed. This was causing an exclusive lock on the target causing them to
stop/restart their software based replication to clear the lock.
Sometimes as often as every other day.
Have others experienced such issues?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
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.