I have a customization that triggers off of an AfterAdapterMethod as per the below. A custom field which is not anywhere in my code always error’s out when I am on our SSO application pool. When I am on the normal application pool, it does not error out. The error i get is:
private void oTrans_imAdapter_AfterAdapterMethod(object sender, AfterAdapterMethodArgs args)
{
// ** Argument Properties and Uses **
// ** args.MethodName **
// ** Add Event Handler Code **
// ** Use MessageBox to find adapter method name
// EpiMessageBox.Show(args.MethodName)
switch (args.MethodName)
{
case "OnChangeToJobSeq":
Is this app pool in a different server? I wonder if you need to regen the datamodel for this aprticular appsever.
Same app server. Desire was to separate SSO and traditional authentication. Regen of datamodel was done from Production application and confirmed in sync when launching UD Column Maintenance from both applications.
1 Like
Only difference I am aware of is net.tcp endpoint binding.
Production (customization works): UsernameWindowsChannel
Production SSO (customization errors): Windows
Production: No custom directory
Production SSO: Empty custom directory but referenced in configuration as AEPL-Custom
- Regen DataModel you have to do on the Database once (if all AppServers share same DB)
-
Recycle IIS you have to do on each Application Server which also will update the DataModel DLL Files. If the column is used in a BPM also on Task Agent App Servers.
- Restart Epicor Client(s).
Also make sure Comment_c is indeed a String, double check it wasnt set by accident to Int.
2 Likes
- Regen of DataModel was done on the database. (We only have 1 AppServer and 1 DB on separate servers).
- We recycled both both Application Pools.
- We run Epicor in a RemoteApp environment and I have done a clear client cache.
The code doesn’t reference Comment_c at all. I can confirm in the udcolumn maintenance that it is still a string. If there was a variable type issue, would it not create an error on both application pools, not just the one?
It may not be in the code, but go in Customization Mode and Export it to an XML, then search XML for Comment_c - or look at the Custom XML Fields… it may be a EpiBinded field to a textbox thats lurking.
1 Like
There is no Comment_c in the entire XML file.
private void oTrans_imAdapter_AfterAdapterMethod(object sender, AfterAdapterMethodArgs args)
{
// ** Argument Properties and Uses **
// ** args.MethodName **
// ** Add Event Handler Code **
// ** Use MessageBox to find adapter method name
// EpiMessageBox.Show(args.MethodName)
switch (args.MethodName)
{
case "OnChangeToJobSeq":
//MessageBox.Show("Change to Job Seq");
var IM = oTrans.Factory("IM");
if(IM == null || IM.Row < 0) return;
if((decimal)IM.dataView[IM.Row]["TranQty"] == 0)
{
decimal toIssue = (decimal)IM.dataView[IM.Row]["QtyRequired"] - (decimal)IM.dataView[IM.Row]["QtyPreviouslyIssued"];
if(toIssue > 0) { IM.dataView[IM.Row]["TranQty"] = toIssue; }
//MessageBox.Show(toIssue.ToString());
if(IM.dataView[IM.Row]["FromWarehouseCode"].ToString() == "51REG1") {
//MessageBox.Show(IM.dataView[IM.Row]["FromWarehouseCode"].ToString());
//IM.dataView[IM.Row]["FromBinNum"] = "";
//IM.dataView[IM.Row]["FromBinNumDescription"] = "";
String ToJobNum = (string)IM.dataView[IM.Row]["ToJobNum"];
String ToAssemblySeq = (string)IM.dataView[IM.Row]["ToAssemblySeq"].ToString();
String ToJobSeq = (string)IM.dataView[IM.Row]["ToJobSeq"].ToString();
EpiTextBox txtFromBinNum;
txtFromBinNum = (EpiTextBox)csm.GetNativeControlReference("4d7e0cd4-7323-48e9-8409-7af91c1b8216");
txtFromBinNum.Focus();
DynamicQueryAdapter dqa = new DynamicQueryAdapter(oTrans);
dqa.BOConnect();
QueryExecutionDataSet qeds = dqa.GetQueryExecutionParametersByID("IssueMaterialHelper");
qeds.ExecutionParameter.Clear();
qeds.ExecutionParameter.AddExecutionParameterRow("JobNum", ToJobNum, "nvarchar", false, Guid.NewGuid(),"A");
qeds.ExecutionParameter.AddExecutionParameterRow("AssemblySeq", ToAssemblySeq, "nvarchar", false, Guid.NewGuid(),"A");
qeds.ExecutionParameter.AddExecutionParameterRow("MtlSeq", ToJobSeq, "nvarchar", false, Guid.NewGuid(),"A");
dqa.ExecuteByID("IssueMaterialHelper",qeds);
DataTable dt = dqa.QueryResults.Tables["Results"];
string toWarehouse = dt.Rows[0][20].ToString();
string toBin = dt.Rows[0][21].ToString();
IM.dataView[IM.Row]["FromBinNum"] = toBin;
}
oTrans.NotifyAll();
}
//MessageBox.Show("Change to Job Seq - Req: " +(IM.dataView[IM.Row]["QtyRequired"]).ToString());
//Focus on OK so they can hit Enter
EpiButton okButton;
okButton = (EpiButton)csm.GetNativeControlReference("43ce5d32-8e77-4d69-9a8e-6c33bd4da434");
okButton.Focus();
break;
}
}
If you have exported the XML and inspected the XML (not just code).
Can you double check in UD Columns Maintenance on Table JobMtl_UD what you have. Worst case I would regen again. Because its enough for the Comment_c to exist in UD Columns Maintenance with wrong type or default value, despite you not using it, it still intializes the DataTable on the UI behind scenes.
Also once you check UD Columns Maintenance, XML you said you checked, you can also post the “Details” of the error. Stack Trace.
1 Like
Well thanks for pushing me to triple check… JobMTL_UD is not in sync. I checked this multiple times on the weekend before we went live and this was synced. I did check this from the Production application pool instance of the Epicor client though, not SSO.
Check your Comment_c types, settings… and atleast you have something to work with… Remember to Recycle all Instances and perhaps redo Regen on or something odd 
If you look at your Server Directory inside Assmblies there is going to be a dll Erp.Data.910100.dll check the Modified Date on both Instances
\\YourServer\EpicorERP\Server\Assemblies
Any ideas why one application pool would see the data model synced and the next wouldn’t?
In my case it happens when I dont Recycle an App Pool… so try just Recycling that App Poll again and then check Erp.Data.910100.dll above ^
I concur with Haso, it’s probably just that a recycle got missed for one of the two appservers. Both have to be independently recycled.
The dates of the Erp.Data DLL do not match when I did the recycle. I’ll check there next time to make sure.
Thanks again for the heads up on the DLL. It was great to be able to check the date modified of both files to ensure it worked as expected. We are back up and running without errors.
