Epicor 10.1.400.18
bool RecordSelected;
string whereClause;
whereClause = ModeDate + " Is Null";
DataSet dSet = SearchFunctions.listLookup(UD20Form, “UD20Adapter”, out RecordSelected, false, whereClause);
Should I be using another method to retrieve records from a UD Table? This returns the rows without the extended UD fields from the UD20_UD table.
ListLookup only returns the main fields on the table (get list)
Use get rows or invoke search to get the whole dataset
-Jose
In a Nutshell,
In Epicor 9:
System.Data.DataSet dsPartRevSearchAdapter = Ice.UI.FormFunctions.SearchFunctions.listLookup(this.oTrans, "PartRevSearchAdapter", out recSelected, false, whereClause);
In Epicor 10:
listLookup only gets the “core columns” it no longer gets the UD Columns by design.
So you have a few options… I use the BOReader instead of listLookup when doing simple reads… but there is also a catch.
GetList: WORKS! - BRINGS IN THE PART REV INFO WITH MY UD FIELDS POPULATED!
System.Data.DataSet dsPartRevSearchAdapter = _bor.GetList("Erp:BO:PartRevSearch", whereClause, "PartNum, RevisionNum, Character10, CheckBox02, CheckBox03, CheckBox04, Date01, Date02");
GetList: DOES NOT WORK - BRINGS IN THE PART REV INFO BUT MY UD FIELDS REMAIN BLANK
System.Data.DataSet dsPartRevSearchAdapter = _bor.GetList("Erp:BO:PartRevSearch", whereClause, "");
GetRows: Works gets my UD Fields etc…
System.Data.DataSet dsPartRevSearchAdapter = _bor.GetRows("Erp:BO:PartRevSearch", whereClause, "Character10, CheckBox02, CheckBox03, CheckBox04, Date01, Date02");
When using the BOReader.GetList you “must” specify the columns you want. When doing BOReader.GetRows you can leave the columns “” and get all.
You are probably going to end up using either the AD/BO GetRows or CreateRuntimeSearch:
SearchOptions searchOptions = SearchOptions.CreateRuntimeSearch(whereClauses, DataSetMode.RowsDataSet);
adapterUD05.InvokeSearch(searchOptions);
3 Examples:
BOReader Gotchas!
Haso,
What’s the advantage of using a BOReader over a DynamicQuery with a BAQ?
Mark W.
performance wise i think they’re about the same (assuming you’re bringing back a similar sized dataset) but the BO reader is far less code and you don’t have to build and maintain the BAQ… just my thoughts. The only disadvantage i can think of is you are limited to UI applications with the BO reader where you could use the BAQ approach in BPM’s as well. But how often would you need the same one in both?
The reason I was asking is I’m doing a LOT of research on Testing Software and making software easier to upgrade. One of the points I will be talking about at Insights* is eliminating dependencies wherever possible. If we decouple objects then they tend to upgrade easier and are easier to isolate for testing purposes. As this thread shows, the dependency on the specific UD### adapter broke the application when the behavior of that adapter changed. If this was a BAQ, the main risk would have been fields renamed or eliminated.
Also, as you mentioned, reuse for other situations (like REST or BPMs) become possible.
Mark W.
(*Thursday, 9:05 AM)
assuming they don’t change the dynamic query adapter lol, but all good thoughts, your presentation sounds interesting!
+1 !!!
I agree with @rbucek in addition less dependencies, just one less thing to worry about; if someone removes the BAQ or whatever. #Speed
But some folks are using the DynamicAdapter (BAQ) and building COM-zGetSomethingHere Helper BAQ’s, nothing wrong with that especially if you have Calculated Fields.
