Show Posts
1
Bugs and Issues / Objects Positioned Incorrectly in Project Browser Tree
« on: March 05, 2025, 05:26:18 pm »
I've used Sparx EA off and on for more than 10 years, and beginning a couple of weeks ago I'm experiencing a very strange phenomena with one project in particular. When I open the project and expand the tree in the Project Browser, a certain percentage of the objects refuse to show in the correct position in the hierarchy - instead they sit at the root level of their package as though they have no parent defined. But if I look at the t_object table the parentid and package_id values are set appropriately - I can run a hierarchical query against the t_object table (with parentage defined by t_object.parentid) and the results appear as expected. But the object browser will consistently display these "rogue" rows at the root level.
This is in a postgresql repository. The behavior started not too long after I recently upgraded to Sparx V17, but it only occurs against this one model and not others in different postgresql databases. And it persists after I uninstalled and reinstalled V16, so I'm not inclined to call this a V17 issue although it is possible that it could have been triggered by something in V17.
If I drag and drop one of the rogue rows to a new parent, it will stay there in the Object Browser but only until I reload the Package Contents - at that point (or if I close and reopen the model) the same object goes back to sitting at the root level of the package - even though the database table confirms the parent has changed.
Scrutinizing every column value of all of the t_object rows, I could not spot any other clues where the rogue rows looked somehow different from the ones that were behaving properly.
At one point, I noticed that if I did a "bogus update" to one of the rogue rows in question (i.e. "update t_object set alias = alias where object_id = 12345") then that row would stop lying around at the base of the tree and now appear in its correct position in the hierarchy. Huzzah! So then I thought I'd be clever and perform an "update t_object set alias = alias" on all rows (no where clause). But sadly that has triggered an entirely different set of rows to now persistently appear at the root level (and me to curse profusely...)
I also tried creating a new empty eaq repository and copying all of the t_object rows to it. Opening that model, everything displays correctly. Which supports my belief that there is nothing wrong with any of the data in those t_object rows.
Eventually I enabled the sql logging on my postgresql database, captured the set of queries that are run when you perform a Reload Current Package, and found the one query against t_object that fetches the resultset for the Object Browser. From there, I was able to further determine that when I run that query through another tool, the "rogue" rows are all found earlier within that query's resultset than the parent rows that they are referring to. Every row that occurs before its parent ends up shown by the UI at the root of the package, while all of the others are shown in their rightful positions. This query is not a hierarchical query (it is a simple query against t_object that only sorts by package_id) which is not at all surprising since different DBMSs require very different syntax for hierarchical queries. This all suggests to me that the Sparx UI must normally be responsible for arranging the results into the correct hierarchy for display, and for some reason in this one particular model it is no longer doing this properly.
So my question is: what could possible be causing this one particular project to stop ensuring the proper hierarchy positioning for those rows that are fetched from t_object before their parents?
Huge Thanks in advance for any assistance - this is a show-stopper for me and I've already lost more than a full day of billable time trying to troubleshoot it...
Richard
This is in a postgresql repository. The behavior started not too long after I recently upgraded to Sparx V17, but it only occurs against this one model and not others in different postgresql databases. And it persists after I uninstalled and reinstalled V16, so I'm not inclined to call this a V17 issue although it is possible that it could have been triggered by something in V17.
If I drag and drop one of the rogue rows to a new parent, it will stay there in the Object Browser but only until I reload the Package Contents - at that point (or if I close and reopen the model) the same object goes back to sitting at the root level of the package - even though the database table confirms the parent has changed.
Scrutinizing every column value of all of the t_object rows, I could not spot any other clues where the rogue rows looked somehow different from the ones that were behaving properly.
At one point, I noticed that if I did a "bogus update" to one of the rogue rows in question (i.e. "update t_object set alias = alias where object_id = 12345") then that row would stop lying around at the base of the tree and now appear in its correct position in the hierarchy. Huzzah! So then I thought I'd be clever and perform an "update t_object set alias = alias" on all rows (no where clause). But sadly that has triggered an entirely different set of rows to now persistently appear at the root level (and me to curse profusely...)
I also tried creating a new empty eaq repository and copying all of the t_object rows to it. Opening that model, everything displays correctly. Which supports my belief that there is nothing wrong with any of the data in those t_object rows.
Eventually I enabled the sql logging on my postgresql database, captured the set of queries that are run when you perform a Reload Current Package, and found the one query against t_object that fetches the resultset for the Object Browser. From there, I was able to further determine that when I run that query through another tool, the "rogue" rows are all found earlier within that query's resultset than the parent rows that they are referring to. Every row that occurs before its parent ends up shown by the UI at the root of the package, while all of the others are shown in their rightful positions. This query is not a hierarchical query (it is a simple query against t_object that only sorts by package_id) which is not at all surprising since different DBMSs require very different syntax for hierarchical queries. This all suggests to me that the Sparx UI must normally be responsible for arranging the results into the correct hierarchy for display, and for some reason in this one particular model it is no longer doing this properly.
So my question is: what could possible be causing this one particular project to stop ensuring the proper hierarchy positioning for those rows that are fetched from t_object before their parents?
Huge Thanks in advance for any assistance - this is a show-stopper for me and I've already lost more than a full day of billable time trying to troubleshoot it...
Richard
Unknown error(7) occurred"