When upgrading from Kinetic 2023.1 to 2024.2, conversion "MetaUIMigration" (191) error

Hi all,
I am upgrading our Kinetic from version 2023.1 to 2024.2.
After the first launch, it will launch the Conversion Workbench.
All conversions are complete, except conversion 191 - “MetaUIMigration”.

When I look at the log, the “conversion failed” line only says “Conversion failed” and the last line with error has a message:

Program Ice.Services.Lib.RunTask when executing task 3048040 raised an unexpected exception with the following message: RunTask:
System.Transactions.TransactionAbortedException: The transaction has aborted.
   at System.Transactions.TransactionStateAborted.BeginCommit(InternalTransaction tx, Boolean asyncCommit, AsyncCallback asyncCallback, Object asyncState)
   at System.Transactions.CommittableTransaction.Commit()
   at System.Transactions.TransactionScope.InternalDispose()
   at System.Transactions.TransactionScope.Dispose()
   at Ice.Internal.Conversion.MetaUIMigration.MetaUIMigration.MigrateMetaFxLayers() in C:\_releases\ICE\ICE4.3.200.0\Source\Server\Internal\Conversions\Ice.Internal.Conversion.MetaUIMigration\MetaUIMigration.cs:line 197
   at Ice.Internal.Conversion.MetaUIMigration.MetaUIMigration.RunConversion(Int64 instanceTaskNum) in C:\_releases\ICE\ICE4.3.200.0\Source\Server\Internal\Conversions\Ice.Internal.Conversion.MetaUIMigration\MetaUIMigration.cs:line 59
   at Ice.Core.ConversionTaskBase`1.RunProcess(Int64 instanceTaskNum, String outputFileName) in C:\_releases\ICE\ICE4.3.200.10\Source\Server\Internal\Lib\TaskLib\ConversionBase\ConversionTaskBase.cs:line 69
   at Ice.Core.TaskBase`1.StartProcess(Int64 instanceTaskNum, String outputFileName) in C:\_releases\ICE\ICE4.3.200.10\Source\Server\Internal\Lib\TaskLib\TaskBase\TaskBase.cs:line 84
   at Ice.Hosting.TaskCaller.InnerExecuteTask(IceDataContext newContext) in C:\_releases\ICE\ICE4.3.200.10\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 113
   at Ice.Hosting.TaskCaller.ExecuteTask(IceDataContext dataContext, Boolean suppressTransaction) in C:\_releases\ICE\ICE4.3.200.10\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 47
   at Ice.Services.Lib.RunTaskSvc.<>c__DisplayClass30_2.<InnerRunTask>b__1() in C:\_releases\ICE\ICE4.3.200.10\Source\Server\Services\Lib\RunTask\RunTask.cs:line 465
   at Ice.Lib.RunTask.BpmFriendlyTaskLauncher.Run(String sessionIdPrefix, IceContext db, Action taskRunner) in C:\_releases\ICE\ICE4.3.200.10\Source\Server\Services\Lib\RunTask\BpmFriendlyTaskLauncher.cs:line 57
   at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in C:\_releases\ICE\ICE4.3.200.10\Source\Server\Services\Lib\RunTask\RunTask.cs:line 462

I also created an Epicare Case and sent them this error too, but there is no response at the moment.
Any idea how to resolve this?

1 Like

What happens if you run it again manually?

1 Like

I’ve tried several times already. Still the same result.

You might try and redeploy your app server.
That conversion migrates the file system on the server over to the database. Maybe it’s missing something?

Thank you for the response.

Done. No changes. :frowning:
And now done again with IISRESET and still no changes. :frowning:

Maybe try this suggestion?

@aosemwengie1 it looks like you had the same issue a couple years ago. Do you recall how you got around it?

1 Like

I think I just marked it complete and moved on. In later releases it ran successfully.

1 Like

I’ll have to say I am confused here… I see the version for that conversion is the latest, but I would have expected all kinetic UI stuff would be in the DB already. :person_shrugging:

It would be very handy to understand what this actually does. (yet another rabbit warren)

Looking at the error I wonder if it’s creating deadlock situation when trying write to the database…

Do you have any unsusual data directives enabled that might be related to the destinations.

Bit of a stretch, but as you’ve had a similar problem before… Is your SQL server configured correctly?

When you install the app server, it unzips all of the MetaUI files to the file server.
When you run that conversion, it takes all of those and shoves them into the database so they can be used universally.
Take, for instance, a setup like ours where we have 3 different servers that point to the same database for load balancing. Imagine if the file system was out of sync between the 3? Pop it into the database and it no longer becomes an issue.

1 Like

Makes sense… New stuff has to get into the db somehow.

Hmm I wonder if the notification type setting in the Host.config is respected? :thinking:

I have the newer version 2024.2 and the error occurs less than 1 minute.

I checked the location C:\Epicor\ERP11\ERP11.3.200.0\Server and there are only Server.zip, reports.zip and Epicor.Ice.Version.dll files. There are no subfolders.

If I look to the C:\inetpub\wwwroot\K11Prod\Server\Apps, there is MetaUI and inside MetaIUI there are many subfolders with jsonc files.

In what database table are these files saved?

I checked Host.config file:

<add key="NotificationType" value="database" />

Is this okey?

1 Like

I already have later release. :wink:
I am still waiting for a response from Epicor support.
Maybe they have similar error again!

Yes that should be fine, that’s the default. Really would only have an impact if you had multiple appservers.

Interestingly the third last entry says it completed succesfully, then the next steps it fails…

1 Like

When I look at the Conversion workbench → Conversion Log, it looks like MetaUI migration is successful.

But after that, it tries to do some conversion and the problem is in that conversion.


There is no specific explanation, what is failed! :frowning:
The last line has the exact same error message that I added to my original message.

I currently I have upgrade to 2024.2.10, but I just discovered that there is a newer version 2024.2.11. I will upgrade to this. Maybe there are some improvements there.

No changes. :frowning:

Problem solved.
I found a “Predictive Search” for the JobHead.JobNum field. It was done before me (2017!). It had QuickSearch.IsShared = false, that’s why I couldn’t see it either, the person who did it has long since left.
I set QuickSearch.IsShared = true, then I was able to delete it under Predictive Search Maintenance and the problems disappeared.

3 Likes