lviw_System_Persons interface

In Appframe365 family we have a fragmentation of persons implementations. In branch we have atbl_Felles_Personer implementation and in branch we have stbl_System_Persons implementation. For a long while Appframe365 would just use application views internally for authentication and other purposes, but then came in and that became unsustainable. We had to move away from using application level implementation of persons and start using system level implementation of persons. At the same time we have to support existing solution and continue rolling updates from Appframe365 to both branches. Using system view directly is not sustainable, any alter would generate and update and so the update stream would break solutions. In this case we need a dependency injection mechanism, an ability to use one or another view based on a database configuration.

Interface views

Appframe365 needs some interactions with person and related entities. 4 interfacing local views were extracted during Appframe365 database cleanup:

  1. lviw_System_Persons
  2. lviw_System_PersonsUsers
  3. lviw_System_ReportSettings
  4. lviw_System_MyWebApps

Those views are used by Appframe365 where needed. As first view name letter suggests they are local to each solution, definition of those views does not come via regular update stream. instead it is defined in stbl_Database_Setup.


stbl_Database_Setup table has 4 columns to configure views to be used internally by local views.

  1. PersonsViewName
  2. PersonsUsersViewName
  3. ReportSettingsViewName
  4. MyWebAppsViewName

Those columns have defaults pointing to system views, so in Appframe365 and descendants it can be left as is. You only need to reconfigure if you are to use different persons model then the one currently built in into Appframe365.


When you change any of columns mentioned SQL Template engine kicks in and regenerates related local view (implementation details in stbl_Database_Setup_UTrig). So if PersonsViewName column value would change lviw_System_Persons would be regenerated. Appframe365.Database SQL template is taking care of regeneration. Fragments shown below are responsible of generating SQL for local views:

Fragments define what columns are required by views, so to alter local views, SQL fragments should be updated and data change containing stbl_Database_setup update should be rolled out.

Related articles