Errors in Sync
Generic Error

TL;DR

We continue to try to get better information to help solve these when you get them and we are still trying to fully understand what we can/can't do to help.

As at 2026.02 it has been more than 2 years since one has been reported to us, but it doesn't mean it can't happen still.

When MCe, during the sync:

Our experience is that it is so far always caused by a rule/notification that either:

  • doesn't like something about 'the data' or
  • doesn't like something about the recent changes (by the upgrade) in the table definitions (Note for technical people: In the DDL.

Known causes:

Cause 1: rule never used to fire

We've seen it when your rule was written but never triggered/tested until we started 'doing more' which then caused it to fire.

Cause 2: rule didn't handle a change in the schema

When Accruent or we add a table, or column, or constraint etc.., your rule isn't flexible enough to handle the change

With Accruent we have an agreement that:

  • we can add columns to any table.
    • If it is a row version identity (timestamp) both companies agreed they would name it exactly RowVersionIdentity (because you can only have ONE of that type of column on a given table.)
    • otherwise, we append 'aps' to the beginning of the column name
  • we can add new tables
    • we append 'aps' to the beginning of the table name, but the columns do not require any special naming
  • we can add new views
    • we append 'mce' to the beginning of the view name, but the columns do not require any special naming

Through the last decade+ this has caused very few problems … occasionally a rule/notification has a problem because it wasn't expecting these types of changes.

Accruent can also add tables, new columns, even change the functional definition of a column, and same as above, this can occasionally cause a rule/notification to have a problem because it wasn't expecting these types of changes.

Cause 3: Database configuration error

This particular error is the most generic one that generally happens when it isn't a data error but a database configuration error.

Specifically, the error is: The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.

This type of error is caused by a rule or notification throwing an error during a valid data update. A rule throwing an error causes valid data to fail entirely and it is impossible for an end user to continue.

All of these mean a user who experiences the error can't fix it

What I am trying to say is this type of error isn't usually fixable by the user who experienced it, but requires the rule or notification that is creating the error to be fixed. This would typically be senior administrators, and often requires professional services to delve in and find the rule that is causing the problem.

Collected notes:

A generic error is one that isn't otherwise known to us. The full available details can be retrieved by selecting the expand button on the right. It may not be much but it may be key.

Real life example:

We had an error reported from the expand button. The human description of the error is: "The current transaction cannot be committed and cannot support operations that write to the log file."

Looking up this error online it is a trigger bug in MC. There is a data error occurring but that is causing a second bug in MC to trigger and instead of getting a useful error you get that one.

Specifically, they were executing SQL inside a try/catch to prevent UI errors if the SQL statement is bad. The problem is that catching a SQL error inside a trigger (as was happening) doesn't work and results in the entire process failing.

It was a Rule with the "[EVENTRECORD]" not set up correctly. This was on a Rule updating the WO part that had been correctly added via MCe. The Rule had a 'WO View' as its trigger so when we first noticed it we didn't think it would be called into action by a MCe sync, but is hard to tell what trigger action a rule uses.

Being able to update WP parts costs is critical to launching MCe. As there was no Rule trigger for WO parts transactions we had to use 'WO View' as a trigger and then update all WP parts that had $0 as the cost. We also ran into some NULL values which should not have been the case, but it was easier to write the SQL to prevent NULL from being used in the update. In the end the SQL that is working is:

UPDATE WOPart
SET 
    WOPart.IssueUnitCost =
        CASE WHEN (
            SELECT Part.IssueUnitCost
            FROM  Part 
            WHERE WOPart.PartPK = Part.PartPK) ISNULL
        THEN 0 
        ELSE (
            SELECT Part.IssueUnitCost
            FROM  Part 
            WHERE WOPart.PartPK = Part.PartPK)
        END,
    WOPart.TotalCost =(WOPart.QuantityActual * WOPart.IssueUnitCost),
    WOPart.IssueUnitChargePrice = 
        CASE WHEN (SELECT Part.IssueUnitChargePrice
            FROM  Part 
            WHERE WOPart.PartPK = Part.PartPK) ISNULL
        THEN 0 
        ELSE (
            SELECT Part.IssueUnitChargePrice
            FROM  Part WHERE WOPart.PartPK = Part.PartPK)
       END,
    WOPart.TotalCharge = (WOPart.QuantityActual * WOPart.IssueUnitChargePrice)
WHERE (WOPart.IssueUnitCost = 0)