Home > Forum > Database > [Solved] Issues with database connection "subsequently assumed a new security context"

[Solved] Issues with database connection "subsequently assumed a new security context"
0

MVP

Hi everyone,

I was working on a process and out of the blue I receive the following errors:

In BPS Portal / testing a data table:
The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction

In the event viewer there's the following entry:
The connection has been dropped because the principal that opened it subsequently assumed a new security context, and then tried to reset the connection under its impersonated security context. This scenario is not supported. See "Impersonation Overview" in Books Online.

The data table uses "Current BPS database".

Does someone have an idea what could be the cause?

Best regards,
Daniel

MVP

Hi,

the underlying reason was that the SQL statement compared the id of a picker field against an instance id.

So far so usual. Somehow the customer was able to save a value in the field which did not contain the the id. This caused the problems.

No, the field did not allow to save values which are not in the database. Validation was activated too. :)

Best regards,
Daniel

In reply to: Daniel Krüger (Cosmo Consult)

Hi,

the underlying reason was that the SQL statement compared the id of a picker field against an instance id.

So far so usual. Somehow the customer was able to save a value in the field which did not contain the the id. This caused the problems.

No, the field did not allow to save values which are not in the database. Validation was activated too. :)

Best regards,
Daniel

When encountering the error "subsequently assumed a new security context" in a database connection, it typically indicates authentication or permissions issues. Reviewing user privileges, ensuring correct credentials, and verifying network configurations can help resolve this issue, ensuring smooth and secure database connections.

In reply to: Daniel Krüger (Cosmo Consult)

Hi,

the underlying reason was that the SQL statement compared the id of a picker field against an instance id.

So far so usual. Somehow the customer was able to save a value in the field which did not contain the the id. This caused the problems.

No, the field did not allow to save values which are not in the database. Validation was activated too. :)

Best regards,
Daniel

How did you find the corrupt entry in the database?
I'm struggling with similar issues resulting in massive system lagging which can be resolved only by SQL service restart.
I assume I would need to check all picker field entries and look for the faulty one e.g. one without #, right?
In both WFElements and WFElementsHisory. I suppose WFElementDetails and WFElementDetailsHistory as well.
If the reason is the same in my case and I'm able to find the corrupt entry the only solution is to change the value directly in the sql table, right?