Skip to Content

“DecryptPassword” Error on database failover


We are on SMP3 SP11, using android client 70.11.0. This is on a customized client of SAP Work Manager 6.2. The client is pre-built with an AgentryDB.

We recently moved the SMP DB to an SQL cluster and every time the DB fails over, the prebuilt client fails to login with a “DecryptPassword” error. We have tried the usual of clearing the application cache and force stopping it with no success.

Now the issue is every time the DB fails over we have to build new prebuilt clients, this is redundant and unreliable.

What could possibly be causing this? Does the RSA key change when the DB fails over? What exactly causes this, what changes on the SMP side at this point?

Much appreciated.

Sizo Ndlovu

****SMP is not on a cluster, but the dB is on an sql cluster***

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Apr 12, 2018 at 02:35 PM

    Hi Sizo,

    I would like to support you with respect to SAP Support in General Analysis.

    Given: SMP is not a cluster - BUT - the dB is on a SQL cluster (ex: SQL1 and SQL2).

    Based on the given above, here is your best answer:

    SAP Analysis:

    Each time you have an Agentry SMP client (ex: Client 1)

    Agentry Client 1 --> Syncs to the backend:

    |-- --> SMP 3.0 (SMP will be who are you?):

    |--> Oh you are a new user - from a cleared client, let SMP Agentry create an authentication key for you so that SMP would know you as a valid user (This will prevent collision)

    |------> Saves this to your DB1 (SQL1).

    Now you have an option that your SQL Server DB failed and you have a failed SQL Server backup (SQL 2) <-- SMP 3.0 is now pointing to this DB 2.

    So for this issue, when you sync to the backend, the SMP will now look at SQL2 or DB2 and start comparing your key that was initially created for that device and saved in DB1 and it is missing in DB2 and you would get the error:

    "DecryptPassword” Error on database failover" (basically the key does not match)

    It seems this fail over DB technique needs to have some means to make sure it mimics the main DB1 more often.

    Proposed Solution: Could be a simple Database update wherein an expert Database Administration can properly configure based on the best practice of the company (back up daily, weekly, monthly or others based on workflow case). Please consult your company's DBA for recommendation on the rules of backups. This is a sensitive matter and an expert DBA will give you their best judgment as copying or backing up of gigs or tera size of files may need some special consideration while in production.

    From what I know, some people or customers who are retiring older database (really old version) and going to a new one had to do some special DB process (to get this key) and just transfer to the new DB. This way the clients in the field would not need to clear or rebuild this client (This step is highly not recommended). It happens and the customer had to work with SAP and had to pay for this work.

    This is the best answer I can come up with at this moment.

    Best Regards,

    Mark Pe

    Senior Support - Platinum Engineer
    SAP Support

    Add comment
    10|10000 characters needed characters exceeded