Reviewed the case: if the analyst currently working on the issue can’t repro the issue with the latest backup of your database provided earlier today, then it would be an issue my team would pursue. I suspect though that the analyst will be able to repro the issue based on the error and the apps development team will ultimately provide the resolution.
1 Like
You have the stack trace? That should speed up analysis
We will make sure it is in the ticket. This is it:
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: The underlying provider failed on EnlistTransaction.
Stack Trace:
at System.Data.EntityClient.EntityConnection.EnlistTransaction(Transaction transaction)
at System.Data.Objects.ObjectContext.EnsureConnection()
at System.Data.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption)
at System.Data.Objects.ObjectQuery`1.System.Collections.Generic.IEnumerable<T>.GetEnumerator()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
at System.Data.Objects.CompiledQuery.ExecuteQuery[TResult](ObjectContext context, Object[] parameterValues)
at Epicor.Data.DBExpressionCompiler.GetResult[TContext,TQuery,TResult](Func`3 executeQuery, Cache cacheSetting, TContext dataContext, TQuery query) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Data\DBExpressionCompiler.cs:line 441
at Epicor.Data.DBExpressionCompiler.InvokeSingle[TContext,TQuery,TResult](Expression expression, Cache currentCacheSetting, Boolean cacheQuery, TContext dataContext, Func`2 getDataCacheKey, Func`2 compileQuery, Func`3 executeQuery) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Data\DBExpressionCompiler.cs:line 302
at Epicor.Data.DBExpressionCompiler.<>c__DisplayClass34_0`4.<Compile>b__0(TContext context, TArg1 arg1, TArg2 arg2) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Data\DBExpressionCompiler.Generated.cs:line 1110
at Erp.Internal.Lib.JobRcpnt.DoPerson(String In_PersonId, Int32 In_AlertNum) in c:\_Releases\ERP\RL10.1.500\Source\Server\Internal\Lib\JobRcpnt\JobRcpnt.cs:line 225
at Erp.Internal.Lib.JobRcpnt._JobRcpnt(String In_JobNum, Int32 In_AlertNum, String In_EmailList, String& RcpntList) in c:\_Releases\ERP\RL10.1.500\Source\Server\Internal\Lib\JobRcpnt\JobRcpnt.cs:line 118
at Erp.Internal.Lib.XAP05.Do_1150(String In_ParmList, Int32 In_AlertNum) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\Lib\Shared\XAP05\XAP05.cs:line 1794
at Erp.Internal.Lib.XAP05._XAP05(Int32 In_AlertNum, String In_ParmList, String& VContinue) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\Lib\Shared\XAP05\XAP05.cs:line 420
at Erp.Internal.Lib.JobOperWrite._JobOperWrite(JobOper JobOper, JobOper OldJobOper, Boolean RollUp) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\Lib\JobOperShared\JobOperWrite\JobOperWrite.i.cs:line 1013
at Erp.Internal.Lib.JobOperShWrite.DoJobOper(JobOper JobOper, JobOper OLDJobOper) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\Lib\JobOperShared\JobOperShWrite\JobOperShWrite.cs:line 1298
at Erp.Triggers.JobOper.WriteTrigger.write(JobOper JobOper, JobOper OldJobOper) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Db\Triggers\JobOper\write.cs:line 221
at Ice.Triggers.TriggerQueue.ExecuteWriteTrigger(IceDataContext context, LinqRow modifiedRecord, LinqRow originalRecord) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 296
at Ice.Triggers.TriggerQueue.RunWriteTriggerInNewLevel(IceDataContext context, LinqRow modifiedRecord, LinqRow originalRecord, Boolean forAddedRow) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 157
at Ice.Triggers.TriggerQueue.<>c__DisplayClass11_0.<RunWriteTrigger>b__1() in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 148
at Ice.Triggers.TriggerQueue.RunAtNewLevel(Func`1 buildTriggerRunState, Action action) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 501
at Ice.Triggers.TriggerQueue.RunTriggers(IceDataContext context) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 83
at Ice.IceDataContext.RunUntilAllTriggersHaveExecuted() in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Data\IceDataContext.cs:line 542
at Ice.Triggers.TriggerQueue.RunAtNewLevel(Func`1 buildTriggerRunState, Action action) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 501
at Ice.IceDataContext.Validate[TLinqRow](TLinqRow row) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Data\IceDataContext.cs:line 299
at Erp.Triggers.LaborDtl.WriteTrigger.Write(LaborDtl LaborDtl, LaborDtl OLaborDtl) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Db\Triggers\LaborDtl\Write.cs:line 1525
at Ice.Triggers.TriggerQueue.ExecuteWriteTrigger(IceDataContext context, LinqRow modifiedRecord, LinqRow originalRecord) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 296
at Ice.Triggers.TriggerQueue.RunWriteTriggerInNewLevel(IceDataContext context, LinqRow modifiedRecord, LinqRow originalRecord, Boolean forAddedRow) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 157
at Ice.Triggers.TriggerQueue.<>c__DisplayClass11_0.<RunWriteTrigger>b__1() in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 148
at Ice.Triggers.TriggerQueue.RunAtNewLevel(Func`1 buildTriggerRunState, Action action) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 501
at Ice.Triggers.TriggerQueue.RunTriggers(IceDataContext context) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Triggers\TriggerQueue.cs:line 83
at Ice.IceDataContext.RunUntilAllTriggersHaveExecuted() in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Data\IceDataContext.cs:line 542
at Erp.Internal.Lib.BFLaborD.CreateProduction() in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\Lib\BFLaborD\BFLaborD.cs:line 380
at Erp.Internal.Lib.BFLaborD.processLaborDtl(Guid LaborDtlRowid, String& oMessage) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\Lib\BFLaborD\BFLaborD.cs:line 220
at Erp.Internal.Lib.BFLaborD._BFLaborD(Guid LaborDtlRowid, String& oMessage) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\Lib\BFLaborD\BFLaborD.cs:line 139
at Erp.Internal.JC.BackflushLaborProcess.RunProcess(Int64 InstanceTaskNum, String OutputFileName) in D:\_Releases\ERP\UD10.1.500.31\Source\Server\Internal\JC\BackflushLaborProcess\BackflushLaborProcess.cs:line 174
at Ice.Hosting.TaskCaller.InnerExecuteTask(IceDataContext newContext) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 93
at Ice.Hosting.TaskCaller.ExecuteTask() in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 54
at Ice.Lib.RunTask.BpmFriendlyTaskLauncher.Run(String sessionIdPrefix, IceContext db, Action taskRunner) in D:\_Releases\ICE\3.1.500.31\Source\Server\Services\Lib\RunTask\BpmFriendlyTaskLauncher.cs:line 63
at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in D:\_Releases\ICE\3.1.500.31\Source\Server\Services\Lib\RunTask\RunTask.cs:line 526
Inner Exception:
The partner transaction manager has disabled its support for remote/network transactions. (Exception from HRESULT: 0x8004D025)
Stack Trace:
at System.Transactions.Oletx.OletxTransactionManager.ProxyException(COMException comException)
at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
at System.Transactions.TransactionStatePSPEOperation.PSPEPromote(InternalTransaction tx)
at System.Transactions.TransactionStateDelegatedBase.EnterState(InternalTransaction tx)
at System.Transactions.EnlistableStates.Promote(InternalTransaction tx)
at System.Transactions.Transaction.Promote()
at System.Transactions.TransactionInterop.ConvertToOletxTransaction(Transaction transaction)
at System.Transactions.TransactionInterop.GetExportCookie(Transaction transaction, Byte[] whereabouts)
at System.Data.SqlClient.SqlInternalConnection.GetTransactionCookie(Transaction transaction, Byte[] whereAbouts)
at System.Data.SqlClient.SqlInternalConnection.EnlistNonNull(Transaction tx)
at System.Data.SqlClient.SqlInternalConnection.Enlist(Transaction tx)
at System.Data.SqlClient.SqlInternalConnection.EnlistTransaction(Transaction transaction)
at System.Data.SqlClient.SqlConnection.EnlistTransaction(Transaction transaction)
at Epicor.Data.Provider.EpiConnection.EnlistTransaction(Transaction transaction) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Data\EpiProvider2\EpiConnection.cs:line 209
at System.Data.EntityClient.EntityConnection.EnlistTransaction(Transaction transaction)
at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in D:\_Releases\ICE\3.1.500.31\Source\Server\Services\Lib\RunTask\RunTask.cs:line 526
at Ice.Services.Lib.RunTaskSvcFacade.RunTask(Int64 ipTaskNum) in D:\_Releases\ICE\3.1.500.31\Source\Server\Services\Lib\RunTask\RunTaskSvcFacade.cs:line 87
at SyncInvokeRunTask(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at Epicor.Hosting.OperationBoundInvoker.InnerInvoke(Object instance, Func`2 func) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Hosting\OperationBoundInvoker.cs:line 59
at Epicor.Hosting.OperationBoundInvoker.Invoke(Object instance, Func`2 func) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Hosting\OperationBoundInvoker.cs:line 28
at Epicor.Hosting.Wcf.EpiOperationInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) in D:\_Releases\ICE\3.1.500.31\Source\Framework\Epicor.System\Hosting\Wcf\EpiOperationInvoker.cs:line 23
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
at System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext request, Boolean cleanThread, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext request, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult result)
at System.ServiceModel.Dispatcher.ChannelHandler.OnAsyncReceiveComplete(IAsyncResult result)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.SecurityChannelListener`1.ReceiveItemAndVerifySecurityAsyncResult`2.InnerTryReceiveCompletedCallback(IAsyncResult result)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.TransportDuplexSessionChannel.TryReceiveAsyncResult.OnReceive(IAsyncResult result)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.SynchronizedMessageSource.ReceiveAsyncResult.OnReceiveComplete(Object state)
at System.ServiceModel.Channels.SessionConnectionReader.OnAsyncReadComplete(Object state)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.Security.NegotiateStream.ProcessFrameBody(Int32 readBytes, Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.NegotiateStream.ReadCallback(AsyncProtocolRequest asyncRequest)
at System.Net.AsyncProtocolRequest.CompleteRequest(Int32 result)
at System.Net.FixedSizeReader.CheckCompletionBeforeNextRead(Int32 bytes)
at System.Net.FixedSizeReader.ReadCallback(IAsyncResult transportResult)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.ConnectionStream.IOAsyncResult.OnAsyncIOComplete(Object state)
at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs e)
at System.Net.Sockets.SocketAsyncEventArgs.FinishOperationSuccess(SocketError socketError, Int32 bytesTransferred, SocketFlags flags)
at System.Net.Sockets.SocketAsyncEventArgs.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)The team currently working on it was not able to repro the issue on Epicor’s end. This has happened before and sucks because we seem to drop into no mans land and are left to fend for ourselves.
We are in desperate need of assistance to get this issue resolved. If there is anything you can do to push this along that would be great.
It’s not no mans land if you have it repro on your side without BPM - it just needs a little encouragement to help it along that you are continuing to provide (I assume).
If it can’t be repro’d within Support, that is more or less the end of the application support triage as they work with the base application.
When we bring a database in-house, my DB Load team executes a tailoring database script to allow it to work within our environment. As of 10.1, the script does the following–one of them could be your X-factor.
WE REMOVE:
- any pending shop warnings
- system monitor records (systask, sysrptlst, etc)
- user account lockouts
- any existing pointers to taskagent configurations within the customer’s environment
WE DISABLE:
- UI tracing on user records
- solution workbench tracking
- all BPMs <-- this should be tested in a customer’s environment before uploading the database to support
- tax connect (if applicible)
- system agent schedules
- taskagent rules
- the SSRS override on the company record
- require SSO on user records
WE UPDATE(OR CREATE):
- a security manager user record that it can be used with the system agent taskagent configuration, login via the client <–NOTE: the user on the system agent/taskagent doesn’t need to be a security manager and best practices would be NOT to have it be one
- the system agent to work with our epicordata folder shares and remove the appserverURL as it isn’t needed in our environment
- the company records to set the work station method to Machine name + Domain User <-- everyone should do this in their environment, the report type preference to SSRS if Crystal was set, and to use a local file share for file attachments (if applicable)
- the menu to expose the data fix workbench and conversion workbench if they were disabled/removed/not where they should be by default
WE COMPLETE AS NEEDED:
- apply an internal support license <-- not common
EDIT:
We only load databases at the latest point update for the release that the database is currently on. So, as of today, any 10.1.400.x database processed by support would be loaded at 10.1.400.38, for 10.1.600.x that would be 10.1.600.18 (etc).
@aidacra
If application support triage has reached the end of their support, how does our case move on to the next team? Who helps us figure out our X-factor?
Application support’s primary initial objective when testing an issue is to determine if the behavior is intended or not, and if not, if the cause is due to the base application or (generically) “something else”. Based on their testing the cause is not the base application at the latest point update so must be “something else”.
When this happens, we have to determine what could be unique with how a customer is running the application in their environment vs how Support does. The X-factor could be one of the items I listed yesterday regarding the steps a customer database goes through when we load it within Support.
- Have you disabled all BPMs in your testing environment and retested?
- Have you applied the latest point update in your testing environment and retested? As of today that is 10.1.500.33
- …
We disabled all BPMs and retested and the result is still the same. We have not tested .33.
Are you unable to test with our custimizations still on? Are you able to test at .31?
Upgrading is ever easy. We run through a whole testing process that can take weeks. Every upgrade we have applied fixed some issues but always introduces new ones. We actually found 2 issues when we migrated from 10.1.500.12 to 10.1.500.31 that have been acknowledged as new bugs and scheduled to be fixed in 10.2.200. 
We aren’t suggesting you upgrade your production to .33, just an environment that isn’t production with a backup of your current live database to determine if this one issue is resolved in the new release.
We upgraded our testing environment to 10.1.500.33 and it still fails. Now what is the next step?
I provided a list of the things that support does when we bring a database in-house. How many of them have you eliminated?
Additionally, as you are working with Support I would recommend you reach out to the analyst you are already working with regarding your testing your findings so they can assist you in determining appropriate next steps if you haven’t done so already.
Thanks for all your support. It has been really frustrating for us.
- Support has webex’ed numerous times and has not been able to figure it out.
- We get the issue with all BPM’s and customizations turned off.
- We have upgraded to .33 and the issue still occurs. Even with BPM’s and customizations turned off.
- The same jobs always fail in our Live environment and even in our pilot environment after we refresh with Live.
- Today Support did a webex and ran performance diagnostics on our Epicor servers. They didn’t find anything alarming at first glance. They are still reviewing the results.
We have not tried the other items on your (@aidacra) list because we don’t know how. We take it one step at a time keep asking/calling to inquire the next step.
On top of everything, not every support person updates the case ticket with what they did nor do they call us back after they say they are going to. That makes working with support extremely difficult.
We don’t understand it but found what was causing the issue. We have a simple global alert that was recently created by our customer service. It was to create a memo and send alert when “Operation has been completed”. It had a from email address and a label, “51 Completed”. It was set to go to a email with text that red “Please Flip Quote”.
When this alert is active, our backflush hangs on select jobs. If we deactivate, backflush runs with no issues.
We are working with support with this issue. The reason this was not identified on the Epicor system was because the support person noticed the process hung when they first ran it for us on our uploaded db. They communicated to the tech team and the tech team did something, and then from that point on support had no issue running backflush with or without the alert on. Support was able to identify that they too can get the backflush process to hang and is fixed somehow when she tells the tech team to restart the task agent because a process hung. The support person feels the tech team does something more than just restart the task agent but it has not been communicated.
Still investigating.
Very odd. This was a BPM?
no bpm. Native global alerts.
Well we pretty much got the "sorry, we can’t help you’ from Epicor.
Epicor is able to replicate the issue using our DB however they are not able to in their environment. We were told by support that since development was not able to replicate the issue in their environment that it will be unlikely that we will get a root cause or solution.
I am doing my best not to start venting but this is a prime example of what happens to us time and time again. Now we are unable to use another global alert. We already are unable to use the global alert when a task has been completed (Case CS0000573759 that turned into PRB0190899 which they rejected a fix for 10.1.500.x) and now the global alert for when an operation has been completed.
The support on the phone apologized and said there is nothing much we can do. We will not get an answer as to the what and why to our problem. She said we will just have to stop using global alerts.
…(sigh)… deadend. 
Hi Nathan,
I am particularly interested in the disabling of BPM and removing the form customization. Is this script available for us to use as well?
If yes, it will be a great help to us and probably other customers to reduce the load on Epicor support and do more due diligence on our own before escalation.
Right now manually to consistently do all of the above you mentioned is tricky.
The challenge I have is that anything I publicly put into the world seems to automatically make it something I have to personally support until the end of times–doesn’t matter the disclaimers I put on it or the caveats included that explain only do this if that else don’t ever to this.
Here is a dramatized reenactment of a situation I found myself in not so long ago:
“@aidacra posted something eight years ago for a product that hasn’t been updated for seven years, and I just ran against a database for a product that was just released today and something bad happened to my database, @aidacra has to fix it! No, I didn’t read the obvious disclaimer at the top! Or, the “don’t do this without testing it” in the middle of the comment. No, I didn’t backup my database first–why would I have backed up my database first if @aidacra said it was ok eight years ago for an earlier product?!..” --Anonymous
Needless to say, I’m always a little hesitant to publish certain things because I’ve been more than once bitten twice shy by things that would be fine for 99.9% of situations without any modification, but, it’s the 1 out of 1000 where the information provided can actually cause harm unless it is fully understood that I worry about because I don’t want to ever negatively impact anyone by something I say or post–even if I really try to warn people about the 1 in 1000 situation.
That being said, after seeking sage guidance from my resident expert and housemate, if you all pinky swear promise to the following:
- don’t ever attempt anything that some random internet person tells you unless you have a 100% fool-proof way of reverting it (aka: don’t do stuff in production unless you are completely sure of what it is ACTUALLY going to do by testing it first, and never do anything permanent against a database without backing up your database beforehand).
- that any *past, present or future kerfluffles that potentially could maybe happen because of what I’m about to post is the end users’ responsibility. (aka: it is provided as-is with no support whatsoever for what comes from executing it).
- you really accept the fact that Support cannot help you with anything that the script does or doesn’t do.
*time travel could be a thing in the future, and I want to be covered
below is a link to the majority of the tailor db script with some of my sanitized internal comments as to what that statement is generically doing when we execute a script like this against a customer database when we bring it in-house. You will also find a really long disclaimer and the script as provided when executed in its entirety will not actually do anything against a database. For those with experience with TSQL the changes needed to make it work should be straightforward–if you can’t identify the changes needed, then you really shouldn’t be using this script and is best to just not(truly sorry about that, but, it’s really for your own good). I would greatly appreciate no one publicly stating what the changes needed to make the script work in its entirety or republishing this script (or even a subset of the script) on this site, or elsewhere.
Link to the partial tailor db script is here.
Please community, don’t break my heart and take this something I put out there for the betterment of those that can safely use it and hurt yourself.
3 Likes