The new database is added to the replication system but all
tables on the RDB are empty.  Setreptable is on and there's
no uncommitted transaction.  It is using default action
class and there's no loss detection.  Queue is caught up. 
We turned on "dsi_buf_dump" and it shows on the error log
that the transaction executed on the PDB is replicated. 
However, the table is again empty on the RDB.  Log is not
full on both RDB and RSSD.  Maint user is dbo.  What else
can I take a look at?  PDS and RDS is 11.0.3.3, RS is 11.0.3

I don't remember since what version warm standy exists.

Did you create subscriptions ?

Luc.

<mkim@xtivia.com> wrote in message 
news:48d459d2.2871.1681692777@sybase.com...
> The new database is added to the replication system but all
> tables on the RDB are empty.  Setreptable is on and there's
> no uncommitted transaction.  It is using default action
> class and there's no loss detection.  Queue is caught up.
> We turned on "dsi_buf_dump" and it shows on the error log
> that the transaction executed on the PDB is replicated.
> However, the table is again empty on the RDB.  Log is not
> full on both RDB and RSSD.  Maint user is dbo.  What else
> can I take a look at?  PDS and RDS is 11.0.3.3, RS is 11.0.3 

Assuming that you are not replicating to more than one target and 
therefore dsi_buf_dump trace is pointing to the DB that you wanted it to 
be....

.....some possibilities include:

1 - servername in interfaces file for RS matches the destination (and 
data isn't being applied elsewhere).   You can turn on the CIS traces in 
the server in question to make sure it is receiving the commands ala 
dbcc traceon (3605,11201,11202,11203,11204,11205)....if the ASE log then 
contains the same commands as dsi_buf_dump, you know it is receiving the 
commands....

2 - someone has null'd the rs_commit function string - so nothing is 
getting committed (verifiable by watching monOpenObjectActivity for DBID 
in question and see rows inserted/updated/deleted if matching DSI 
activity....dsi_buf_dump used to use a default fstring output so it may 
not show the problem all the way).

3 - If triggers are on, or if doing proc replication - make sure none of 
the triggers/procs are issuing a rollback transaction.


mkim@xtivia.com wrote:
> The new database is added to the replication system but all
> tables on the RDB are empty.  Setreptable is on and there's
> no uncommitted transaction.  It is using default action
> class and there's no loss detection.  Queue is caught up. 
> We turned on "dsi_buf_dump" and it shows on the error log
> that the transaction executed on the PDB is replicated. 
> However, the table is again empty on the RDB.  Log is not
> full on both RDB and RSSD.  Maint user is dbo.  What else
> can I take a look at?  PDS and RDS is 11.0.3.3, RS is 11.0.3

The problem was found on the replicate database (ASE). 
Somehow, the transaction was not executed.  Whenever DML is
executed by either maint user or dbo user, it gives prompt
back and the transaction didn't happen.  Nothing was written
on the error log and there was no return message.  We by
passed this problem by creating new tables and re-executing
materialization.  We found one more reason to upgrade!!! 
Thanks for the helpful tips.
> Assuming that you are not replicating to more than one
> target and  therefore dsi_buf_dump trace is pointing to
> the DB that you wanted it to  be....
>
> ....some possibilities include:
>
> 1 - servername in interfaces file for RS matches the
> destination (and  data isn't being applied elsewhere).
> You can turn on the CIS traces in  the server in question
> to make sure it is receiving the commands ala  dbcc
> traceon (3605,11201,11202,11203,11204,11205)....if the ASE
> log then  contains the same commands as dsi_buf_dump, you
> know it is receiving the  commands....
>
> 2 - someone has null'd the rs_commit function string - so
> nothing is  getting committed (verifiable by watching
> monOpenObjectActivity for DBID  in question and see rows
> inserted/updated/deleted if matching DSI
> activity....dsi_buf_dump used to use a default fstring
> output so it may  not show the problem all the way).
>
> 3 - If triggers are on, or if doing proc replication -
> make sure none of  the triggers/procs are issuing a
> rollback transaction.
>
>
> mkim@xtivia.com wrote:
> > The new database is added to the replication system but
> > all tables on the RDB are empty.  Setreptable is on and
> > there's no uncommitted transaction.  It is using default
> > action class and there's no loss detection.  Queue is
> > caught up.  We turned on "dsi_buf_dump" and it shows on
> > the error log that the transaction executed on the PDB
> > is replicated.  However, the table is again empty on the
> > RDB.  Log is not full on both RDB and RSSD.  Maint user
> > is dbo.  What else can I take a look at?  PDS and RDS is
> 11.0.3.3, RS is 11.0.3

On Sep 23, 7:52=A0pm, mkim wrote:
> The problem was found on the replicate database (ASE).
> Somehow, the transaction was not executed. =A0Whenever DML is
> executed by either maint user or dbo user, it gives prompt
> back and the transaction didn't happen. =A0Nothing was written
> on the error log and there was no return message. =A0We by
> passed this problem by creating new tables and re-executing
> materialization. =A0We found one more reason to upgrade!!!
> Thanks for the helpful tips.
>
>
>
> > Assuming that you are not replicating to more than one
> > target and =A0therefore dsi_buf_dump trace is pointing to
> > the DB that you wanted it to =A0be....
>
> > ....some possibilities include:
>
> > 1 - servername in interfaces file for RS matches the
> > destination (and =A0data isn't being applied elsewhere).
> > You can turn on the CIS traces in =A0the server in question
> > to make sure it is receiving the commands ala =A0dbcc
> > traceon (3605,11201,11202,11203,11204,11205)....if the ASE
> > log then =A0contains the same commands as dsi_buf_dump, you
> > know it is receiving the =A0commands....
>
> > 2 - someone has null'd the rs_commit function string - so
> > nothing is =A0getting committed (verifiable by watching
> > monOpenObjectActivity for DBID =A0in question and see rows
> > inserted/updated/deleted if matching DSI
> > activity....dsi_buf_dump used to use a default fstring
> > output so it may =A0not show the problem all the way).
>
> > 3 - If triggers are on, or if doing proc replication -
> > make sure none of =A0the triggers/procs are issuing a
> > rollback transaction.
>
> > m...@xtivia.com wrote:
> > > The new database is added to the replication system but
> > > all tables on the RDB are empty. =A0Setreptable is on and
> > > there's no uncommitted transaction. =A0It is using default
> > > action class and there's no loss detection. =A0Queue is
> > > caught up. =A0We turned on "dsi_buf_dump" and it shows on
> > > the error log that the transaction executed on the PDB
> > > is replicated. =A0However, the table is again empty on the
> > > RDB. =A0Log is not full on both RDB and RSSD. =A0Maint user
> > > is dbo. =A0What else can I take a look at? =A0PDS and RDS is
> > 11.0.3.3, RS is 11.0.3- Hide quoted text -
>

Did you have Row level Access implemented at replicate side by any
chance ?

-Manish Negandhi
[TeamSybase]

Do you mean "enable row level access" configuration?  The
ASE is 11.0.3.3 and it is not present.

> On Sep 23, 7:52=a0pm, mkim wrote:
> > The problem was found on the replicate database (ASE).
> > Somehow, the transaction was not executed. =a0Whenever
DML
> > is executed by either maint user or dbo user, it gives
> > prompt back and the transaction didn't happen.
=a0Nothing
> > was written on the error log and there was no return
> > message. =a0We by passed this problem by creating new
> > tables and re-executing materialization. =a0We found one
> > more reason to upgrade!!! Thanks for the helpful tips.
> >
> >
> >
> > > Assuming that you are not replicating to more than one
> > > target and =a0therefore dsi_buf_dump trace is pointing
> > > to the DB that you wanted it to =a0be....
> >
> > > ....some possibilities include:
> >
> > > 1 - servername in interfaces file for RS matches the
> > > destination (and =a0data isn't being applied
elsewhere).
> > > You can turn on the CIS traces in =a0the server in
> > > question to make sure it is receiving the commands ala
> > > =a0dbcc traceon
> > > (3605,11201,11202,11203,11204,11205)....if the ASE log
> > > then =a0contains the same commands as dsi_buf_dump,
you
> know it is receiving the =a0commands.... >
> > > 2 - someone has null'd the rs_commit function string -
> > > so nothing is =a0getting committed (verifiable by
> > > watching monOpenObjectActivity for DBID =a0in question
> > > and see rows inserted/updated/deleted if matching DSI
> > > activity....dsi_buf_dump used to use a default fstring
> > > output so it may =a0not show the problem all the way).
> >
> > > 3 - If triggers are on, or if doing proc replication -
> > > make sure none of =a0the triggers/procs are issuing a
> > > rollback transaction.
> >
> > > m...@xtivia.com wrote:
> > > > The new database is added to the replication system
> > > > but all tables on the RDB are empty. =a0Setreptable
is
> > > > on and there's no uncommitted transaction. =a0It is
> > > > using default action class and there's no loss
> > > > detection. =a0Queue is caught up. =a0We turned on
> > > > "dsi_buf_dump" and it shows on the error log that
> > > > the transaction executed on the PDB is replicated.
> > > > =a0However, the table is again empty on the RDB.
=a0Log
> > > > is not full on both RDB and RSSD. =a0Maint user is
> > > dbo. =a0What else can I take a look at? =a0PDS and RDS
is
> 11.0.3.3, RS is 11.0.3- Hide quoted text - >
>
> Did you have Row level Access implemented at replicate
> side by any chance ?
>
> -Manish Negandhi
> [TeamSybase]