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 Stops and starts by it self?

10 posts in Replication Last posting was on 2010-09-02 22:38:38.0Z
Advantage Posted on 2010-08-02 17:19:08.0Z
From: "Advantage" <kim@comcasystems.com>
Newsgroups: Advantage.Replication
Subject: Replication Stops and starts by it self?
Date: Mon, 2 Aug 2010 13:19:08 -0400
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 71.180.49.133
Message-ID: <4c56fd5b@solutions.advantagedatabase.com>
X-Trace: 2 Aug 2010 11:16:11 -0700, 71.180.49.133
Path: solutions.advantagedatabase.com!71.180.49.133
Xref: solutions.advantagedatabase.com Advantage.Replication:402
Article PK: 1134255

I have a customer that have the following setup:

Two replication coming in via the internet and one replication coming via
the local network from another ADS server, both server has the latest
version 9.1 installed. It started three weeks ago when the replication from
one server to the other server in the local network would stop replicating
from 7:00 am to around 12 noon so all transaction between 7 and 12 was
missing all transaction before and after was there. Then it happen again a
week after and last week if happen twice but the second time the replication
stopped from 3:43 pm to 5:07 pm, all transaction was missing from that
period. The two replication from the internet never have missing data, the
server also have the local data, and it has never been down in that period.

Any idea what could make this happen, the replication has been working fine
since September last year and nothing has been changed, I just update the
servers to the last version last week.

Kim


Mark Wilkins Posted on 2010-08-02 23:26:56.0Z
From: "Mark Wilkins" <mark.wilkins@nospamplease>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com>
In-Reply-To: <4c56fd5b@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Mon, 2 Aug 2010 17:26:56 -0600
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 10.24.40.128
Message-ID: <4c575391@solutions.advantagedatabase.com>
X-Trace: 2 Aug 2010 17:24:01 -0700, 10.24.40.128
Path: solutions.advantagedatabase.com!10.24.40.128
Xref: solutions.advantagedatabase.com Advantage.Replication:403
Article PK: 1134256

Hi Kim,

This seems to be a rather puzzling situation. Under normal circumstances, I
cannot think of obvious reasons that would happen. Are there errors in the
error logs (ads_err.*) during those time frames? It would be useful to look
in both the target and source servers' logs.

A few ideas come to mind that could result in this behavior. These seem
unlikely because they all require some action or activity that you or the
customer would probably be aware of. But for what it is worth:

1) It is possible to disable a subscription and then re-enable it. This
seems unlikely since it would require that your application modify the
subscription information on the fly (and you would know if your application
did that). I suppose it is possible for someone using Advantage Data
Architect to connect to the dictionary and disable the subscription. But
that also seems rather unlikely.
2) If replication were halted due to some error, then no entries would be
processed until that error was addressed. But if someone deleted the
replication queue (the actual underlying table) from disk (or simply deleted
all the records in the table), then this behavior would be seen. This would
require someone actively doing this at the source site.
3) It is possible to ignore replication failures
(http://devzone.advantagedatabase.com/dz/webhelp/Advantage10/index.html?master_permitted_rep_errors.htm).
If some kind of communication error were a permitted error, then it could
result in a stretch of "lost" transactions.

Mark Wilkins
Advantage R&D

"Advantage" <kim@comcasystems.com> wrote in message
news:4c56fd5b@solutions.advantagedatabase.com...
> I have a customer that have the following setup:
>
> Two replication coming in via the internet and one replication coming via
> the local network from another ADS server, both server has the latest
> version 9.1 installed. It started three weeks ago when the replication
> from one server to the other server in the local network would stop
> replicating from 7:00 am to around 12 noon so all transaction between 7
> and 12 was missing all transaction before and after was there. Then it
> happen again a week after and last week if happen twice but the second
> time the replication stopped from 3:43 pm to 5:07 pm, all transaction was
> missing from that period. The two replication from the internet never have
> missing data, the server also have the local data, and it has never been
> down in that period.
>
> Any idea what could make this happen, the replication has been working
> fine since September last year and nothing has been changed, I just update
> the servers to the last version last week.
>
> Kim


Edgar Sherman Posted on 2010-08-03 14:48:48.0Z
Date: Tue, 03 Aug 2010 08:48:48 -0600
From: Edgar Sherman <no@email.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
Newsgroups: Advantage.Replication
Subject: Re: Replication Stops and starts by it self?
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com>
In-Reply-To: <4c575391@solutions.advantagedatabase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 10.24.33.110
Message-ID: <4c582b9c@solutions.advantagedatabase.com>
X-Trace: 3 Aug 2010 08:45:48 -0700, 10.24.33.110
Lines: 62
Path: solutions.advantagedatabase.com!10.24.33.110
Xref: solutions.advantagedatabase.com Advantage.Replication:404
Article PK: 1134257

Two other thoughts that came to mind. Still unlikely, but...

A) If somehow the users connected to the dictionary via LOCAL SERVER
rather then REMOTE SERVER there would be no replication.

B) Are these DBF tables that may be updated outside of the dictionary?

Edgar

On 8/2/2010 5:26 PM, Mark Wilkins wrote:
> Hi Kim,
>
> This seems to be a rather puzzling situation. Under normal
> circumstances, I cannot think of obvious reasons that would happen. Are
> there errors in the error logs (ads_err.*) during those time frames? It
> would be useful to look in both the target and source servers' logs.
>
> A few ideas come to mind that could result in this behavior. These seem
> unlikely because they all require some action or activity that you or
> the customer would probably be aware of. But for what it is worth:
>
> 1) It is possible to disable a subscription and then re-enable it. This
> seems unlikely since it would require that your application modify the
> subscription information on the fly (and you would know if your
> application did that). I suppose it is possible for someone using
> Advantage Data Architect to connect to the dictionary and disable the
> subscription. But that also seems rather unlikely.
> 2) If replication were halted due to some error, then no entries would
> be processed until that error was addressed. But if someone deleted the
> replication queue (the actual underlying table) from disk (or simply
> deleted all the records in the table), then this behavior would be seen.
> This would require someone actively doing this at the source site.
> 3) It is possible to ignore replication failures
> (http://devzone.advantagedatabase.com/dz/webhelp/Advantage10/index.html?master_permitted_rep_errors.htm).
> If some kind of communication error were a permitted error, then it
> could result in a stretch of "lost" transactions.
>
> Mark Wilkins
> Advantage R&D
>
> "Advantage" <kim@comcasystems.com> wrote in message
> news:4c56fd5b@solutions.advantagedatabase.com...
>> I have a customer that have the following setup:
>>
>> Two replication coming in via the internet and one replication coming
>> via the local network from another ADS server, both server has the
>> latest version 9.1 installed. It started three weeks ago when the
>> replication from one server to the other server in the local network
>> would stop replicating from 7:00 am to around 12 noon so all
>> transaction between 7 and 12 was missing all transaction before and
>> after was there. Then it happen again a week after and last week if
>> happen twice but the second time the replication stopped from 3:43 pm
>> to 5:07 pm, all transaction was missing from that period. The two
>> replication from the internet never have missing data, the server also
>> have the local data, and it has never been down in that period.
>>
>> Any idea what could make this happen, the replication has been working
>> fine since September last year and nothing has been changed, I just
>> update the servers to the last version last week.
>>
>> Kim
>


Advantage Posted on 2010-08-04 20:24:59.0Z
From: "Advantage" <kim@comcasystems.com>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com> <4c582b9c@solutions.advantagedatabase.com>
In-Reply-To: <4c582b9c@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Wed, 4 Aug 2010 16:24:59 -0400
Lines: 3
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 71.180.49.133
Message-ID: <4c59cbeb@solutions.advantagedatabase.com>
X-Trace: 4 Aug 2010 14:22:03 -0700, 71.180.49.133
Path: solutions.advantagedatabase.com!71.180.49.133
Xref: solutions.advantagedatabase.com Advantage.Replication:405
Article PK: 1134258

There are 8 user connected locally as Remote Server to the database at all
time. We are only using ADT files with DD.

I happen again yesterday but this time only from 6:56 am to 7:24 am. No one
have access to ARC. It look like it always happens in the morning, when the
store opens, but the computers are on all the time.

Kim

"Edgar Sherman" <no@email.com> wrote in message
news:4c582b9c@solutions.advantagedatabase.com...
> Two other thoughts that came to mind. Still unlikely, but...
>
> A) If somehow the users connected to the dictionary via LOCAL SERVER
> rather then REMOTE SERVER there would be no replication.
>
> B) Are these DBF tables that may be updated outside of the dictionary?
>
> Edgar
>
> On 8/2/2010 5:26 PM, Mark Wilkins wrote:
>> Hi Kim,
>>
>> This seems to be a rather puzzling situation. Under normal
>> circumstances, I cannot think of obvious reasons that would happen. Are
>> there errors in the error logs (ads_err.*) during those time frames? It
>> would be useful to look in both the target and source servers' logs.
>>
>> A few ideas come to mind that could result in this behavior. These seem
>> unlikely because they all require some action or activity that you or
>> the customer would probably be aware of. But for what it is worth:
>>
>> 1) It is possible to disable a subscription and then re-enable it. This
>> seems unlikely since it would require that your application modify the
>> subscription information on the fly (and you would know if your
>> application did that). I suppose it is possible for someone using
>> Advantage Data Architect to connect to the dictionary and disable the
>> subscription. But that also seems rather unlikely.
>> 2) If replication were halted due to some error, then no entries would
>> be processed until that error was addressed. But if someone deleted the
>> replication queue (the actual underlying table) from disk (or simply
>> deleted all the records in the table), then this behavior would be seen.
>> This would require someone actively doing this at the source site.
>> 3) It is possible to ignore replication failures
>> (http://devzone.advantagedatabase.com/dz/webhelp/Advantage10/index.html?master_permitted_rep_errors.htm).
>> If some kind of communication error were a permitted error, then it
>> could result in a stretch of "lost" transactions.
>>
>> Mark Wilkins
>> Advantage R&D
>>
>> "Advantage" <kim@comcasystems.com> wrote in message
>> news:4c56fd5b@solutions.advantagedatabase.com...
>>> I have a customer that have the following setup:
>>>
>>> Two replication coming in via the internet and one replication coming
>>> via the local network from another ADS server, both server has the
>>> latest version 9.1 installed. It started three weeks ago when the
>>> replication from one server to the other server in the local network
>>> would stop replicating from 7:00 am to around 12 noon so all
>>> transaction between 7 and 12 was missing all transaction before and
>>> after was there. Then it happen again a week after and last week if
>>> happen twice but the second time the replication stopped from 3:43 pm
>>> to 5:07 pm, all transaction was missing from that period. The two
>>> replication from the internet never have missing data, the server also
>>> have the local data, and it has never been down in that period.
>>>
>>> Any idea what could make this happen, the replication has been working
>>> fine since September last year and nothing has been changed, I just
>>> update the servers to the last version last week.
>>>
>>> Kim
>>


Mark Wilkins Posted on 2010-08-04 20:38:28.0Z
From: "Mark Wilkins" <mark.wilkins@nospamplease>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com> <4c582b9c@solutions.advantagedatabase.com> <4c59cbeb@solutions.advantagedatabase.com>
In-Reply-To: <4c59cbeb@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Wed, 4 Aug 2010 14:38:28 -0600
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 10.24.40.128
Message-ID: <4c59cf16@solutions.advantagedatabase.com>
X-Trace: 4 Aug 2010 14:35:34 -0700, 10.24.40.128
Path: solutions.advantagedatabase.com!10.24.40.128
Xref: solutions.advantagedatabase.com Advantage.Replication:406
Article PK: 1134259


>
> I happen again yesterday but this time only from 6:56 am to 7:24 am. No
> one have access to ARC. It look like it always happens in the morning,
> when the store opens, but the computers are on all the time.
>

Are there any errors in ads_err.* in that timeframe? It would be worth
checking both source and target servers.

Mark Wilkins
Advantage R&D


Advantage Posted on 2010-08-04 20:53:40.0Z
From: "Advantage" <kim@comcasystems.com>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com>
In-Reply-To: <4c575391@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Wed, 4 Aug 2010 16:53:40 -0400
Lines: 1
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 71.180.49.133
Message-ID: <4c59d2a4@solutions.advantagedatabase.com>
X-Trace: 4 Aug 2010 14:50:44 -0700, 71.180.49.133
Path: solutions.advantagedatabase.com!71.180.49.133
Xref: solutions.advantagedatabase.com Advantage.Replication:407
Article PK: 1134261

Hi Mark,

I don't see any errors in the Ads_err file in either end. We have the
Ignore Replication Failures check, should I uncheck it to see if we get some
errors in the Ads_err table?

Kim

"Mark Wilkins" <mark.wilkins@nospamplease> wrote in message
news:4c575391@solutions.advantagedatabase.com...
> Hi Kim,
>
> This seems to be a rather puzzling situation. Under normal circumstances,
> I cannot think of obvious reasons that would happen. Are there errors in
> the error logs (ads_err.*) during those time frames? It would be useful
> to look in both the target and source servers' logs.
>
> A few ideas come to mind that could result in this behavior. These seem
> unlikely because they all require some action or activity that you or the
> customer would probably be aware of. But for what it is worth:
>
> 1) It is possible to disable a subscription and then re-enable it. This
> seems unlikely since it would require that your application modify the
> subscription information on the fly (and you would know if your
> application did that). I suppose it is possible for someone using
> Advantage Data Architect to connect to the dictionary and disable the
> subscription. But that also seems rather unlikely.
> 2) If replication were halted due to some error, then no entries would be
> processed until that error was addressed. But if someone deleted the
> replication queue (the actual underlying table) from disk (or simply
> deleted all the records in the table), then this behavior would be seen.
> This would require someone actively doing this at the source site.
> 3) It is possible to ignore replication failures
> (http://devzone.advantagedatabase.com/dz/webhelp/Advantage10/index.html?master_permitted_rep_errors.htm).
> If some kind of communication error were a permitted error, then it could
> result in a stretch of "lost" transactions.
>
> Mark Wilkins
> Advantage R&D


Mark Wilkins Posted on 2010-08-04 23:04:18.0Z
From: "Mark Wilkins" <mark.wilkins@nospamplease>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com> <4c59d2a4@solutions.advantagedatabase.com>
In-Reply-To: <4c59d2a4@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Wed, 4 Aug 2010 17:04:18 -0600
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 10.24.40.128
Message-ID: <4c59f13d@solutions.advantagedatabase.com>
X-Trace: 4 Aug 2010 17:01:17 -0700, 10.24.40.128
Path: solutions.advantagedatabase.com!10.24.40.128
Xref: solutions.advantagedatabase.com Advantage.Replication:408
Article PK: 1134260

Hi Kim,

The "ignore" option on those errors shouldn't have any effect on whether or
not the errors are logged. The logging should occur no matter what that
setting is.

I found one bug entry that is similar to this issue. It was fixed in
9.10.0.9 (and later versions). Since you say you are using the latest v9.1
(which I believe is 9.10.0.21), then it would not be applicable. If you are
using a version older than 9.10.0.9, though, the problem can be triggered if
the first person to connect to the dictionary has no permissions (e.g.,
anonymous user). The bug in that case was that the replication information
was not populated for the dictionary and subsequent connections would use
the cached information.

A crash dump (connect from ARC and press <ctrl>F9) from the source server
while this problem is occurring would be very useful. However, that seems a
bit tricky since it seems unlikely that you know about the problem until
after the fact.

Mark Wilkins
Advantage R&D

"Advantage" <kim@comcasystems.com> wrote in message
news:4c59d2a4@solutions.advantagedatabase.com...
> Hi Mark,
>
> I don't see any errors in the Ads_err file in either end. We have the
> Ignore Replication Failures check, should I uncheck it to see if we get
> some errors in the Ads_err table?
>
> Kim
>
> "Mark Wilkins" <mark.wilkins@nospamplease> wrote in message
> news:4c575391@solutions.advantagedatabase.com...
>> Hi Kim,
>>
>> This seems to be a rather puzzling situation. Under normal
>> circumstances, I cannot think of obvious reasons that would happen. Are
>> there errors in the error logs (ads_err.*) during those time frames? It
>> would be useful to look in both the target and source servers' logs.
>>
>> A few ideas come to mind that could result in this behavior. These seem
>> unlikely because they all require some action or activity that you or the
>> customer would probably be aware of. But for what it is worth:
>>
>> 1) It is possible to disable a subscription and then re-enable it. This
>> seems unlikely since it would require that your application modify the
>> subscription information on the fly (and you would know if your
>> application did that). I suppose it is possible for someone using
>> Advantage Data Architect to connect to the dictionary and disable the
>> subscription. But that also seems rather unlikely.
>> 2) If replication were halted due to some error, then no entries would be
>> processed until that error was addressed. But if someone deleted the
>> replication queue (the actual underlying table) from disk (or simply
>> deleted all the records in the table), then this behavior would be seen.
>> This would require someone actively doing this at the source site.
>> 3) It is possible to ignore replication failures
>> (http://devzone.advantagedatabase.com/dz/webhelp/Advantage10/index.html?master_permitted_rep_errors.htm).
>> If some kind of communication error were a permitted error, then it could
>> result in a stretch of "lost" transactions.
>>
>> Mark Wilkins
>> Advantage R&D
>
>


Kim Jensen Posted on 2010-08-05 22:52:10.0Z
From: "Kim Jensen" <kim@comcasystems.com>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com> <4c59d2a4@solutions.advantagedatabase.com> <4c59f13d@solutions.advantagedatabase.com>
In-Reply-To: <4c59f13d@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Thu, 5 Aug 2010 18:52:10 -0400
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 71.180.49.133
Message-ID: <4c5b3fe8@solutions.advantagedatabase.com>
X-Trace: 5 Aug 2010 16:49:12 -0700, 71.180.49.133
Path: solutions.advantagedatabase.com!71.180.49.133
Xref: solutions.advantagedatabase.com Advantage.Replication:409
Article PK: 1134262

Hi Mark,

I was using 9.10.0.9 when it first started and then I upgraded to 9.10.0.21,
but I did not update the dll on the client computers that connect to the
server, they may have a older version than 9.10.0.9, would that do it?

I always happen in the morning, I will try to go online every morning and
see if I can do a cash dump.

I only have tomorrow and Saturday, because I'm flying to DC on Sunday for
the Techwave.

Kim

"Mark Wilkins" <mark.wilkins@nospamplease> wrote in message
news:4c59f13d@solutions.advantagedatabase.com...
> Hi Kim,
>
> The "ignore" option on those errors shouldn't have any effect on whether
> or not the errors are logged. The logging should occur no matter what
> that setting is.
>
> I found one bug entry that is similar to this issue. It was fixed in
> 9.10.0.9 (and later versions). Since you say you are using the latest
> v9.1 (which I believe is 9.10.0.21), then it would not be applicable. If
> you are using a version older than 9.10.0.9, though, the problem can be
> triggered if the first person to connect to the dictionary has no
> permissions (e.g., anonymous user). The bug in that case was that the
> replication information was not populated for the dictionary and
> subsequent connections would use the cached information.
>
> A crash dump (connect from ARC and press <ctrl>F9) from the source server
> while this problem is occurring would be very useful. However, that seems
> a bit tricky since it seems unlikely that you know about the problem until
> after the fact.
>
> Mark Wilkins
> Advantage R&D
>
> "Advantage" <kim@comcasystems.com> wrote in message
> news:4c59d2a4@solutions.advantagedatabase.com...
>> Hi Mark,
>>
>> I don't see any errors in the Ads_err file in either end. We have the
>> Ignore Replication Failures check, should I uncheck it to see if we get
>> some errors in the Ads_err table?
>>
>> Kim
>>
>> "Mark Wilkins" <mark.wilkins@nospamplease> wrote in message
>> news:4c575391@solutions.advantagedatabase.com...
>>> Hi Kim,
>>>
>>> This seems to be a rather puzzling situation. Under normal
>>> circumstances, I cannot think of obvious reasons that would happen. Are
>>> there errors in the error logs (ads_err.*) during those time frames? It
>>> would be useful to look in both the target and source servers' logs.
>>>
>>> A few ideas come to mind that could result in this behavior. These seem
>>> unlikely because they all require some action or activity that you or
>>> the customer would probably be aware of. But for what it is worth:
>>>
>>> 1) It is possible to disable a subscription and then re-enable it. This
>>> seems unlikely since it would require that your application modify the
>>> subscription information on the fly (and you would know if your
>>> application did that). I suppose it is possible for someone using
>>> Advantage Data Architect to connect to the dictionary and disable the
>>> subscription. But that also seems rather unlikely.
>>> 2) If replication were halted due to some error, then no entries would
>>> be processed until that error was addressed. But if someone deleted the
>>> replication queue (the actual underlying table) from disk (or simply
>>> deleted all the records in the table), then this behavior would be seen.
>>> This would require someone actively doing this at the source site.
>>> 3) It is possible to ignore replication failures
>>> (http://devzone.advantagedatabase.com/dz/webhelp/Advantage10/index.html?master_permitted_rep_errors.htm).
>>> If some kind of communication error were a permitted error, then it
>>> could result in a stretch of "lost" transactions.
>>>
>>> Mark Wilkins
>>> Advantage R&D
>>
>>


Mark Wilkins Posted on 2010-08-06 15:04:33.0Z
From: "Mark Wilkins" <mark.wilkins@nospamplease>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com> <4c59d2a4@solutions.advantagedatabase.com> <4c59f13d@solutions.advantagedatabase.com> <4c5b3fe8@solutions.advantagedatabase.com>
In-Reply-To: <4c5b3fe8@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Fri, 6 Aug 2010 09:04:33 -0600
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 10.24.40.128
Message-ID: <4c5c23cb@solutions.advantagedatabase.com>
X-Trace: 6 Aug 2010 09:01:31 -0700, 10.24.40.128
Path: solutions.advantagedatabase.com!10.24.40.128
Xref: solutions.advantagedatabase.com Advantage.Replication:410
Article PK: 1134263

Hi Kim,

The old client version should not matter. The fix is server-side, so it
seems this is not the issue. I was rather inclined to think it wasn't to
begin with because if it were the issue, I think it would have required a
stop and restart of ADS in order for the replication to start working again.
If I understand your scenario, it simply "starts working again for no
apparent reason".

So I am still completely baffled.

I can't remember if you have supplied a crash dump file for us in the past
or not. I need to point out that while producing the crash dump, ADS
freezes all threads. This can mean that clients may time out and lose their
connections (I think if the connection type is TCP/IP this won't happen ...
but I am not 100% sure about that now). The size of the crash dump largely
depends on how much memory is in use by the server; if the user count is low
(which yours sounds like it), it may be reasonably fast.

Mark Wilkins
Advantage R&D

"Kim Jensen" <kim@comcasystems.com> wrote in message
news:4c5b3fe8@solutions.advantagedatabase.com...
> Hi Mark,
>
> I was using 9.10.0.9 when it first started and then I upgraded to
> 9.10.0.21, but I did not update the dll on the client computers that
> connect to the server, they may have a older version than 9.10.0.9, would
> that do it?
>
> I always happen in the morning, I will try to go online every morning and
> see if I can do a cash dump.
>
> I only have tomorrow and Saturday, because I'm flying to DC on Sunday for
> the Techwave.
>
> Kim
>
> "Mark Wilkins" <mark.wilkins@nospamplease> wrote in message
> news:4c59f13d@solutions.advantagedatabase.com...
>> Hi Kim,
>>
>> The "ignore" option on those errors shouldn't have any effect on whether
>> or not the errors are logged. The logging should occur no matter what
>> that setting is.
>>
>> I found one bug entry that is similar to this issue. It was fixed in
>> 9.10.0.9 (and later versions). Since you say you are using the latest
>> v9.1 (which I believe is 9.10.0.21), then it would not be applicable. If
>> you are using a version older than 9.10.0.9, though, the problem can be
>> triggered if the first person to connect to the dictionary has no
>> permissions (e.g., anonymous user). The bug in that case was that the
>> replication information was not populated for the dictionary and
>> subsequent connections would use the cached information.
>>
>> A crash dump (connect from ARC and press <ctrl>F9) from the source server
>> while this problem is occurring would be very useful. However, that
>> seems a bit tricky since it seems unlikely that you know about the
>> problem until after the fact.
>>
>> Mark Wilkins
>> Advantage R&D
>>
>> "Advantage" <kim@comcasystems.com> wrote in message
>> news:4c59d2a4@solutions.advantagedatabase.com...
>>> Hi Mark,
>>>
>>> I don't see any errors in the Ads_err file in either end. We have the
>>> Ignore Replication Failures check, should I uncheck it to see if we get
>>> some errors in the Ads_err table?
>>>
>>> Kim
>>>
>>> "Mark Wilkins" <mark.wilkins@nospamplease> wrote in message
>>> news:4c575391@solutions.advantagedatabase.com...
>>>> Hi Kim,
>>>>
>>>> This seems to be a rather puzzling situation. Under normal
>>>> circumstances, I cannot think of obvious reasons that would happen.
>>>> Are there errors in the error logs (ads_err.*) during those time
>>>> frames? It would be useful to look in both the target and source
>>>> servers' logs.
>>>>
>>>> A few ideas come to mind that could result in this behavior. These
>>>> seem unlikely because they all require some action or activity that you
>>>> or the customer would probably be aware of. But for what it is worth:
>>>>
>>>> 1) It is possible to disable a subscription and then re-enable it.
>>>> This seems unlikely since it would require that your application modify
>>>> the subscription information on the fly (and you would know if your
>>>> application did that). I suppose it is possible for someone using
>>>> Advantage Data Architect to connect to the dictionary and disable the
>>>> subscription. But that also seems rather unlikely.
>>>> 2) If replication were halted due to some error, then no entries would
>>>> be processed until that error was addressed. But if someone deleted
>>>> the replication queue (the actual underlying table) from disk (or
>>>> simply deleted all the records in the table), then this behavior would
>>>> be seen. This would require someone actively doing this at the source
>>>> site.
>>>> 3) It is possible to ignore replication failures
>>>> (http://devzone.advantagedatabase.com/dz/webhelp/Advantage10/index.html?master_permitted_rep_errors.htm).
>>>> If some kind of communication error were a permitted error, then it
>>>> could result in a stretch of "lost" transactions.
>>>>
>>>> Mark Wilkins
>>>> Advantage R&D
>>>
>>>


Kim Jensen Posted on 2010-09-02 22:38:38.0Z
From: "Kim Jensen" <kim@comcasystems.com>
Newsgroups: Advantage.Replication
References: <4c56fd5b@solutions.advantagedatabase.com> <4c575391@solutions.advantagedatabase.com> <4c59d2a4@solutions.advantagedatabase.com> <4c59f13d@solutions.advantagedatabase.com> <4c5b3fe8@solutions.advantagedatabase.com> <4c5c23cb@solutions.advantagedatabase.com>
In-Reply-To: <4c5c23cb@solutions.advantagedatabase.com>
Subject: Re: Replication Stops and starts by it self?
Date: Thu, 2 Sep 2010 18:38:38 -0400
Lines: 1
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 71.180.49.133
Message-ID: <4c8026b1@solutions.advantagedatabase.com>
X-Trace: 2 Sep 2010 16:35:29 -0700, 71.180.49.133
Path: solutions.advantagedatabase.com!71.180.49.133
Xref: solutions.advantagedatabase.com Advantage.Replication:411
Article PK: 1134264

We finally found the problem. There was one subscription that had stopped
back in 09/04/2009 with a queue of over 500,000 records. After removing the
subscription and deleting the queue, two weeks ago, there have been no
problems.

Kim