It looks like you're new here. If you want to get involved, click one of these buttons!
borealis wrote: »
To the best of my knowledge this isn't permitted. I haven't read up on the latest cumulative updates so may be mistaken, but I know that as of CU4 this was not allowed.
The only thing you can do key wise is add additional keys using added extension fields. Also worth noting that you cannot adjust the field groups. We have a client that has an extended item identifier (100 chars) and the shenanigans we had to go through to make that easily searchable/sortable without redoing everything involved were extensive.
Our theory is that this is because the extension based fields/keys are stored in a separate table in SQL and the base tables are considered set in stone. Thus you cannot add a key that mixes, for instance, the product group code (original table, in master database table) and "custom subproduct group" (extension field, stored in the secondary extension table) as they're in completely different tables.
TallyHo wrote: »
First and foremost, the use of the term Key group is not correct I hope? Key groups were a feature in older NAV versions.. and if we're talking here about creating them in AL on Tables split by extensions.. I'm off.
TallyHo wrote: »
Well ugly as it is.. Create copy, named differently, of all fields of the targeted key in the base table and add them to the extension. Create the key in your extension but now with the copied fields and your custom fields.
To update the fields with the same value as the original fields.
This probably has a lot of cons, but I cannot see any other way.
Slawek_Guzek wrote: »
@borealis you cannot create a "mixed" key having fields from base table and the extension for a very simple reason - the extension data is physically stored in a separate table.
When you access table with an extension NAV Server creates in the background a query joining the base table with the extension table, and the results is visible in code as a one record. The SQL Server however is not capable of creating keys that span many tables, therefore key mixing base table fields and extension fields will be probably never possible.