Scratch that. My row number was off on the second table. Should have been a 1 and not a 0.
How would I update two tables using the same service call?
I’m trying to update the Primary Warehouse and the Primary Bin, but if I do the below, I get a “Record has been Modified by another user” error.
foreach(var r in ttResults.Where(r => r.Updated()))
{
if( r != null )
{
using(var partBO = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.PartSvcContract>(Db))
{
string binDesc = (
from wb in Db.WhseBin.With(LockHint.NoLock)
where wb.Company==Session.CompanyID && wb.BinNum==r.PlantWhse_PrimBin
select wb.Description).ToString();
string whseDesc = (
from whse in Db.Warehse.With(LockHint.NoLock)
where whse.Company==Session.CompanyID && whse.WarehouseCode==r.PartPlant_PrimWhse
select whse.Description).ToString();
PartTableset pds = new PartTableset();
pds = partBO.GetByID(r.PlantWhse_PartNum);
pds.PartPlant[0].PrimWhse = r.PartPlant_PrimWhse;
pds.PartPlant[0].PrimWhseDescription = whseDesc;
pds.PartPlant[0].RowMod = "U";
pds.PartWhse[0].WarehouseCode = r.PlantWhse_WarehouseCode;
pds.PartWhse[0].PrimBinNum = r.PlantWhse_PrimBin;
pds.PartWhse[0].PrimBinNumDescription = binDesc;
pds.PartWhse[0].RowMod = "U";
partBO.Update(ref pds);
}
}
What’s the scoop on getting this to work for multiple rows?
I got as far as figuring it’s something to do with the index of the table, but I’m having troubles figuring out the logic to dynamically assign that index.
I tried putting a counter variable that incremented after each foreach loop, but that still resulted in the “Record modified by another user” error.
I filtered my BAQ to focus on 1 part for testing.
It has 3 warehouses set up.
I can change the first one (BULK) just fine, but if I try the other 2, it will give me that modified error.
If I set an int counter I can update them in order, meaning I can update the first one, the first two, or all three and it will work, but if I update the middle one, or the last two, I get the error. Thinking it was indexing on all rows instead of just updated rows, I redefined my counter to included non-updated rows, but the same behavior happens.
ok a couple of things, do a trace on doing this manually. I don’t think they set the Description by hand like you are doing (Isn’t there a ChangeWhse , ChangeBin method the trace does?) you should always mimic the trace
Secondly, in your code you are addressing pds.PartPlant[0] (0 being the FIRST one) so you need to select the right one to modify. Not just 0 but rather find the record within that needs to be modified. You can do that with a Link query or a Loop in the pds.PartPlant or pds.PartWhse to find the right one.
See if that helps.
Make sure you are only looping on stuff that is modified Where(r => r.Updated()))
Correct me if I’m wrong, but I had assumed the the “foreach(var r in ttResults.Where(r=>r.Updated())” was looping through only the updated rows in the dataset.
So, if I updated only the highlighted rows in the BAQ, then that foreach statement would only process those two giving an index of 0 to MAIN-WIP and and index of 1 to REMWH1-TRK. Is that wrong?
This is what I have been doing since the last time I posted code. I had gotten rid of the index of zero hardcode, and added a counter:
int i = 0;
foreach(var r in ttResults.Where(r=>r.Updated()))
{
using(var partWhseBO = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.PartOnHandWhseSvcContract>(Db))
{
partWhseBO.GetPartOnHandWhse(r.PlantWhse_PartNum, "MfgSys");
}
using(var partBO = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.PartSvcContract>(Db))
{
string binDesc = (
from wb in Db.WhseBin.With(LockHint.NoLock)
where wb.Company==Session.CompanyID && wb.BinNum==r.PlantWhse_PrimBin
select wb.Description).ToString();
PartTableset pds = new PartTableset();
pds = partBO.GetByID(r.PlantWhse_PartNum);
pds.PartWhse[i].WarehouseCode = r.PlantWhse_WarehouseCode;
pds.PartWhse[i].PrimBinNum = r.PlantWhse_PrimBin;
pds.PartWhse[i].PrimBinNumDescription = binDesc;
pds.PartWhse[i].RowMod = "U";
partBO.Update(ref pds);
i++;
}
}
What you said about looping through the pds clicked after I made it output what it was doing.
I see what you’re saying now. The dataset isn’t what the foreach is looping through. The foreach is looping through the updated records of the temp table. So, I have to loop through the pds to find the right record and then I can update it.
For anyone else, here’s the train of thought that helped me understand the above a little more:
I wrote the index, before, and afters of all three to an out file and it all looks like I would expect:
Index: 0 - FROM: B | CON1 TO: B | BULK
Index: 1 - FROM: MAIN | WIP TO: MAIN | AA
Index: 2 - FROM: REMWH1 | TRK TO: REMWH1 | Staging
And if I run it for just the middle row:
Index: 0 - FROM: B | CON1 TO: MAIN | AA
The “FROM” is the pds.PartWhse[i] and the TO: is the ttResults table.
It clicked when I saw that the “FROM” data was the first record in the dataset and the TO was the updated record in the temp table.
It seems this was resolved. Could you share the complete steps as I need to achieve the same thing. Possibly share the exported dashboard + baq files? Thanks
After stumbling over this looking for information on the PrimBinNum, you might be better off using the PartWarehouse DMT to update. I don’t imagine this would be something you change regularly, or is it.
Thanks @hmwillett and @josecgomez for a great post. I’m sure the information will come in handy down the track. Your contributions are invaluable to all.
Well, I thought it worked for me. It works 2/3 of the time.
For a part in only one warehouse, it always works
For a part in two or more warehouses, it works in warehouse A but not B or C. I still get the “modified by another user” error if I try B or C.
a. I think it’s the alphabetically first warehouse that wins.
I tried the final code. I could easily be missing something. I have it on the Update method on Base processing. Maybe that’s wrong?
Edit: Also, I tried this even where the BAQ is pre-filtered to one warehouse and I still get the same problem. I feel like the code is still trying to hit the other warehouses anyway.
What you’re describing sounds like the issue I originally ran into. Make sure that the code you have is looping through the part dataset to find the correct record to update. My original code was just always updating the first one.