c8/nt6.07 lookups not working

[hilton]

Hi Bruce,

I have been fiddling some more and something struck me as strange - probably because I do not understand the finer points of programming, but here it is:

1. I put a TRACE in the 'afterlookups' in the calling program to reveal which rep if any was passed back from the lookup
2. I put a TRACE in the 'rowClick' to reveal the rep:recordid's obtained (also because I did not really know what I was doing)
3. I put a TRACE in the 'CallClicked' to show which rep:recordid was selected.

As you can see from the attached trace results, on the surface the results seem to be out of order.
The 'rowclicks' are fine as they show the records being obtained by the lookup program.
Then I get the calling program's results (nothing returned)
Then on another thread the result of clicking on the select button in the lookup browse row on another thread.

To the layman, namely me, it seems a bit strange.

I hope I am not wasting your time, but it may be of interest.

Bye,
Hilton.

[attachment deleted by admin]

[peterH]

Lookups seem broken in 6.06 as well.

I think it has got something to do with the record buffer or session values not being properly set/refreshed after the lookup as I'm always getting the lookup record from the previous lookup.

Now, to make it really funny I just discovered that it does work in one file (with two keys) but not in another (with three keys) ....  not much help here, I'm afraid.

Peter

[Bruce]

Peter, lookups were fixed in 6.07, so if you have 6.06 you definitely want that updated.
Hiltons comments are slightly tangent to that.

cheers
Bruce

[Bruce]

Hi Hilton,

>> As you can see from the attached trace results, on the surface the results seem to be out of order.

Each request comes through separately, and gets allocated to different threads for processing.
Since there's no guarentee what time each thread will get, or in what order they'll finish, there's no "right" or "wrong" order.
You simply can't rely on the order at all, but rather need to place code in the right place.

Feel free to ask if there's more you want to know about where to do something specific.

cheers
Bruce

[hilton]

Hi Bruce,

I guess I did not make it clear enough - I am finding that the lookups DO NOT WORK in nt6.07.

I have tried the search button in the browse line - did not work.
I have tried the search button at the bottom - did not work
I tried deleting the browse and regenerating it - lookup did not work
However!!! I deleted the calling update and then regenerated it - now the lookups work.

I have also had to start redoing my order entry procedures as they ceased working since the conversion from nt5.41 to nt6.  Now on nt6.07.

I can only assume from the above that the conversion process somehow has something lacking.

When I am feeling less discouraged I will try some more looking around and let you know the results.

Bye,
Hilton.

[Bruce]

Hi Hilton,

instead of deleting offending procedures, send me the app so I can have a look to see what's wrong with them.

My immediate guess is that you've got xHtml ticked on for something (header, field or something) and you're not ensuring the code is actually xHtml compliant. that's the usual issue with this sort of thing. But it may be something else.

cheers
Bruce

[hilton]

Hi Bruce,


Attached please find:
1. htgex1.zip - compressed app, files etc
2. webdict.zip - compressed dictionary
 'runninginst.txt' to guide you thru login, passwords etc.

Thank you very much,

Hilton.

[attachment deleted by admin]

[Bruce]

ok, I see the issue. Basically you're not using your Primary Key's as the relation between two tables. For example;

CustCategory table has a primary key (PK_recordID) which has a field (recordID). that's good.
CustCategory then relates to CustAttrib table, using the local "code" field.

CustAttrib also has a primary key, and recordID field, but does not use this RecordId as the row identifier. In other words the "Primary key" of CustAttrib does not match the Foreign Key of CustCategory. (or vice versa).

Typically when doing the relations in the dictionary, the primary key of one table matches the foreign key in another. this is the so-called "3rd normal form", and it is the layout the wizard is expecting.

the solution, and the reason it worked after you re-did it manually, is to set the "Unique Key" of the Lookup browse to be say CUSCAT:K_categorycode instead of CUSCAT:PK_recordid.

In other words, the key used in the Lookup Browse matches the key that you ultimately use to relate that table to other parent tables.

Cheers
Bruce

[hilton]

Hi Bruce,

Thanks, I see what you are saying.  I have played with the sample I sent you and where I got my wires crossed, uncrossed them and it worked.  I will now go through the rest of the app looking for crossed wires.

The thing that really threw me was the fact that it worked in version 5.43.

I am happy and will now plod thru' everything looking for errors.  That will at least teach me to be consistent.

Bye until I next stumble,
Hilton.