WorkView Views in Version 18

[Matthew_Pope1]

In version 18 the views are now stored in the database, but I am having trouble locating them.  I see the rmview and rmscreen tables, but these have no data in them.  When I open a view I can see in diagnostics console database tab that it is querying the rmcomponent tables.  After looking into these it appears that this is where the information on views is stored.  How do these rmcomponent tables relate back to the rmobject and rmobjectinstance tables for each class?

[Bill_Schoby]

@Ryan Wakefield notice hsi.rmcomponent has fields ParentID, PrimaryComponentID, and SeqNum.  I have not pursued it, but I suspect through a combination of sql, stored procedure, application logic that you could (and Hyland WV team does) recursively query this class to construct the view based on all the data contained in this table in combination with hsi.rmcomponentprop, hsi.rmComponentScript, and 
hsi.rmComponentStyles.

[Ryan_Wakefield]

So after doing some initial search, here is what I have found based upon what you pointed out @Bill Schoby .

The primarycomponentid column contains the root of the layout's component ID number. So for example, the root view of mine is ID# 3006. So I run the following query and get all of the child items for this specific view (and store them in an array).

select * from hsi.rmcomponentwhere primarycomponentid=3006

Then I would parse each of the items in the array where I would run a query (or run it against the array itself) where the parentid is equal to the current items rmcomponentid value and sort it by the seqnum column.

Obviously I don't know the full code logic as I'm not messing with it too much right now, but it is a feasible logic to run. However, what I will say is this, I took a look at the SQL queries that Studio runs when it loads the View, it appears that it does that second query/matching "where the parentid is equal to the current items rmcomponentid value" through the local code on the machine. This way it is just getting the data from the database and not taxing the database by structing the data. This definitely makes a lot of sense...in a way.

The only thing I have left that I need to figure out is how do I tie a specific view (rmcomponenttype=15) data to the parent component template (rmcomponenttype=13). There doesn't seem to be any official tie, but I could just be missing it of course.

Thanks for all of the help and insight. This has been a fun collaboration of finding this information out. 🙂

[Theresa_Yu]

@Ryan Wakefield 

The template and view are tied together in the hsi.rmcomponentprop table. The view has a property that stores the guid of the parent template.

[Ryan_Wakefield]

Thank you @Theresa Yu ! That is the final tieing point that I needed for my query. I will have to try and finish it up and I can then put it together for you guys. It is definitely....and interesting query to say the least. lol

[Theresa_Yu]

As mentioned in the original post, as of OnBase 18 all information for the views is in fact stored between the hsi.rmcomponent and hsi.rmcomponentprop tables. Each element of a view, including the view itself, is listed in the hsi.rmcomponent table (i.e. screen, view, attribute fields, tables, etc.), and all of the individual setting information and other details for those elements are stored in hsi.rmcomponentprop. There is no separate table that just lists the views. The type of item represented in the hsi.rmcomponent table is distinguished by the rmcomponenttype.

With views now being stored in the database, we no longer have corresponding HTML files for each view in the WorkView system path, and the hsi.rmview tables are no longer used.