Table relation and LookupFormID

Hi, I have the following problem. I have a filed on the employee table (5200) named is Type. It’s a option filed containg Employee,Ex-Employee On a different table I have a filed linking to this table with the following table relation: Employee WHERE (Type=CONST(Employee)) So I only want to select the Employee’s that are real employees. The problem is that when I select the employee with the drownbutton, the lookupform of the 5200 is opened. Here it goes wrong. The cursor is not on the correct employee. It’s on the first employee. I found out that I created a Key that looks like this “Type, No.”. So when the form is opened, for some reason it selects that key and then it finds the first record. When I disable the key it works like it should. Does anybody have An idea how to solve this. I also solved the problem to select a view on the lookupform. But that’s not what i’m looking for. Guido

As a table relation always looks into the primary key fields, your foreign field should hold a Code20 field for the employee’s number and not an option field for the type. So there should not be a dropdown button available.

There a 3 situations that resolve the problem but are no option. 1. Removing the where part. 2. I Have key that Navision selects that causes this problem. When I delete this key, everything works like it should. 3. If I set the SourceTableView to “No.” it also works. All the options above are no option. Is there another way?

Why is 3 no option ?

Have you changed the Primary Key in Table 5200 Employee?

I don’t want to stuck with that key. If I for some reason expand my where clause, navision will always use that key. But it should use a much faster key.

Can you please post the list of Keys you currently have in Table 5200 Employee.

Enabled Key SumIndexFields yes No. yes Search Name yes Status,Union Code yes Status,Emplymt. Contract Code yes Status 2,Status,No. yes Birth Month,Birth Day yes Vendor No. This is the key that causes the problem yes Status 2,Status,No.

Navision uses the first key which contains the where clause fields. It does not use the “best” key. There is no way beside. except you write the onlookup code in the table yourself. As long as you do not have thousands of records in your employee table you will not really have a speed issue when running on the wrong key.