Reg: Logic Behind Maximum no. of Keys in Table is 40

Siddarth

Dear All,
Recently i came to know that there is one logic behind for Restricting the Maximum 40 Keys for Navision table.
If any one know please tell me the logic

kine

I think that it is just limitation of Native DB implementation which must be there for compatibility with Native DB Server. No needed for SQL, but because we have same object for both, than it must be in both...

jfalkebo

Yes the reasons are mainly historical and has to do with limitations in our Native database. Going forward NAV will no longer support the Native database so NAV will be released from some constraints in this area.

The number of indexes created on a table should be limited, however the NAV programming model and semantics often require more indexes than what is optimal.

The two main problems that we are trying to address are:
1.NAV guarantee Dynamic Result sets. This means that if the application is retrieving records according to a specified filter/range and at the same time inserting/modifying/deleting records further downstream in the result set then NAV guarantee that those changes will appear as the records are retrieved from the database. One of the ways we ensure this is to ask SQL server for a dynamic result or in other words a result that include changes. The best access plan for such a result set is one that fits the requested sorting (The ORDER BY) and therefore a NAV application developer is often forced to create an index that fits both the sort order and the filters. This sometimes lead application developers to create many overlapping indexes.
2.SetCurrentKey is the only way from AL code to specify which sort order is applied. As you know the fields specified in the SetCurrentKey must match a NAV index. Going forward we might introduce a different way for specifying the sort order where this constraint doesn’t exist. This should also help limit the number of indexes that need to be created in NAV.

rhpnt

Anyone who needs more than 40 keys/indexes on a NAV table should seriously rethink his/hers solution.

Alex_Chow

rhpnt wrote:

Anyone who needs more than 40 keys/indexes on a NAV table should seriously rethink his/hers solution.

=D> =D> =D>