Error on Dual table window (OpenInsight 64-bit)
At 09 FEB 2021 02:01:01PM Brad Haughn wrote:
Hi all,
I had an issue like this before and was solved with 10.0.8, but it seems to be back now in 10.0.8.1 (or something like that).
I have a screen with 2 tables, and a selection join setup, but when I put in values manually to one of the keys (2 part key) I get an error from OIWIN_RESULTROW. To test further I made a blank screen with 3 fields, no events or validation on them. I attached to field one, the first part of my key. I attached to field two, the second part of my key. I attached to field 3, a field from another table.
so:
Part no: INVENTORY_DETAIL_MASTER*PART_NO second key part
Whs: INVENTORY_DETAIL_MASTER*WHS_NO first key part
Description: INVENTORY_HEADER_MASTER*DESCRIPTION - field from related table using PART_NO as key
I added the join. I manually typed into part no and tabbed out. Error. I've attached screenshots of the screen/setup, the error, and the call stack.
screen/setup
error
call stack
Any obvious issues anyone can see here that I can fix? Or is this something more involved?
At 09 FEB 2021 02:46PM Brad Haughn wrote:
With some further testing we found that if we have the key part 1 filled in before key part 2, we never have this issue. If we fill in key part 2 before key part 1, we always have this issue.
In other words, for my above table, the key is WHS*PART_NO
If I fill in data to WHS before PART_NO: no issue
if I fill in PART_NO before WHS: crash
At 09 FEB 2021 02:51PM Dave Sigafoos wrote:
Brad… this almost makes sense that it would happen. It is triggering off of KeyPart n (last key part) to do it's join and get data. Not sure what else could be done to make the screen work. Sure Carl will fill in where i have gotten it wrong :)
At 10 FEB 2021 06:05AM Carl Pates wrote:
Well it shouldn't break to the debugger at least :) I'll check it out and see what gives.
At 11 FEB 2021 08:37AM Carl Pates wrote:
Hi Brad,
Can I just clarify something? From what it looks like… INVENTORY_DETAIL_MASTER is basically the "primary" table for _this_ form (even though is not in terms of the way the database is structured) because you've bound both keys to it?
So your ordinal component list should be:
INVENTORY_DETAIL_MASTER
INVENTORY_HEADER_MASTER
Because it seems that you have a DETAIL form that can edit it's related HEADER ? Of course, if you just wanted to display the description from the header then you'd use a calculated column to xlate the value and bind the description to that instead?
Either way, it shouldn't hit the debugger, but I just want to know what you're actually wanting to achieve.
Regards,
At 11 FEB 2021 08:47AM Brad Haughn wrote:
Hi Carl,
This is one of a handful of screens we have where we have a "header" or general information entry screen/table where people enter data there, and a detail screen that has a 2 part key (one part for location and one that matches that general entry) and allows entry of both detail and header information. So someone could make new general info from one screen if they wanted to.
We've had these screens for.. well.. I think decades at this point? But yes, we're getting a debugger in oi10 for them now. We did try creating the screen fresh (which is what the screenshots are from) to see if that solved the issue, but did not.
For the example above though, the screen is mostly INVENTORY_DETAIL_MASTER fields, with a handful of INVENTORY_HEADER_MASTER fields using PART_NO as the key. displaying things like description, or inventory class, etc. Most clients would use this screen only (never going to the general entry screen) when creating new parts. Some clients with more structured inventory would use the general entry first.
Did that answer your question? Or did I ramble? I do that sometimes.
At 12 FEB 2021 09:13AM Carl Pates wrote:
Hi Brad,
You mention that you've had these working in version prior to 10:
DETAIL : key part 2
DETAIL : key part 1
HEADER : Description
For clarification - can you duplicate this in v9 and show me what the Join Criteria looks like for each table? What is the order of the the ordinal components etc?
(For the record the v9 Form Designer crashes when I try to do this!)
Thanks,
At 12 FEB 2021 09:26AM Carl Pates wrote:
Hi Brad,
With respect to your example:
I think actual the problem here is that the join order of the tables is not correct and the join selection dialog does not let you rearrange them (the dialog has other bugs that will be sorted in the next release too).
Your two key prompts are both bound the DETAIL table, therefore this needs to be the "primary" table. Your HEADER table becomes the "secondary" table with a join spec of "EF_PART_NO = <HEADER.PART_NO column>".
This means that we should at least update that dialog to allow the join order to changed. In the mean time, if you remove the prompts and then add them back with the DETAIL ones first, followed by the HEADER one - That should get _this_ example working at least.
If we can get that going then we need to look at what your actual live forms are doing and why we're getting the VNAV error.
At 12 FEB 2021 10:30AM Brad Haughn wrote:
Hi Carl,
if I make this test in OI9 latest version, it does now crash for me too. The full screen that these 3 controls are taken off of was made in OI9 and worked fine when we made it then. I have changed the order of the table join from HEADER/DETAIL to DETAIL/HEADER and still get the same crash. Same with OI9 now.
Unfortunately, the test screen is much easier to do this with since it only has 3 fields. The standard screen has closer to 100 controls, about 30ish to 70ish header/detail split. But since in my test I can never get to work regardless of the join order, I'm not sure that will help.
The only work around we have seen success with so far is to auto fill the warehouse (first part key) when the part gets focus (second part key) so its not possible to have an empty warehouse. We may just go with this for now since it sounds like you're getting a different result by doing the same thing.