System tables not usable for Extension development.

[NicolaiEsbensen]

Last issue I've come across (not mentioning the things that has been announced to be supported/adressed later on). There are quite a few tables that are no longer accessible. Many of which is understandable, i just would like some elaboration on the thoughts for not making them accessible. Below is a list and my comments.

Add-In (Table 2000000069)
The type or method 'Add-in' cannot be used for 'Extension' development.

• I guess will be populated by installing the extension, however we will have to wait testing this out...?

Object (Table 2000000001)
The type or method 'Object' cannot be used for 'Extension' development.

• Are there another table you suggest to use instead. AllObj for an example.. We use references to
  this a lot in order to configure the system, so it would be nice to be able to still lookup tables and codeunits.

Database (Table) 2000000048
The type or method 'Database' cannot be used for 'Extension' development.

• Makes sense. We use it to get unique identifier for the installation (In combination with other values).

Server Instance (Table 2000000112)
The type or method 'Server Instance' cannot be used for 'Extension' development.'
User Property (Table 2000000121)
The type or method 'User Property' cannot be used for 'Extension' development.
Web Service (Table 2000000076)
The type or method 'Web Service' cannot be used for 'Extension' development.

• How would you expose and use webservices without being able to access these tables?

Permission (Table 2000000005)
The type or method 'Permission' cannot be used for 'Extension' development.
Permission Set (Table 2000000004);
The type or method 'Permission Set' cannot be used for 'Extension' development.
License Permission (Table 2000000043)
The type or method 'License Permission' cannot be used for 'Extension' development.

• I guess this will be populated one way or another as a part of the extension installation?

[esbenk]

We have made some table unavailable to extension development for different reasons. In some case the information is sensitive or not relevant in SaaS in other cases we already know that we may remove or change the table in the future.

Add-In (Table 2000000069)
The table contains the list of installed add-ins (JavaScript Control, DotNet Control Add-in, DotNet Interoperability, Language Resource) and is currently not relevant for extension development.

Object (Table 2000000001)
The object table is a C/SIDE artifact. The format in here is only readable by C/SIDE and will be obsolete will all development has moved to the new model.

Database (Table) 2000000048
The database names are not available for SaaS.

Server Instance (Table 2000000112)
Not relevant for SaaS

User Property (Table 2000000121)
The user property table has always been a system only table.

Web Service (Table 2000000076)
The Web Service table is shared between all tenants and is therefore not accessible to extensions. Use the "Tenant Web Service 2000000168" table instead.

Permission (Table 2000000005)
Permission Set (Table 2000000004);
Same. Use the "Tenant Permission" and "Tenant Permission Set" instead.

License Permission (Table 2000000043)
License information is not available for SaaS

[NicolaiEsbensen]

Thanks for the reply @esbenk. I agree with many of the points, and thank you for pointing out the necessary alternatives.

Regarding the Add-In table, I guess we just have to wait to see what you are going to do there. Do you know when we are going to have something available in the preview?

Regarding the object table, what to you propose as an alternative. We will still need to be able to do table lookups one way or another. Tables don't become obsolete as I se it? :) Will there be a replacement in the new model or do one already exist.

The user property table we use in order to get the user webservices key for integration purposes. I am actually unsure if we actually use this field externally.

[NicolaiEsbensen]

AllObj seems to be a valid alternative currently and have added "App Package ID", does this mean that we can switch to use that instead or are the chances that this will be replaced with another concept?

[esbenk]

No plans at the moment. It is way to do it.

[Gallimathias]

@esbenk:
The format in here is only readable by C/SIDE and will be obsolete will all development has moved to the new model.

Does this mean that you may have access without c side to its source code, for example to write a own api?

[esbenk]

It means that when all our internal development has also moved to VsCode (W1, Country version) and we no longer use C/SIDE internally, then the Object table is obsolete and will be removed.

V2 extension objects don't go into the Object table, but is stored differently.