Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Phil.S

Pages: [1]
1
I was very happy to see the new "Time Aware Modelling" feature that was introduced in Version 13. Within my organisation we frequently use custom queries written in SQL to filter elements prior to RTF reporting. One query I have is how can we efficiently and accurately identify the superseded versions of an element using SQL, and therefore exclude them from the query results?

I have looked at how the versions of a given element are linked and having looked at the entries within the t_connector table the Connector Type used is "Abstraction", which means that if you filtered for elements linked to a given element via the "Abstraction" connector you could not rule out including elements that had been linked manually as an Abstraction (as opposed to linked automatically by the clone facility).  Within the t_connector table I have compared an entry for a manually created Abstraction connection against one created automatically by the clone feature. The only discernible difference between the two is that any records created by the clone tool seem to have the StyleEx field populated. In such cases the StyleEx field contains an entry like "version=1.1;VOF=1;. It appears the version part of the entry refers to the cloned version, which is great, but I am unsure what the VOF part is referring to. At the moment I don't know if this type of entry is exclusively used by the clone feature and therefore I am reluctant to use it as the basis of an SQL query to filter out the superseded version of elements.

What would be really great is if there was a flag against an element to mark it as being the most recent version. I know I could create a custom tag but that would mean manual management and ideally the clone feature would automatically mark an element as the most recent version when it is automatically created (whilst at the same time removing the flag against the now supersede element).

I'd be interested to know if anyone else has considered this issue and also whether there does exist an easy (or at least foolproof) way of excluding the superseded versions of elements from a SQL results set.

Many thanks

Phil

Pages: [1]