distrib. agent remains stopped

We have a situation where if the subscriber becomes unavailable for an
extended period (say over 15 minutes), the distribution agent at the
publisher will make several attempts to re-connect to the subscriber. Once
the subscriber returns to service, the distrib. agent remains in 'failed'
status and does not reconnect to the subscriber. This causes a push and
other pending operations to fail. As a workaround, the distrib. agent. has
to be manually restarted so normal operation can continue. Is this the
default behavior or possibly a known issue.
================================================== ===
Win2003/SQLSvr2000 ver 8.00 760 (SP3)/Transactional Replic. w/updatable
subscribers/
Hilary Cotter
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
"batuka" <abraxas1969@.hotmail.com> wrote in message
news:ulzKd7ZdFHA.1684@.TK2MSFTNGP09.phx.gbl...
> We have a situation where if the subscriber becomes unavailable for an
> extended period (say over 15 minutes), the distribution agent at the
> publisher will make several attempts to re-connect to the subscriber. Once
> the subscriber returns to service, the distrib. agent remains in 'failed'
> status and does not reconnect to the subscriber. This causes a push and
> other pending operations to fail. As a workaround, the distrib. agent. has
> to be manually restarted so normal operation can continue. Is this the
> default behavior or possibly a known issue.
>
> ================================================== ===
> Win2003/SQLSvr2000 ver 8.00 760 (SP3)/Transactional Replic. w/updatable
> subscribers/
>
|||schedule your distribution agent to start every 5 or 15 minutes. Then make
sure it runs continuously. This way when it stops it will restart 5-15
minutes later. You can also have the job return to stop 1 on failure of step
3.
Hilary Cotter
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
"batuka" <abraxas1969@.hotmail.com> wrote in message
news:ulzKd7ZdFHA.1684@.TK2MSFTNGP09.phx.gbl...
> We have a situation where if the subscriber becomes unavailable for an
> extended period (say over 15 minutes), the distribution agent at the
> publisher will make several attempts to re-connect to the subscriber. Once
> the subscriber returns to service, the distrib. agent remains in 'failed'
> status and does not reconnect to the subscriber. This causes a push and
> other pending operations to fail. As a workaround, the distrib. agent. has
> to be manually restarted so normal operation can continue. Is this the
> default behavior or possibly a known issue.
>
> ================================================== ===
> Win2003/SQLSvr2000 ver 8.00 760 (SP3)/Transactional Replic. w/updatable
> subscribers/
>
|||Both of the suggested options worked very well. However, none of the db
updates that were done at the publisher (while the distribution agent
remained in 'stopped' status) are reflected ('or pushed') at the subscriber
db when it returned to service. Any ideas are apprecciated.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OxUzufadFHA.3052@.TK2MSFTNGP10.phx.gbl...
> schedule your distribution agent to start every 5 or 15 minutes. Then make
> sure it runs continuously. This way when it stops it will restart 5-15
> minutes later. You can also have the job return to stop 1 on failure of
step[vbcol=seagreen]
> 3.
> --
> Hilary Cotter
> 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
> "batuka" <abraxas1969@.hotmail.com> wrote in message
> news:ulzKd7ZdFHA.1684@.TK2MSFTNGP09.phx.gbl...
Once[vbcol=seagreen]
'failed'[vbcol=seagreen]
has
>

Distinct Count issue in Crystal Reports

Hi there,

I'm having a problem with a pretty easy formula which is suppose to just Distinct Count some ID's for a specific period of time:
Each parameter in the formula represents a field in the database, formula bellow should return 3 records... but it returns 7. If I take out the date conditions (so only DistinctCount remains) (7) records will be returned.

If {@.M_Startdate} <= {@.ClientRefDate} and {@.ClientRefDate} <= {@.M_EndDate} Then DistinctCount({@.UniqueRefID})

I also tried to put is in a different way (which express the same thing);
If {@.ClientRefDate} in [{@.M_Startdate} to {@.M_EndDate}] Then DistinctCount({@.UniqueRefID})

It looks like a date validation is performed when I reverse the <= with >=; Formula bellow returns (0) records, if I remove any date condition (7) records are returned.
If {@.M_Startdate} >= {@.ClientRefDate} and {@.ClientRefDate} <= {@.M_EndDate} Then DistinctCount({@.UniqueRefID})

Using WhilePrintingRecords; right at the top does not help I tried already. Also adding a date validation on the main query of the report does not help because whole data will be affected.
Any suggestions?

Thanks,

RobertHi Robert,
Firstly, I see a potential problem here, straight up. Evaluation order of the formulae. You will get inconsistent/unreliable evaluation in formulae that use other formulae if you don't use the EvaluateAfter statement.

If {@.M_Startdate} <= {@.ClientRefDate} and {@.ClientRefDate} <= {@.M_EndDate} Then DistinctCount({@.UniqueRefID})

try this
EvaluateAfter ({@.M_Startdate}
EvaluateAfter ({@.ClientRefDate})
EvaluateAfter ({@.M_EndDate})
EvaluateAfter ({@.UniqueRefID})

If {@.M_Startdate} <= {@.ClientRefDate} and {@.ClientRefDate} <= {@.M_EndDate} Then DistinctCount({@.UniqueRefID})

That way, you are forcing this formula to evaluate the others first.
This may be why the different statements return different results.

Secondly, you are using formulae to provide what I presume are references to data fields (like @.UniqueRefID). I presume there is a pressing reason to do it this way rather than just referencing the underlying data field itself? Going to the underlying data without using a formula is always going to be quicker, and more reliable, as it removes the formulae........

Dave|||Hi Robert,
Firstly, I see a potential problem here, straight up. Evaluation order of the formulae. You will get inconsistent/unreliable evaluation in formulae that use other formulae if you don't use the EvaluateAfter statement.

try this
EvaluateAfter ({@.M_Startdate}
EvaluateAfter ({@.ClientRefDate})
EvaluateAfter ({@.M_EndDate})
EvaluateAfter ({@.UniqueRefID})

If {@.M_Startdate} <= {@.ClientRefDate} and {@.ClientRefDate} <= {@.M_EndDate} Then DistinctCount({@.UniqueRefID})

That way, you are forcing this formula to evaluate the others first.
This may be why the different statements return different results.

Secondly, you are using formulae to provide what I presume are references to data fields (like @.UniqueRefID). I presume there is a pressing reason to do it this way rather than just referencing the underlying data field itself? Going to the underlying data without using a formula is always going to be quicker, and more reliable, as it removes the formulae........

Dave

Hi Dave,

Referencing fields from the database can be quicker sometimes but in this case I'm pressed to use parameters for different calculations. I tried qwith "direct" database fields, result is the same.

Using:
EvaluateAfter ({@.M_Startdate}
EvaluateAfter ({@.ClientRefDate})
EvaluateAfter ({@.M_EndDate})
EvaluateAfter ({@.UniqueRefID})

If {@.M_Startdate} <= {@.ClientRefDate} and {@.ClientRefDate} <= {@.M_EndDate} Then DistinctCount({@.UniqueRefID})
would have to work but unfortunately same result is returned.

Second pass functions require data from more than one record and in this case(WhilePrintingRecords) should evaluate params first... but it does not.

I'll keep trying,

Thanks a bunch,

Robert