Disable the expired subscription clean up job. Setting to the retention
period are effective for existing jobs. So you should be ok. But disable the
<davidr@sharpesoft.com> wrote in message
news:1158704774.100686.131470@h48g2000cwc.googlegroups.com...
> Well if we needed another week to fix the problem. Can I just set the
> retention from 14 days to like 28 days. The size of the distribution
> tables isn't an issue. Just not losing the data is the issue. We have
> support ticket with Microsoft and getting close to the 14 day retention
> period. So we wanted to bump it up or something so the subscriptions
> do not expire.
>
> David
>
>
> Hilary Cotter wrote:
>> No, what happens is that the subscription will expire but not be dropped.
>> If
>> you do not set this setting the subscription will expire and be dropped.
>>
>> --
>> Hilary Cotter
>> Director of Text Mining and Database Strategy
>> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
>>
>> This posting is my own and doesn't necessarily represent RelevantNoise's
>> positions, strategies or opinions.
>>
>> Looking for a SQL Server replication book?
>>
http://www.nwsu.com/0974973602.html >>
>> Looking for a FAQ on Indexing Services/SQL FTS
>>
http://www.indexserverfaq.com >>
>>
>>
>> <davidr@sharpesoft.com> wrote in message
>> news:1158704140.221818.178160@i42g2000cwa.googlegroups.com...
>> >I want to verify this.
>> > We have a publication that is having issues and isn't letting their
>> > subscriptions replicate over.
>> > Until we fix the publication issue we want to switch from retention
>> > period 14 days to subscriptions never expires. If I set the
>> > publication to subscription never expires will all the merge data in
>> > the Distribution tables and the subscription tables be ok until we fix
>> > the other problem? This is bi-directional merge replication. Thus, we
>> > do not want the subscriptions to expire and lose their data.Will the
>> > subscribers still collect data ok? Will the publication still collect
>> > data ok?
>> >
>> > Thanks in advance and hope for a quick response.
>> >
>> > David
>> >
>