The transaction is in doubt

Epicor ERP 10
1

Epicor seems to be suffering from lack of self-esteem.

Did the transaction work or not?

pic1

2 Likes
2

I doubt it :wink:

3 Likes
3

This exception is thrown when an action is attempted on a transaction that is in doubt. A transaction is in doubt when the state of the transaction cannot be determined. Specifically, the final outcome of the transaction, whether it commits or aborts, is never known for this transaction.

Assume no.

2 Likes
4

Thanks. A new error for our users. They are looking for a more confident ERP system. lol

They redid the save and it worked the second time around.

5

Thatā€™s a hoot! Not seen this message before. Anybody else?

6

Schrƶdingerā€™s transactionā€¦

ST

6 Likes
7

Well then your users should rest assured as your ERP system is 100% confident that SQL is unconfident. :stuck_out_tongue:

EDIT: I had to look it up, but, uncondident is actually a word.

3 Likes
8

Iā€™ll let others speak to specifics if they have them, but, from a Support perspective I see single digit cases since the beginning of Support time that reference this error.

Of those:

  • Donā€™t see any references to it as of 10.2.100 reported.
  • More than half are with MRP. The others are around posting engine.
  • (please, save the jokes on this one but) Donā€™t see anything explicit that Support did to ā€œresolveā€ these cases. It seems that the ones I looked at, the issue happened once and didnā€™t occur again so we couldnā€™t really triage the issue that caused the issue the first time :confused:
9

JK :smile: You rock @aidacra

10

At first I was like image but then I was like image

1 Like
11

Nathan,

I found this thread because Iā€™m running into this error in 10.2.100.36. Iā€™m seeing it primarily in integrations that use the REST API, but also occasionally around our last remaining counter that uses a UD table instead of the NextValue API. I havenā€™t heard any reports of the same error message popping up anywhere in the Epicor UI. The rate is about 1-2 errors per day, and I have no way to reproduce it on demand. Iā€™m seeing it on reads, so Iā€™m guessing maybe Iā€™m trying to read something that was written in a previous transaction that has not yet committed. But Iā€™m not seeing any pattern in which reads sometimes get the error, other than the row being read might have been written sometime in the last several seconds to a minute.

I found a blog post about this error that I havenā€™t fully absorbed yet. It sounds like thereā€™s very little I can do to troubleshoot the problem because it probably exists between Epicor and the DB. My control might be limited to tweaking some timeouts or something. But since itā€™s occurring fairly regularly, do you know of anything I can trace in SQL Server Profiler that might provide useful information?