Bad design – dabbler.dk

In the past I worked a lot with Microsoft Dynamics C5 and I just stumbled across an old quirk when you add database to a large existing database. You simply does not always get what you pay for.

Registered Microsoft Dynamics C5 partners can find this information in Danish on PartnerSource following this link: https://mbs.microsoft.com/partnersource/denmark/pricing-ordering/pricing-ordering-news/C52012DatabaseIntervalsExplained

…but the rest of you can get part of it here :-).

For Microsoft Dynamics C5 you purchase additional database in packages of these sizes: +25MB, +125MB, +250MB, +500MB and +2,500MB. Unfortunately internally the Microsoft Dynamics C5 kernel and license codes handles additional database size like this:

Database interval	Increments	Notes
0 – 45MB	+5MB	45MB is included in the initial Microsoft Dynamics C5 license
45 – 120MB	+5MB
120 – 2,020MB	+25MB
2,020 – 12,020MB	+100MB
12,020 – 112,020MB	+1,000MB

This actually means that if you have a database of 2,020MB and purchases +25MB, Microsoft Dynamics C5 will state the available space as 2,120MB, while your license states only 2,045MB.

Actually – according to the above mentioned information link to PartnerSource, you are NOT allowed to use more database than the license states. So you should add an extra database package when you reach 2,045MB in the above example.

If you don’t do that, this will also cause some huge confusion when you reach 2,120MB – because you might then add another +25MB and you’ll get NOTHING. The license will say 2,070MB, but Microsoft Dynamics C5 will still state it as 2,120MB…

Bonus info.: How much database storage can you purchase to a Microsoft Dynamics C5 installation? Exactly 112,020MB. After this the Microsoft Dynamics C5 kernel will stop calculating the DB size and you will not be required to purchase extra database license (but you are not likely to ever reach this limit 🙂 ).

Note: To my knowledge all of this is also true for Microsoft XAL because it was build on the same kernal as Microsoft Dynamics C5

In Dynamics NAV events are also fired on temporary records – this is really a confusing design and can trigger various, hard to debug, but rather serious issues.

On one customer running NAV 2018 CU1, user group memberships was cleared randomly. We did’nt know exactly when, but in the end one of my Indian colleagues figured out it happened related to the “Export to a datafile” functionality.
I was pretty sure someone was doing a DELETEALL – but was it in our code or in the standard code? And exactly how/where?

Actually it was easily found.
I created a subscriber one the delete trigger in table 9001 / User Group Member – only with one line of code:

ERROR('STOP');

…and started the debugger.

Note that events are fired even if the table trigger is not executed (i.e. INSERT/DELETE/MODIFY/RENAME is called with FALSE).

The deletion of the group membership is caused by the select/deselect all companies on the “Export to a Datafile” page in NAV. The list of companies is build in a temporary company record and DELETEALL is used on it when you select or deselect the all companies flag.

Unfortunately there is a subscriber in Codeunit 2 called OnAfterCompanyDeleteRemoveReferences which does not check if it is actually called with a company beeing removed, or just called with a temporary record instance from somewhere.
So it cleans up anyway – removing actual reference data from still existing companies!

This shows very clear that non-self-explanatory functionality like events beeing called on temporary records should have been avoided by Microsoft when designing this.
After all the goal of the development environment and -language should be to help developers write correct code – not to trap them into creating bugs.

If I had to redesign this functionality I would make it an function trigger property (default off) if the subscriber should run on temporary record instances.
Or at least let a subscriber parameter tell if it is temporary or not (not that this would make it easier to check, but it would remind you about checking it every time you created a subscriber 🙂 ).

To me the current functionality is wrong, people are getting bitten by this. It is illogical design and even if you tried it once or even multiple times (and my guess is that you have if you are writing event subscribers), you’ll probably forget it and do it again in the future.

At least we know we are not alone – Microsoft C\AL developers are actually also getting bitten by this :-).

Please note – this bug is not only emptying the 9001 / User Group Member table, but other tables as well: User Group Access Control, Application Area Setup, Custom Report Layout and Repor tLayout Selection.

By the way: The correct fix (introduced in NAV 2018 CU2) is to make these lines the first two lines in Codeunit 2, OnAfterCompanyDeleteRemoveReferences:

IF Rec.ISTEMPORARY THEN
  EXIT;
[…]

Tag: Bad design

2 + 2 <> 4

Even Microsoft gets this wrong :-)