Error Approving Product Configurator

I have had a ticket open with Epicor since September 24th and they still haven’t figured out what’s wrong. Hoping that someone here has run into this or has a solution. We get the following error when approving our PC.

Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask:
System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. ---> System.Data.SqlClient.SqlException: Lock request time out period exceeded.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption, Boolean shouldCacheForAlwaysEncrypted)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
   at System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget target, Func`3 operation, TInterceptionContext interceptionContext, Action`3 executing, Action`3 executed)
   at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.Reader(DbCommand command, DbCommandInterceptionContext interceptionContext)
   at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
   --- End of inner exception stack trace ---
   at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
   at System.Data.Entity.Core.Objects.Internal.ObjectQueryExecutionPlan.Execute[TResultType](ObjectContext context, ObjectParameterCollection parameterValues)
   at System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1 func, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction, Boolean releaseConnectionOnSuccess)
   at System.Data.Entity.Core.Objects.ObjectQuery`1.<>c__DisplayClass7.<GetResults>b__5()
   at System.Data.Entity.Core.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption)
   at System.Data.Entity.Core.Objects.ObjectQuery`1.<System.Collections.Generic.IEnumerable<T>.GetEnumerator>b__0()
   at System.Data.Entity.Internal.LazyEnumerator`1.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Epicor.Data.DBExpressionCompiler.GetResult[TDataContext,TQuery,TResult](Func`3 executeQuery, Cache cacheSetting, TDataContext dataContext, TQuery query) in C:\_Releases\ICE\UD10.2.600.14FW\Source\Framework\Epicor.System\Data\DBExpressionCompiler.cs:line 429
   at Epicor.Data.DBExpressionCompiler.InvokeList[TDataContext,TQuery,TResult](Expression expression, Cache currentCacheSetting, Boolean cacheQuery, TDataContext dataContext, Func`2 getDataCacheKey, Func`2 compileQuery, Func`3 executeQuery) in C:\_Releases\ICE\UD10.2.600.14FW\Source\Framework\Epicor.System\Data\DBExpressionCompiler.cs:line 160
   at Epicor.Data.DBExpressionCompiler.<>c__DisplayClass2_0`4.<Compile>b__0(TContext context, TArg1 arg1, TArg2 arg2) in C:\_Releases\ICE\UD10.2.600.14FW\Source\Framework\Epicor.System\Data\DBExpressionCompiler.Generated.cs:line 82
   at Erp.Internal.PC.RegenConfigurators.SetPartRevConfig(String iConfig, ConfiguratorDefSvcContract configDefBO, Boolean allRegen) in C:\_Releases\ERP\RL10.2.600.0\Source\Server\Internal\PC\RegenConfigurators\RegenConfigurators.cs:line 360
   at Erp.Internal.PC.RegenConfigurators.ImmediateRegen(ConfiguratorDefSvcContract configDefBO) in C:\_Releases\ERP\RL10.2.600.0\Source\Server\Internal\PC\RegenConfigurators\RegenConfigurators.cs:line 233
   at Erp.Internal.PC.RegenConfigurators.RunProcess(Int64 instanceTaskNum, String outputFileName) in C:\_Releases\ERP\RL10.2.600.0\Source\Server\Internal\PC\RegenConfigurators\RegenConfigurators.cs:line 141
   at Ice.Core.TaskBase`1.StartProcess(Int64 instanceTaskNum, String outputFileName) in C:\_Releases\ICE\UD10.2.600.14FW\Source\Server\Internal\Lib\TaskLib\TaskBase\TaskBase.cs:line 83
   at Ice.Hosting.TaskCaller.InnerExecuteTask(IceDataContext newContext) in C:\_Releases\ICE\UD10.2.600.14FW\Source\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 117
   at Ice.Hosting.TaskCaller.ExecuteTask() in C:\_Releases\ICE\UD10.2.600.14FW\Source\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 59
   at Ice.Lib.RunTask.BpmFriendlyTaskLauncher.Run(String sessionIdPrefix, IceContext db, Action taskRunner) in C:\_Releases\ICE\UD10.2.600.14FW\Source\Server\Services\Lib\RunTask\BpmFriendlyTaskLauncher.cs:line 63
   at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in C:\_Releases\ICE\UD10.2.600.14FW\Source\Server\Services\Lib\RunTask\RunTask.cs:line 452

Hi Chadd,

Have you tried duplicating the Config ID & approving the new Cfg? If that works then likely the issue lies in the method rules, otherwise the issue is UD method code or Document rule code, or perhaps a Part Creation setting.

1 Like

I can’t say we had that error, but we would occasionally do something like what @rbomford suggested. We would export the configurator then import it.

1 Like

I would agree with export/delete/import again for sure, but it seems to be a SQL Exception (I’m not great at interpreting those messages though), so I would look in the sql server for an orphaned session that is holding a lock on that row… perhaps the query on this page will help…


With the help of our PC consultant we did the following but still getting the error. Any other ideas?

  1. Removed all parts from current configurator
  2. Approved the configurator, got error (all we should be dealing with are document rules)
  3. Created a new configurator
  4. Import everything EXCEPT document and method rules
  5. Approved configurator, no errors
  6. Imported document rules
  7. Approved configurator, no errors
  8. Went back to original configurator
  9. Import just the document rules,
  10. Approved configurator, original error.

Was there a chance that was done to the document rules that would impact how the method rules are behaving?

I’m sorry, I don’t have any more ideas. It seems like it could be a bug, but you would have to replicate it on demand to get going fast with Epicor support.

I sent Epicor a copy of our database a month ago. They are able to recreate it on their end with our dB. But they just keep sending us in circles checking things on our server hosts and changing config file values. It’s getting really frustrating.

I don’t like being in that position. You can always try and escalate the case if you are not happy with the results.

Tried that. It just got assigned to the same person :roll_eyes:

We are attempting to go live on 10.2.600 and this is the only hold up at this point.

Ah, I feel your pain. We couldn’t get MRP to run for a month when going from 9 to 10.1 and it pushed out our go-live date till they finally found that it was invalid characters in some part numbers that caused it to crash.

1 Like

I am interested to hear what it ends up being though if you get a PB or just a fix.

I will post the fix from them for sure. Hopefully it can save someone else a month + of going back and forth.

The error message is more cryptic than usual… Normally any SQL lock error I’ve run into is resolved with a reboot of the SQL server or by going in and trying to kill the right SPID. I wouldn’t expect a lock error to persist like this, especially if Epicor can recreate it when standing up your db…

Here’s a crazy thought – I once had a configurator issue trying to save a UD method or something and kept getting compile errors. Eventually I realized the errors were coming from a configurator I wasn’t even working on. Maybe there is another configurator in your system that is actually the culprit? I know it sounds crazy but stranger things have happened.

And the SQL server has been rebooted since we got this error. So I don’t think it’s a lock issue. Our SQL monitoring tool also checks for locks and logs them. It’s not reporting any locks either. So I think it’s something deeper. We also only have a single configurator. Good idea though on the others causing issues.

Update - 11/5/2020

This is a bug in 10.2.600. Epicor opened PRB0229118/ERPS-150499 for it. No ETA on a fix. Until this is fixed our 10.2.600 upgrade is on-hold. :unamused:

Chad, thank you for reporting back.

What are the details? Is there any workaround or way to avoid it?

It’s a timeout issue Epicor said. They are not sure where in the approval process it’s happening specifically. The most recent update from Epicor was to continue on with the 600 upgrade and us the PC even with the error. They were confident that the error was not going to prevent using it or it functioning correctly. So, we are now again planning to go live with the error. If we run into issues Epicor will have to support it. Since we have in writing them approving moving forward with the error.