This is directly thanks to @josecgomez opening a case that they only used key1 previously for comparison which for certain screens would load WAY too much data. However they did as he suggests and added key2 to the filter, well key2 is tilde separated and that would work fine, but it doesn’t appear that the UI and BO were updated to pass they secondary keys along. All that is passed along is the sysrow for the primary head record which tells the backend nothing about the key2 records we need.
OK… so sometimes the change log viewer is hard to use (admittedly not my favorite screen to use). in some cases, I have created my own BAQ/Dashboard to extract/view the data that is in the Change Log Tables. It isn’t very hard, and you can even incorporate it into a tab on the main edit screen.
Sure but I don’t want to be doing that for a bunch of different screens. I have a case opened to get it fixed. The UI does not pass anything but the head records sysrowID. Now that the Key2 is included in the lookup, it will never know about the sub records that are ~ delimited because that information is never sent to the BO.
If you add it to Ideas I will vote for it everyday We have so many users trained to look at those details before they tell me the system has a problem.
No PRB for this yet, but this BPM will restore functionality and show all of the change log records. Because there is no for sure date or workaround @josecgomez and I dug into how to fix it, the BPM is the best we could do. We wanted to make it work as intended with key2 filtering but alas, not possible with the UI unable to send the BO key2 info.
If you have a lot of change logs you will still have the issue of that screen loading a ton of them because no additional keys are used (ex. AP Invoices @josecgomez original grind), but for normal consumption it will work.
I provide this AS-IS and without warranty or liability we threw it together quick so test before production please.
I don’t have a 500 system I can do that in.
Single code widget here you go
string result = ttChgLog.FirstOrDefault().Key1.Split(':')[1].Trim();
var cl = (from x in Db.ChgLog where x.Company == this.Session.CompanyID && x.Identifier == ip_tableName && x.Key1 == result select x).ToList();
ttChgLog.Clear();
foreach(var l in cl)
{
var row = ttChgLog.NewRow();
BufferCopy.Copy(l,row);
ttChgLog.Add(row);
}
We have so many users trained to look at those details before they tell me the system has a problem.
