
02-09-2012 10:42 AM - last edited on 02-09-2012 10:49 AM
I have been seeing these same errors, after applying web hotfixes 1 and 2 with the ERPTradingAccount table.
My not so nice workaround was just to delete all records in this table every 5 minutes, since the customer doesn't use it.
I'm also now encountering a same or very similar error with a new 1 to 1 table from Account called Website, and what I'm seeing is that the seccodeid in the account does not match the seccodeid in the customer_website table. I added this table recently using architect., and then added the entity to the AA.
What appears to be happening is that the customer is changing the account seccodeid, but then the Website seccodeid is not updated to match. Should the oledb provider be doing this, or do I need to modify one of the Account Business rules?
I'm also wondering if this is the same thing that's going on with the ERPTradingAccount table.
-Chris
02-09-2012 11:17 AM
The provider should be doing this....but it didn't on the LAN side and we are seeing that it isn't doing it on the Web Side.
PITA
02-09-2012 04:12 PM
This one is a real mess....
A - If the integration is NOT being used.. then NO ERP "special tables" should be populated - it's just taking up space in the db and leads to performance issues.
B - If integration IS being used then the Provider should be making sure the SECCODEID's on 1:1 matches the "parent/master"
C - If the "parent/master" record's SECCODEID is changed, then the provider should change the SECCODEID in the 1:1 ("child") to match it.
D - None of this is specific to the web client.. it has to be the same for ALL clients (Web/WIndows-LAN/Mobile Web/other apps using SData or the Provider directly. Anything else will break the others.
For now we have our customer using a TaskCentre task to simply truncate the ERP table(s) in question if any records show up... but it is simply a work-around.... and needs a real Hot-Fix.