It may be too late to chime in, but does your old server have an X3.AUDITH table? I'm on version 9 and I have 12 in a test environment, and I don't have X3.AUDITH.

Surprisingly on old server there is no X3.AUDITH table as well. This table is only available in production and not reference folder making the error message very strange indeed.

If it's actual X3 code that's doing something silly, I suppose you'd have to take that up with Sage. I don't have access to the source code so I can't see what TRTLIC is doing on line 223. If this is on the SQL Server side, which the error suggests, meaning that auditing is set up on one or more X3 tables - I suppose I'd try to track down which tables have auditing, then comment that out of the specific database triggers. I would think that would be enough to at least let you log in to X3, then remove the auditing and re-validate those tables properly.

I used the query here to search for 'AUDITH', which should find triggers doing some kind of auditing. Specifically you want to find tables with triggers in the X3 schema: stackoverflow.com/.../how-to-find-a-text-inside-sql-server-procedures-triggers

The X3.ATABAUD table shows which specific fields have auditing set up. Mine has six entries, five in TABVAT and one in ECCSTA, but I've never had any issues.

Or I'm barking up the wrong tree entirely. In V12 I tried to add auditing to tables from the X3 folder, and although it saved and validated, it didn't actually create the database triggers. Maybe in older versions it would?

Thank you very much for this tip. Have managed to resolve issue.Using the SQL Query above we identified the tables that had triggers on new server but didnt have on old server.

Not sure how the triggers were created in first place but deactivating these triggers was the answer and now everything is working as expected. Previously we couldnt log in to X3 reference folder but now old good