Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 302 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Experience with workarounds for mixed keys
BlueInTheSky2
Member Posts: 3
Hello everybody,
in AL there is the problem that you can only create keys in TableExtensions with fields from the TableExtension itself.
It is therefore not possible to use fields from the original table in a new key of the TableExtension, e.g. in a new key of a TableExtension that extends the table Item, you cannot use any fields from table Item (e.g. 10 type, 16 statistics group, 31 creditor number, ...).
This problem is also outlined and discussed here: https://github.com/microsoft/AL/issues/1054
Although it is currently theoretically possible to extend the standard original table (e.g. 27 item) for the OnPremise variant, this has already been discontinued in the future.
I would be very interested to know what experiences have been made with workarounds for this problem, especially with the following 2 workarounds:
In this case, mixed keys can be created again in the table extension via the shadow fields.
Advantage: It is only necessary to replace the original fields with the shadow fields in the key calls used and no further code modification is necessary.
Disadvantage: The data of the shadow fields are of course saved for the second time, so they use additional storage space. In addition, additional effort is required to maintain the shadow fields.
In the following post it seems as if Microsoft is also considering making this available in a more technical, general way via "platform-managed field mirroring for fields needed in new indexes": https://github.com/microsoft/AL/issues/730#issuecomment-337013729
This workaround is e.g. outlined here: https://www.adv-usa.com/post/business-central-workaround-cross-keys-al-table-extension
The question here is certainly how high-performing such query constructs really are compared to the right key.
Disadvantage: If necessary, all codes in which the desired key is used are to be converted, including flow fields that are based on the desired key.
Of course, this also presupposes that the codes to be converted can be accessed at all (via suitable event subscribers).
I am grateful for all assessments / ideas / experiences!
Blue
in AL there is the problem that you can only create keys in TableExtensions with fields from the TableExtension itself.
It is therefore not possible to use fields from the original table in a new key of the TableExtension, e.g. in a new key of a TableExtension that extends the table Item, you cannot use any fields from table Item (e.g. 10 type, 16 statistics group, 31 creditor number, ...).
This problem is also outlined and discussed here: https://github.com/microsoft/AL/issues/1054
Although it is currently theoretically possible to extend the standard original table (e.g. 27 item) for the OnPremise variant, this has already been discontinued in the future.
I would be very interested to know what experiences have been made with workarounds for this problem, especially with the following 2 workarounds:
- 1st workaround: shadow fields
In this case, mixed keys can be created again in the table extension via the shadow fields.
Advantage: It is only necessary to replace the original fields with the shadow fields in the key calls used and no further code modification is necessary.
Disadvantage: The data of the shadow fields are of course saved for the second time, so they use additional storage space. In addition, additional effort is required to maintain the shadow fields.
In the following post it seems as if Microsoft is also considering making this available in a more technical, general way via "platform-managed field mirroring for fields needed in new indexes": https://github.com/microsoft/AL/issues/730#issuecomment-337013729
- 2nd workaround: queries
This workaround is e.g. outlined here: https://www.adv-usa.com/post/business-central-workaround-cross-keys-al-table-extension
The question here is certainly how high-performing such query constructs really are compared to the right key.
Disadvantage: If necessary, all codes in which the desired key is used are to be converted, including flow fields that are based on the desired key.
Of course, this also presupposes that the codes to be converted can be accessed at all (via suitable event subscribers).
I am grateful for all assessments / ideas / experiences!
Blue
0