Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Re: How to handle Accumulating fields in replication

4 posts in Replication Last posting was on 2006-05-22 15:28:44.0Z
Paul Man Posted on 2006-05-18 11:06:18.0Z
From: "Paul Man" <paulman@datasoft.ie>
Newsgroups: Advantage.Replication
Subject: Re: How to handle Accumulating fields in replication
Date: Thu, 18 May 2006 12:06:18 +0100
Lines: 49
Organization: DSoft
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
NNTP-Posting-Host: 82.141.233.142
Message-ID: <446c548c@solutions.advantagedatabase.com>
X-Trace: 18 May 2006 05:03:40 -0700, 82.141.233.142
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!82.141.233.142
Xref: solutions.advantagedatabase.com Advantage.Replication:126
Article PK: 1133984


"Paul Man" <paulman@datasoft.ie> wrote in message news:...
> to recalculate, I'd need to be sure that the transaction details have been
> replicated prior to the customer record so that I could update the balance
> on the target to add the total of the transaction details. Also it means
> maintaining two sources of balance calculation. Is it possible to ensure
> that the transaction details table is replicated prior to the header (
> customer record ) table? Otherwise do I have access to the old value for
> the source table so that I could update the target balance with the
> difference?
>
> e.g
> site Balance Before Balance After
> =================================.
> A 50 65
> B 50 75
>
> After Update should be
> B 85
>
> i.e. I'd need to add the difference of the A.__OLD and A.__NEW balance to
> the B.balance.
> So does the conflict trigger give access to the A.old and A.new values to
> add to the B.balance?
>
>
> "Joachim Duerr (ADS Support)" <jojo.duerr@gmx.de> wrote in message
> news:446b477e@solutions.advantagedatabase.com...
>> Paul Man wrote in <446b3723@solutions.advantagedatabase.com>:
>>
>>> Say I have site a and site b replicating.
>>> A generates customer transaction data that updates a customer balance
>>> B does the same. If the customer record is overwritten during
>>> replication where both sites have updated the customer balance then
>>> one of the balance updates gets lost.
>>
>> you'll get a conflict and you need to resolve that conflict via an ON
>> CONFLICT trigger. Within that trigger code you can decide to keep one
>> or the other - or to recalculate the balance again.
>>
>> --
>> Joachim Duerr
>> Senior Product Support Analyst (Advantage Database Server)
>> iAnywhere Solutions / Extended Systems
>> advantage[AT]extendsys.de
>
>


Paul Man Posted on 2006-05-18 14:45:39.0Z
From: "Paul Man" <paulman@datasoft.ie>
Newsgroups: Advantage.Replication
References: <446c548c@solutions.advantagedatabase.com>
Subject: Re: How to handle Accumulating fields in replication
Date: Thu, 18 May 2006 15:45:39 +0100
Lines: 34
Organization: DSoft
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
NNTP-Posting-Host: 82.141.233.142
Message-ID: <446c87f4@solutions.advantagedatabase.com>
X-Trace: 18 May 2006 08:43:00 -0700, 82.141.233.142
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!82.141.233.142
Xref: solutions.advantagedatabase.com Advantage.Replication:127
Article PK: 1133986

sorry posted incorrectly...

to recalculate, I'd need to be sure that the transaction details have been
replicated prior to the customer record so that I could update the balance
on the target to add the total of the transaction details. Also it means
maintaining two sources of balance calculation. Is it possible to ensure
that the transaction details table is replicated prior to the header (
customer record ) table? Otherwise do I have access to the old value for
the source table so that I could update the target balance with the
difference?

e.g
site Balance Before Balance After
=================================.
A 50 65
B 50 75

After Update should be
B 85

i.e. I'd need to add the difference of the A.__OLD and A.__NEW balance to
the B.balance.
So does the conflict trigger give access to the A.old and A.new values to
add to the B.balance?

>> "Joachim Duerr (ADS Support)" <jojo.duerr@gmx.de> wrote in message
>>>
>>> you'll get a conflict and you need to resolve that conflict via an ON
>>> CONFLICT trigger. Within that trigger code you can decide to keep one
>>> or the other - or to recalculate the balance again.
>>>


Mark Wilkins Posted on 2006-05-18 16:07:28.0Z
From: "Mark Wilkins" <tired@of.spam>
Newsgroups: Advantage.Replication
References: <446c548c@solutions.advantagedatabase.com> <446c87f4@solutions.advantagedatabase.com>
Subject: Re: How to handle Accumulating fields in replication
Date: Thu, 18 May 2006 10:07:28 -0600
Lines: 66
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
NNTP-Posting-Host: 10.24.38.161
Message-ID: <446c9af3@solutions.advantagedatabase.com>
X-Trace: 18 May 2006 10:04:03 -0700, 10.24.38.161
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!10.24.38.161
Xref: solutions.advantagedatabase.com Advantage.Replication:128
Article PK: 1133987

Hi Paul,

I'm not sure I completely understand the scenario yet. Are you trying to
keep two databases consistent? Or are there three databases? It's not
clear to me if A and B are replicating to each other or are both replicating
to a third database C.

I'll assume the former (just A and B). So you are asking what happens if
site A adds 15 to the balance at the same time that B adds 25 to the
balance? Incidentally, shouldn't the final balance be 90 in this example
instead of 85?

Using the available data, I don't see how a conflict trigger could make the
necessary decision to compute the correct final balance. At site A, when
the trigger fires, the __OLD balance will be 65 and the __NEW balance will
be 75. Unless you save the original balance somewhere else, it will not be
available to the trigger. Maybe if the balance adjustment amount was stored
in the table in another field, it might be possible to compute it?

Replication does guarantee that the order of updates will be consistent. So
if you first update the transactions detail at the source before you update
the header table, then the sequence of updates at the target will be the
same.

Mark Wilkins
Advantage R&D

"Paul Man" <paulman@datasoft.ie> wrote in message
news:446c87f4@solutions.advantagedatabase.com...
> sorry posted incorrectly...
>
> to recalculate, I'd need to be sure that the transaction details have been
> replicated prior to the customer record so that I could update the balance
> on the target to add the total of the transaction details. Also it means
> maintaining two sources of balance calculation. Is it possible to ensure
> that the transaction details table is replicated prior to the header (
> customer record ) table? Otherwise do I have access to the old value for
> the source table so that I could update the target balance with the
> difference?
>
> e.g
> site Balance Before Balance After
> =================================.
> A 50 65
> B 50 75
>
> After Update should be
> B 85
>
> i.e. I'd need to add the difference of the A.__OLD and A.__NEW balance to
> the B.balance.
> So does the conflict trigger give access to the A.old and A.new values to
> add to the B.balance?
>
>
>>> "Joachim Duerr (ADS Support)" <jojo.duerr@gmx.de> wrote in message
>>>>
>>>> you'll get a conflict and you need to resolve that conflict via an ON
>>>> CONFLICT trigger. Within that trigger code you can decide to keep one
>>>> or the other - or to recalculate the balance again.
>>>>
>
>


Paul Man Posted on 2006-05-22 15:28:44.0Z
From: "Paul Man" <paulman@datasoft.ie>
Newsgroups: Advantage.Replication
References: <446c548c@solutions.advantagedatabase.com> <446c87f4@solutions.advantagedatabase.com> <446c9af3@solutions.advantagedatabase.com>
Subject: Re: How to handle Accumulating fields in replication
Date: Mon, 22 May 2006 16:28:44 +0100
Lines: 82
Organization: DSoft
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 82.141.233.142
Message-ID: <4471d817@solutions.advantagedatabase.com>
X-Trace: 22 May 2006 09:26:15 -0700, 82.141.233.142
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!82.141.233.142
Xref: solutions.advantagedatabase.com Advantage.Replication:129
Article PK: 1133985

Yes your are correct - the result is 90. What I understand of your message
is that in a conflice situation, the first update to arrive will be
implemented - hence 50 -> 65 then the second update arrives and causes a
conflict error at which point it has to be decided between 65 and 75. I
guess at this point the only thing I can do is recalculate the balance based
on the __old value of 65 plus the values of the detail lines.(making sure of
courece that the detail lines have been written first ).

"Mark Wilkins" <tired@of.spam> wrote in message
news:446c9af3@solutions.advantagedatabase.com...
> Hi Paul,
>
> I'm not sure I completely understand the scenario yet. Are you trying to
> keep two databases consistent? Or are there three databases? It's not
> clear to me if A and B are replicating to each other or are both
> replicating to a third database C.
>
> I'll assume the former (just A and B). So you are asking what happens if
> site A adds 15 to the balance at the same time that B adds 25 to the
> balance? Incidentally, shouldn't the final balance be 90 in this example
> instead of 85?
>
> Using the available data, I don't see how a conflict trigger could make
> the necessary decision to compute the correct final balance. At site A,
> when the trigger fires, the __OLD balance will be 65 and the __NEW balance
> will be 75. Unless you save the original balance somewhere else, it will
> not be available to the trigger. Maybe if the balance adjustment amount
> was stored in the table in another field, it might be possible to compute
> it?
>
> Replication does guarantee that the order of updates will be consistent.
> So if you first update the transactions detail at the source before you
> update the header table, then the sequence of updates at the target will
> be the same.
>
> Mark Wilkins
> Advantage R&D
>
>
> "Paul Man" <paulman@datasoft.ie> wrote in message
> news:446c87f4@solutions.advantagedatabase.com...
>> sorry posted incorrectly...
>>
>> to recalculate, I'd need to be sure that the transaction details have
>> been
>> replicated prior to the customer record so that I could update the
>> balance
>> on the target to add the total of the transaction details. Also it means
>> maintaining two sources of balance calculation. Is it possible to ensure
>> that the transaction details table is replicated prior to the header (
>> customer record ) table? Otherwise do I have access to the old value for
>> the source table so that I could update the target balance with the
>> difference?
>>
>> e.g
>> site Balance Before Balance After
>> =================================.
>> A 50 65
>> B 50 75
>>
>> After Update should be
>> B 85
>>
>> i.e. I'd need to add the difference of the A.__OLD and A.__NEW balance
>> to
>> the B.balance.
>> So does the conflict trigger give access to the A.old and A.new values to
>> add to the B.balance?
>>
>>
>>>> "Joachim Duerr (ADS Support)" <jojo.duerr@gmx.de> wrote in message
>>>>>
>>>>> you'll get a conflict and you need to resolve that conflict via an ON
>>>>> CONFLICT trigger. Within that trigger code you can decide to keep one
>>>>> or the other - or to recalculate the balance again.
>>>>>
>>
>>
>
>