Urgent! LotSelectUpdate reference

There is a compile Error in E10.2.400

Error: CS0246 - line 44 (693) - The type or namespace name ‘LotSelectUpdate’ could not be found (are you missing a using directive or an assembly reference?)

I can’t find out which reference i missed. It is so urgent. can anybody help me on this?

Thanks so much in advance. My code is at below:
using System;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Windows.Forms;
using Ice.Lib;
using Erp.BO;
using Ice.BO;
using Erp.Proxy.BO;
using Erp.UI;
using Ice.Adapters;
using Erp.Adapters;
using Ice.Lib.Customization;
using Ice.Lib.ExtendedProps;
using Ice.UI.FormFunctions;
using Ice.Lib.Framework;
using Ice.Lib.Searches;
using Erp.Contracts;

public class Script
int classValid = -1 ;
string company = “”;
bool trackLots = false;
LotSelectUpdate lotBo ;

One thing that may be handy to figure this out would be the Business Object Reference documentation that you can find on Epicweb. Go to Products > Epicor ERP version 10 > Release: 10.2.400 > Deliverable: Technical Reference > ERP_BO_Ref_102400. This is a CHM file which provides reference to the Epicor business object assemblies. In the CHM file, go to the Search tab and search for “LotSelectUpdate”. If you open this file from a network drive, the right-hand pane may be blank. If so, copy it to a local drive and open it from there.

I don’t work with customizations so my question could be invalid but, can we see which assemblies are referenced?

Can you try to use Erp.BO.LotSelectUpdate instead of just LotSelectUpdate?

Yes. In Customization Maintenance, use Tools > Assembly Reference Manager

Thanks for your reply. Yes, please help to check it at below.

Thanks. this is my reference screen.

Thank you, Greg.

But I can’t find out the solution in this document. Seeking for your more advice. thanks.

using Erp.BO;
using Erp.Contracts;

Thanks Chris. You can see my code.I had these two, But it doesn’t work.

@josecgomez could you help to check it? sorry ti disturb you, but It is realy urgent for me. Thanks a lot in advance.

The problem is you cant call a BO in a customization that way. You need to use the LotSelectUpdateAdapter

var lsa = new LotSelectAdapter(oTrans);
//do stuff


Thanks a lot for your reply. My code was migrated from E9. I will try the adapter as per your advice.

Hi, Chris,

I tried it and it works.

Thank you.
Best regards,

1 Like

To be fair, you CAN call a BO without having to use the adapter. But you need to instanciate it like so:

using (var bo = WCFServiceSupport.CreateImpl<LotSelectUpdateImpl>((Ice.Core.Session)oTrans.Session, Epicor.ServiceModel.Channels.ImplBase<LotSelectUpdateSvcContract>.UriPath))

This will return a standard BO proxy client that you can call GetRows or Update on normally, without having it tied to an adapter (which can be a real nuisance if you need for example to work with two datasets and not just one…).

Both the Adapter and proxy client also implement IDisposable, so they should in theory always be instantiated with a using statement.

When I said you cant use a BO like that, this is what I referencing:
LotSelectUpdate lotBo ;

And sure you CAN, but as a rule of thumb, Adapter is used client side and a BO is used server side. As you eluded to, this gives you the benefit of not having to finagle datasets.

I disagree that adapters should always be instantiated with using. The cost to spin up and initialize an adapter is not worth the hassle (and performance hit) if you intend to use the adapter more than once (not to mention you lose your dataset when you leave scope which would require you to create your own to store the data if you need it outside the call).

Just call Dispose() when you are done with your adapter, whether its after one use or when the form closes.

Honestly I never use adapters… Most of my BO calling is done from BPM or data directive code, but when I do need to call some BO from customizations, I avoid the adapters like the plague. They are really clumsy to use, and as you pointed out pretty heavy, and most of the time there is no point to them. Not much harder to just use a separate variable for your dataset, and much better for proper object lifetime management. Separation of concerns and all that. To me, they are unnecessary abstraction. In client code, I either use methods on the the Transaction object for the screen (with the bound epidataviews), or I call it as above (through a GetNewBO() extension method on the oTrans object, in our customization template…). There is no real wind up cost, since it uses basic WCF functionality, and connection pooling applies.