If I have a service definition for lots of BEs, and some BEs use a single table and some BEs use multiple tables, and a singular table BE shares a table data-source name with a multiple table BE table name and the two table definition are different, only one of the definitions is loaded into KUIB event though the references are to the correct schemas.
I have a table, tableA, and a BE, tableABE.
I also have a multi table BE multiBE which uses TableX, TableY, TableZ and TableA. There are dozens of other tables and BEs for those tables.
When I add the datasources to the multiBEApp, I must tell it I'm using multiBE.TableX, multiBE.TableY, multiBE.TableZ and multiBE.TableA.
The schema for multiBE.TableA in the schema file for multiBE is different from the schema file for TableABE in the BE TableABE.
Nonetheless, the fields I was being shown for multiBE.TableA were those from the TableABE schema and not those from the mutilBE schema.
The two files did share a common define data-source srcA for (srcttTable | srcTable).
The data-source name I use to load data into my backend should have no effect on what KUIB offers me on my front end build.
In order to fix this issue, I'm going to have to rebuild my app from scratch. Once you generate an app with a data provider, apparently Kendo will never update it,.
I created a new client project, created a new application in it, loaded in the data provider from the old app and now it appears I'm going to get the right fields in my datasource(s). Now to build the App from scratch, once again.
Currently the JSDO does not support multiple data sources for a named resource even if the resources are in different data providers. We plan to remove this restriction in the future. It is best to separate your BE definition from the service interface (file with annotations). Then this file can do any needed transformation such as this.
The BE wizard in PDSOE has a checkbox to generate the service interface as part of the BE. This is great for demos but not recommended for real world apps.
My schema is a separate file from the BE, in fact, all my schemas are in separate files, but it's the totality of schemas we're talking about here, and KUIB's inability to adapt to a new or changed schema that I'm talking about. My point is that KUIB only works correctly if everything goes perfect. The demos never have to adapt to a real world change and that's why they work. They get created and the creator walks away from a perfect project; that developer never has to go in an make changes and thus never has to realize that Kendo has ignored the changes. No one sees the problem because this is demos, not real world.