Please include the following with each issue:

1. Describe the bug Table extension for a table from different extensions from same publisher does not show AS0013 or PTE0022 when using range 1..49999 (works for range 50000..99999)

2. To Reproduce Steps to reproduce the behavior:

In extension A create a new table

table 71000000 EXT001Table1
{
    DataClassification = CustomerContent;

    fields
    {
        field(1; MyField; Integer)
        {
            Caption = 'MyField';
        }
    }

    keys
    {
        key(PK; "MyField")
        {
            Clustered = true;
        }
    }
}

In extension B (same publisher as extension A) create a new tableextension for Table1

tableextension 71000000 EXT002TableExt1 extends EXT001Table1
{
    fields
    {
        field(325; EXT002XX; Code[20])
        {
            Caption = 'XX';
            DataClassification = CustomerContent;
            ToolTip = 'Specifies the XX code for this table.';
        }
    }
}

No warning/info/error visible
Change publisher of Extension B to different value
Warning AS0013 is shown

Note: Because the developers need to copy and paste the code snippet, including a code snippet as a media file (i.e. .gif) is not sufficient.

3. Expected behavior The warning should be visible regardless of the publisher according to documentation. Documentation for AS0013 says that only table and enum objects can use range 0..49999

4. Actual behavior No warning shown.

MAJOR IMPACT

This caused issues with our AppSource offerings as we have now table and tableextension in two AppSource apps with same ID (first tableextension then table) and customers cannot upgrade to the latest version if they have both apps (we have added the field to table in last release).

Internal work item: AB#599115

Aug 20 '25 13:08 TKapitan

@TKapitan - This was actually an intended decision. As we are investing on namespaces and allowed to split tables into table and table extensions within the same app, we have relaxed the validation on table extensions and ID ranges for table extensions from the same publisher. We should update the documentation to reflect it.

In order to help with such issues, we could report the non-blocking diagnostic AS0099 when a field ID is outside the extension's range. It would require you to change its severity using rulesets if you want it to be blocking.

Similarly, we could re-use the non-blocking diagnostic AS098 for affixes - or maybe a new one as Info (i.e. no need to act on it) since AS0098 is a warning (i.e. developers should act on it) and not using affixes in such scenario is acceptable for us. We'll discuss this.

What do you think of this solution reporting them as non-blocking diagnostics?

Sep 02 '25 09:09 qutreson

@qutreson We are OK with this being reported as non blocking as we have our own company-wide rulesets with strict rules.

I still don't understand why this was relaxed this way though - why using publisher and not just the current app? As of now the table/tableextension can be split only within the same app so it doesn't make sense to have it cross-extension.

We were lucky with our AppSource apps as the problem is in a buffer table (Type = Temporary) so it looks like we will be able to create new fields in correct range and obsolete (and remove) the old fields. However, as this may (and will) happen also to someone else and probably in normal non-temporary table, what would be the solution for AppSource apps? E.g. two appsource app installed in 100 environments, next update of the app A will add a field with id from app B - now the customers cannot update their apps and the partner cannot rename/remove the field

Sep 09 '25 14:09 TKapitan

AS0013 and PTE0022 not working correctly for tableextesions from same publisher for range 1..49999

MAJOR IMPACT