Results 1 to 9 of 9

Thread: DPROP Error -

  1. #1
    Join Date
    Sep 2003
    Posts
    51

    Unanswered: DPROP Error -

    Hi guys,

    I'm getting the following error during replication cycle :
    <CPDOUPD(CA/05)> ASN1001E APPLY "APPLYMAX" : "WorkerThread".
    The Apply program encountered an SQL error. The ERRCODE is "CA0105". The SQLSTATE is "23505".
    The SQLCODE is "-803". The SQLERRM is "SCHEMA.TABLE01". The SQLERRP is "SQLDMISR". The server name is "". The table name is "TABLE01".

    The scenario is :
    1. The dprop is configured right.
    2. The ASN.IBMSNAP_SUBS_COLS is configure ok for this TABLE01. All key fields have the IS_KEY attribute = Y
    3. Application guarantee we do not have dup keys on source database. I've already looked for dup keys .... No dup keys

    Environment:
    AIX - 6.1
    DB2 - "DB2 v9.7.0.4
    DPROP - The Apply version "9.7.4"

    Question : What is the problem ?

    Regards,

  2. #2
    Join Date
    Jan 2007
    Location
    Jena, Germany
    Posts
    2,721
    SQLCODE -803 corresponds to message SQL0803: DB2 Database for Linux, UNIX, and Windows

    There is a violation of a unique constraint on the traget table.
    Knut Stolze
    IBM DB2 Analytics Accelerator
    IBM Germany Research & Development

  3. #3
    Join Date
    Sep 2003
    Posts
    51
    Quote Originally Posted by stolze View Post
    SQLCODE -803 corresponds to message SQL0803: DB2 Database for Linux, UNIX, and Windows

    There is a violation of a unique constraint on the traget table.
    Hi Knut,

    I do know SQLCODE -803 corresponds to a violation of a unique constraint on the target table .. but ... as I mentioned before, I'm using DPROP. Dprop's log file shows the 803 error and I've checked the source DB and there is no DUP KEY there .... This table has a PK only, no unique indexes ....

    The error still there ... Unfortunatelly, your reply did not help me.

    Regards,

  4. #4
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by ajfreitas View Post
    I've checked the source DB and there is no DUP KEY there
    What good does it do, if the error originates on the target? Does the target table have the same structure as the source? Does it have the same constraints as the source? Are you trying to apply changes that have already been applied?

  5. #5
    Join Date
    Sep 2003
    Posts
    51
    Quote Originally Posted by n_i View Post
    What good does it do, if the error originates on the target? Does the target table have the same structure as the source? Does it have the same constraints as the source? Are you trying to apply changes that have already been applied?
    Hi,

    I can guarantee :
    1. Structures are exactly the same (source and target db) (ASNDIFF proves it)
    2. Both tables have the same constraints ( only a PK)

    When you ask : Are you trying to apply changes that have already been applied ? I suppose DPROP should be working fine, so the answer to this question is NO...

    When you ask : if the error originates on the target? ... App should guarantee it is not possible to occur ... and .... App's trace is on and it does not show attemps to insert dup rows into that table ... Besides that, DB2 should not allow dup keys on source table, ( we have a PK there)

    That is why I'm thinking about a DPROP's issue .. but ..

    Regards,

  6. #6
    Join Date
    Apr 2006
    Location
    Belgium
    Posts
    2,514
    Provided Answers: 11
    there is a setting in subscr - so insert will be converted to update if -803 and update to insert if sqlcode 100
    this might help
    otherwise activate the applytrace and see what is being done and why
    Best Regards, Guy Przytula
    Database Software Consultant
    Good DBAs are not formed in a week or a month. They are created little by little, day by day. Protracted and patient effort is needed to develop good DBAs.
    Spoon feeding : To treat (another) in a way that discourages independent thought or action, as by overindulgence.
    DB2 UDB LUW Certified V7-V8-V9-V9.7-V10.1-V10.5 DB Admin - Advanced DBA -Dprop..
    Information Server Datastage Certified
    http://www.infocura.be

  7. #7
    Join Date
    Jan 2007
    Location
    Jena, Germany
    Posts
    2,721
    The problem occurs on the target side because the Apply part raised the error. Maybe someone inserted additional rows in that table and you don't have bi-directional replication set up? Check the data in your target table and yous the trace mentioned by Guy.
    Knut Stolze
    IBM DB2 Analytics Accelerator
    IBM Germany Research & Development

  8. #8
    Join Date
    Sep 2003
    Posts
    51
    Quote Originally Posted by stolze View Post
    The problem occurs on the target side because the Apply part raised the error. Maybe someone inserted additional rows in that table and you don't have bi-directional replication set up? Check the data in your target table and yous the trace mentioned by Guy.
    Hi Knut,

    here we go :

    1. We dont have bi-directional replication
    2. Our target DB is used only to generate reports. Users don't have insert/update grants on the target DB. Data on target DB can only be selected
    3.Data on source DB is ok. No dup keys there
    4. I've already turned the trace on ....Just waiting, trying to catch some problem

    Thanks

  9. #9
    Join Date
    Jan 2007
    Location
    Jena, Germany
    Posts
    2,721
    Well, you do have a unique constraint violation on the target system. You'll have to figure out where those rows came from. You may also want to consider using "asndiff" or similar to compare the content of source and target tables.
    Knut Stolze
    IBM DB2 Analytics Accelerator
    IBM Germany Research & Development

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •