Lookups still not working C8 NT6.07

[ccordes]

I think the popup display issues have been taken care of - Now I need to be able to get the data from the selected record.
I have an order record being updated. I select the inventory item and populate values in the order from inventory.
(this is working in NT5.37)
Now in NT6.07, if I open a popup browse to select from, I get the correct item description, but none of the other data gets updated
If I don't use a popup for the select browse, I get nothing returned.

Reading about hilton's popup issue, I made sure that the item id in the order was the primary key of the inventory and it is. However, the inventory item id is not a key in the order table. (I don't think it needs to be, but that could be where I am going wrong)

I also remember something about the descriptions. Our inventory has multiple items with exactly the same description. I do not have "Display Description" checked for the lookup field. Just in case, though, I renamed one of the descriptions for my tests to no avail.

What could I be doing wrong??  Any suggestions?

TIA,
Chris

[Jeffrey Kuijt]

Hi Bruce

How is it possible that the lookup stuff has been broken in NT6?
I remember it was some time broken in NT5, but all is working very well in NT5 now.
I am a bit scared to make the move to NT6 at this moment.

Best regards
Jeffrey

[kevin plummer]

Hi Chris,

It's probably a good idea to test some of your theories on one of the examples (like accounting). That way it is easier for Bruce to replicate.

Cheers,

Kev

[Bruce]

Chris, Kevin is right - best to post an example.

Cheers
Bruce

[Bruce]

Hi Jeffrey,

>> How is it possible that the lookup stuff has been broken in NT6?

Under the hood, there's quite a lot that has changed from NT5 to NT6. Most of the changes are pretty boring stuff, so it doesn't make the excitement level go up, so it doesn't get a lot of press.

The most notable change, architechturally, is that the browse and form have been refactored as jQuery widgets. There are a number of advantages to doing this - the most immediate of which is that the text being sent in a browse or form gets smaller, and cleaner. As we move towards mobile it also gets easier to do some things, and in th long term the widget approach is easier to extend, and a lot easier to manage.

While I've tested a bunch of different things, there are always boud to be the odd place that has slipped through the cracks. The lookup issue, especially with the sheer variety of (dare I say wrong?) ways of using lookups is a manifestation of that.

Although we've had a spate of "lookup is broken" reports over the last few builds, we're really seeing a lot of different issues rather than the same issue. Some are a side-effect of the wizard, and the way some dictionaries are formed. Some are related to the way files are related, some are related to the use of decription and code fields, and so on.

At the moment backward-compatibility is the top priority, and I'm making every effort to resove any upgrade issues. In some cases this means better docs (the "upgrading" doc is continually being updated) to cover various possible situations, in other cases it's possible to make the transition smoother by expanding the envelope of what the widgets can manage.

Lookups are particularly prone to "breakage" when making this sort of transition because they're actually somewhat complex to handle under the hood, and because while there is a "right" way to do lookups, which is dependant on a "right" dictionary - many of us inherited dictionaries, or techniques, for doing lookups that are less than perfect. It's a real world we live in, and so we need to handle those sorts of things - I'm aware of that.

Of course there's no pressure to move to NT6 until you feel it has stabilised - but I do appreciate the effort of those who have updated, and are reporting issues - they are ultimately improving the upgrade for everyone else. The best I can do for them is to keep the builds, and information, flowing as smoothly as possible.

Cheers
Bruce

[Jeffrey Kuijt]

Thanks for your clear explanation, Bruce!

Best regards
Jeffrey

[ccordes]

Bruce you very nearly answered my real question - What do lookups expect to have in order to work? Do they need a 2 -way relationship created in the dictionary? Can they exist as a one-way "lookup" relationship? This is the way my dictionaries are generally made - no need creating a key for every code that bares looking up.
It seemed that NT4 and 5 did not rely heavily on what was in the dictionary.

Is the "right" way included in the docs? I checked in the doc for a "things to change" or "things that changed" section and made whatever changes I found. I was pleased to find very few.

Chris

 

[Bruce]

chris,

NT6 is perhaps a little more unforgiving than NT5. That's something that'll probably change in a build or 3.

At the moment I'm _assuming_ that most lookups consist of
a) a "parent field"

b) a lookup table
c) an id in the lookup table (which is what gets put into the parent field) and a "description" field in the lookup table.

Ideally the lookup field is the component of the lookup table's primary key.
and there is also a unique key, on the lookup table, on the description field.

No key on the parent file is assumed, or required.

Cheers
Bruce

[ccordes]

Thanks much, Bruce

I am using example 25 for testing  this. Out of the box, the look up for product does not work.
That's a good thing because I'm trying to figure out why mine don't.
So far the only situation I see that reliably does not work is when you don't use popups.
In example 25, the price for the line item does not fill in.
Set the line item look-up in UpdateInvoices to open as pop-up and magically the price is updated.

You've made a bunch of changes in here. and I'm not certain what is causing this.

I have also have a cs version of #25 without the product key in the line items table and that seems to work as well.
In my version, I have added a in line button to the invoices browse that adds a line item. It calls UpdateLineitem as insert. This simulates what happens in my app where all the orders are a single lineitem so there are no extra lineitem insert buttons.

Works here with popup but not in my app so I am back to the drawing board to see where I'm going wrong.
At least now I have a model.

Chris


[attachment deleted by admin]

[ccordes]

FOUND IT!
Lookups ARE working BUT I clear my fields in the priming - In the perinsert, I make sure that I am not loading old values from the session queue.
What I didn't know was that preinsert gets called over and over. Which also explains why the order numbers get reset. 

Chris