Common tt in BE design - best practices? Cancel The title field is required!

1. Patrik Wikström

   

   70 posts
   Registered:
   15 Oct 2018
   02 Mar 2020

   Link to this post

   We have a common temp-table (TT, used to configure properties for certain field to be highlighted etc in the client) used by our Business Entities (BE) and we are wondering what would be the best way to handle these so that we don't get into unnecessary trouble with the BE Designer tool etc. We have just started testing and we've found that at this moment the only working way is to let every BE have their own set of TableModels & TT for these TT tables otherwise even the DatasetModel is generated in the common place. Is it also logically problematic to try to maintain a common TT in the Designer because will it not always be overwritten by the BE you happen to edit at the moment (only one BE should be able to be the master of the TT schema)? Probably best to just duplicate/import the common TT to every BE that need them to prevent problems with the Designer? This is the way we chosen now.
   
   Also the DataSetModel was somehow generated to the common directory of the TT, that also makes the idea of a common TT schema definition and maintenance not really working.
   
   Do anyone have had some similar requirements and some ideas and is this idea also dead from the beginning when you think about services in general? :)
2. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   02 Mar 2020 in reply to Patrik Wikström

   Link to this post

   Why do you need that temp-table in the DatasetModel at all? Is that relevant for you? 
3. Patrik Wikström

   

   70 posts
   Registered:
   15 Oct 2018
   26 Feb 2021 in reply to Mike Fechner

   Link to this post

   Completely forgot about this. 
   We wanted to include some additional info for the UI about which records/fields should be highlighted and wanted to have that in a separate common temp-table.
4. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   26 Feb 2021 in reply to Patrik Wikström

   Link to this post

   If that's needed for the UI (web UI, I guess), how would you utilize that from a DatasetModel?
5. Patrik Wikström

   

   70 posts
   Registered:
   15 Oct 2018
   26 Feb 2021 in reply to Mike Fechner

   Link to this post

   I might not care about that temp-table in the DatasetModel but if I remember correctly it was more about the fact that the whole model was generated in the wrong directory?
   The temp-table being part of the BE definition file (bedgm) of several BE's seems still problematic? If the BE definitionsfile is the "master" for the schema of that temp-table.
6. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   26 Feb 2021

   Link to this post

   I really don't think I can follow you. 
   
   Each temp-table in the Business Entity Designer has it's own path and does not need to reside in the relative folder of the Business Entity or Dataset. So it's trivial to keep that generic table reused everywhere without duplicating the generation. 
   
   And for the class based constructs such as the TableModel, the temp-table has a Package name property - so you can always keep the path the same. 
   
   The easiest way to implement this in the Business Entity Designer would be through a plugin. You might use the SmartFrameworkSupportPlugin as a sample. That injects a button in the Ribbon that allows to add some standard fields to the selected table. Likewise you could add a standard table to the current bedgm.
   
   Not sure if that was your problem. If not, please point me to the actual issue