Hi folks, I have a report which runs over the purchase header (? “Einkaufskopf” in German) table, which happens to have a primary key with two fields, “Belegart” and “Nr.”. The “Nr.” field is a predefined filter field on the data item’s filter form. Unfortunately, there is no lookup button to select an existing number, the user has to type in the entire number by hand. The same holds for setting an ordinary table filter on the “Nr.” field in the purchase header form. No lookup is offered in the filter form. I presume this has something to do with the “Nr.” field not being the one and only primary key field. Is there any way to activate the lookup functionality in filter forms for this field?
hi you are right. but you can always give a lookup window to the user in the Request form for the field Nr. you have mentioned. WR Hari
Heinz The reason why you have a missing Lookup button on for the “No.” or “Nr.” field is because the field has no TableRelation set. If you set the TableRelation to look at the “Purchase Header” then you wiil get an error because as you said The Primary Key is built on two fields and “No.” is the second part. For reports I would do what Hari suggested, and add a lookup field for “Nr” on the RequestOptionForm where you can code the Lookup on the OnLookup trigger to take into account the “Document Type” part of the primary key. I don’t know the answer (or if there is a solution)to the part of the question about lookup on the Standard Reqfilter. form
Amendment to previous posting You can set the TableRelation on “No.”/“Nr.” to look at Table 38 “Purchase Header”. On The TableRelation Property you need to set a condition for each of the “Document Types”, Table = 38 “Purchase Header”, Field “No.”/“Nr.” and TableFilter “Document Type” field “Document Type”. This then lets you filter on the “No.”/“Nr.” number on the RequestFilter form. I’m not sure what other problems this solution might cause as i haven’t tested in any great detail.
Stephen, you are a genius!!! [:D][:D][:D]
Thanks steve I noticed this first time carefully, that lookup works without TableRelation set ,only when its first in the primary key otherwise table relation is needed. thanks again
You shouldn’t set a tables relation to itself. Whilst it will help with your report, you can cause yourself issues later. Basically you are telling the table, that the value of this record key must exist in another table, in this case the table is itself, so when you want to create a record, you are basically that you can only create a record if it already exists. In the case of the Sales Header, you are using code to create the table, so it is not a huge issue, but what if you want to manually create a sales order. TRY IT, just go to table 36, and try to create a new record by typing in type=Order, and then enter a number manually. In any case, you CAN do it, just be aware of what you are doing, and be aware of the limitations. And make sure to at least set the properties to “ValidateTableRelation = No”. PS : I saw a solution once, where an NSC SWAPPED the primary key, i.e. Changed the primary key to “No.”,“Document Type”. It was a lot of fun[V], but really do not try this at home.
quote:
Originally posted by David Singleton
Basically you are telling the table, that the value of this record key must exist in another table, in this case the table is itself, so when you want to create a record, you are basically that you can only create a record if it already exists.
Thanks for the info, David. I already had the feeling that there would be a price to be paid… [:0] Anyways - purchase orders are only created programmatically in our system, and setting ValidateTableRelation to FALSE does the trick just in case. So I’ll leave it like this for now.[^] Hm, what happens if you change the order of the key fields? You would have to change all code and properties where this key is set, but there are probably some more dramatic consequences… [xx(]