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.

Replication fails on recall/undelete of the deleted record

5 posts in Replication Last posting was on 2009-09-09 22:15:17.0Z
Kiron Joseph Posted on 2009-09-08 10:43:11.0Z
From: Kiron Joseph <kiron@datadevices.com>
Newsgroups: Advantage.Replication
Subject: Replication fails on recall/undelete of the deleted record
Date: Tue, 08 Sep 2009 16:13:11 +0530
Organization: Data Devices Pvt. Ltd.
Reply-To: kiron@datadevices.com
Message-ID: <bfcca59n1ur2gbh1eou8pio8sm6hmhou2b@4ax.com>
X-Newsreader: Forte Agent 3.2/32.830
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 122.166.23.8
X-Trace: 8 Sep 2009 04:41:55 -0700, 122.166.23.8
Lines: 31
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!122.166.23.8
Xref: solutions.advantagedatabase.com Advantage.Replication:366
Article PK: 1134220

Hi All,

I our application we are recycling the deleted records. We use ADS 9.1
and enabled the replication. Its works well except in the case of
deleted records.

When delete a record in the source table, it will show as deleted in
the target Table also.

But that deleted record is recalled in the source, it will not recall
in that record in the target table. it remains as deleted.

But any modification in that deleted record in the source will
replicated to the target (except recall/undelete)

We use DBF with DD.

The Advantage Docs says that,

" If you delete a DBF record, the SQL DELETE statement will be sent to
the target to delete the same record there. But if an application
modifies a deleted DBF record, the replication logic will simply try
to delete the record at the target again. This will most likely result
in a replication failure. In addition, it is not possible to recall
(undelete) deleted DBF records with replication"

I didnt understand Why this is happening. Any body can explain ?


Regards
Kiron


Peter Funk (ADS) Posted on 2009-09-08 20:03:16.0Z
Date: Tue, 8 Sep 2009 20:03:16 +0000 (UTC)
Message-ID: <864d0bcb196848cbfea43f2d3cb9@devzone.advantagedatabase.com>
From: Peter Funk (ADS) <pfunk@nospam.com>
Subject: Re: Replication fails on recall/undelete of the deleted record
Newsgroups: Advantage.Replication
References: <bfcca59n1ur2gbh1eou8pio8sm6hmhou2b@4ax.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Pro 1098.1
NNTP-Posting-Host: 10.24.38.185
X-Trace: 8 Sep 2009 14:01:56 -0700, 10.24.38.185
Lines: 19
X-Authenticated-User: upreview
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!10.24.38.185
Xref: solutions.advantagedatabase.com Advantage.Replication:367
Article PK: 1134221

Hello Kiron,
What you are seeing is expected. The fundamental problem is that there is
no way to recall a record using SQL and our replication uses SQL to perform
all the replication updates. Obviously there is an SQL DELETE function but
there is no corresponding UNDELETE function. The recall on the source record
is treated like a normal UPDATE in which the deleted byte of the record's
header is updated. Then the replication update for a recall is simply an
SQL UPDATE with all the field values of the source record (changed or not)
but without chaning the destination record's deleted status.

I'll have to talk to the engineer who designed and implemented replication
to see if there is anything we can do about this. I can't think of any reason
why we couldn't, but he might know a reason why.

Regards,
Peter Funk
Advantage R&D


Kiron Joseph Posted on 2009-09-09 00:37:16.0Z
From: Kiron Joseph <kiron@datadevices.com>
Newsgroups: Advantage.Replication
Subject: Re: Replication fails on recall/undelete of the deleted record
Date: Wed, 09 Sep 2009 06:07:16 +0530
Organization: Data Devices Pvt. Ltd.
Reply-To: kiron@datadevices.com
Message-ID: <uctda5t1vavcav4gbihm01ak84klfbtcug@4ax.com>
References: <bfcca59n1ur2gbh1eou8pio8sm6hmhou2b@4ax.com> <864d0bcb196848cbfea43f2d3cb9@devzone.advantagedatabase.com>
X-Newsreader: Forte Agent 3.2/32.830
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 117.196.131.216
X-Trace: 8 Sep 2009 18:35:59 -0700, 117.196.131.216
Lines: 45
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!117.196.131.216
Xref: solutions.advantagedatabase.com Advantage.Replication:368
Article PK: 1134222

Hi Peter,

Thanks for the immediate response.

>Hello Kiron,
>What you are seeing is expected.

OK. Then what the others are doing with the deleted records in
replication ? Otherwise we are not recycling the deleted records,
system will slow.

This is what we are doing now
We delete the unwanted records and recycle it when an there is a
requirement of new record. And hide all the deleted records from the
all the display (Like browsers,reports etc.)

Is there any alternative method ?

> The fundamental problem is that there is
>no way to recall a record using SQL and our replication uses SQL to perform
>all the replication updates. Obviously there is an SQL DELETE function but
>there is no corresponding UNDELETE function. The recall on the source record
>is treated like a normal UPDATE in which the deleted byte of the record's
>header is updated.
I think you can do the same deleted byte updation in the target also.
Then the problem will be solved.

Now the deleted status will not change but the all the other changes
in the deleted records in the source is replicating. I think that is
meaningless.

> Then the replication update for a recall is simply an
>SQL UPDATE with all the field values of the source record (changed or not)
>but without chaning the destination record's deleted status.
>
>I'll have to talk to the engineer who designed and implemented replication
>to see if there is anything we can do about this. I can't think of any reason
>why we couldn't, but he might know a reason why.

Please. we in the final stage of the replication implementation. we
struct at this point.
>
>Regards,
>Peter Funk
>Advantage R&D
>


Peter Funk (ADS) Posted on 2009-09-09 16:49:44.0Z
Date: Wed, 9 Sep 2009 16:49:44 +0000 (UTC)
Message-ID: <864d0bcb196b18cbff5260538617@devzone.advantagedatabase.com>
From: Peter Funk (ADS) <pfunk@nospam.com>
Subject: Re: Replication fails on recall/undelete of the deleted record
Newsgroups: Advantage.Replication
References: <uctda5t1vavcav4gbihm01ak84klfbtcug@4ax.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Pro 1098.1
NNTP-Posting-Host: 10.24.38.185
X-Trace: 9 Sep 2009 10:48:24 -0700, 10.24.38.185
Lines: 13
X-Authenticated-User: upreview
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!10.24.38.185
Xref: solutions.advantagedatabase.com Advantage.Replication:369
Article PK: 1134223

Hello Kiron,
I spoke with the rest of R&D and we don't have a simple fix for this. To
fix it would require some design and implementation time that we just don't
have right now. Our suggestion is to add a logical field to the table which
you use to flag the record as 'deleted'. Then in your application you can
use the field to filter out the 'deleted' records for viewing and also for
recycling.

Regards,
Peter Funk
Advantage R&D


Jan Sperling Posted on 2009-09-09 22:15:17.0Z
Reply-To: "Jan Sperling" <sperling@racsa.co.cr>
From: "Jan Sperling" <sperling@racsa.co.cr>
Newsgroups: Advantage.Replication
References: <bfcca59n1ur2gbh1eou8pio8sm6hmhou2b@4ax.com> <864d0bcb196848cbfea43f2d3cb9@devzone.advantagedatabase.com> <uctda5t1vavcav4gbihm01ak84klfbtcug@4ax.com>
Subject: Re: Replication fails on recall/undelete of the deleted record
Date: Wed, 9 Sep 2009 14:15:17 -0800
Lines: 27
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5843
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: 201.198.4.254
Message-ID: <4aa80c82@solutions.advantagedatabase.com>
X-Trace: 9 Sep 2009 14:13:54 -0700, 201.198.4.254
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!201.198.4.254
Xref: solutions.advantagedatabase.com Advantage.Replication:371
Article PK: 1134225

Hi Kiron:

> Is there any alternative method ?
>

One way we have used for many years is having a master field in all our
tables.
This field indicates the company ID, because our apps are multi-company.

In order to recycle records, when we have to delete some record, simply we
assign 'XXXXXXXXXX' to the company field (assuming we will never get a
XXXXXX ID).

This technique has 2 benefits:
1. The location of a deleted record is faster (simply a seek('XXXXXXXXXX'))
2. AFAIK, old Clipper, dBase, Fox, etc, skip one by one deleted records, in
order to step to the next valid record. This can be time consuming, if
there are for example 50.000 records to be skip'd.


Hope this helps...

BR, Jan