Status: Submitted
Status: Duplicate
Status: In progress
Status: Implemented
Status: Rejected

Allow us to set the order for Table Business Objects

Posted Nov 07 by Jerome Pearce.

Currently you are completely unable to set the default order for Table Business Objects. This means that all editable grids can turn up in a random order. It would be nice to able to set teh default order.


We have many requestes to set the order, and we have to tell the customer that this is impossible. This does not reflect well on the product.



Agreed completely and I believe may have been raised once before.  An initial order should be allowed, even if users can still reorder by clicking column headers.





(!$find('grdTimesheet_Editor_ctl00').sort('bofieldname')) returnfalse;


in the on form load event where bofieldname is the column name from the table. not ideal but a work around.


I am experiencing many difficulties in my design without the basic functionality to set the order of a table BO in editable grids.

Due to the inconsistencies, I have users entering in data incorrectly as randomly the order changes from what they are used to.


I work around that seems to work thus far is to create a primary key in the default order you want the sort to work.  Now, I'm not saying this is a proper method and I still fully agree at least a default sort order is a minimal requirement.  Users are not likely to enter things in the proper "order" (alphabetically, or whichever).  Also, it may not be possible/reasonable to define a decent/proper primary key to try to hack this.


Alas, this was raised nearly two years ago – and still no acknowledgement from OpenText that I've ever seen.


I do not recall any acknowledgement for any enhancement requests (although this is really a 'removed feature') since Rob left.


Yea, this forum, while "official", seems to be less supported by actual employees than what happened before the take over.


I have logged this on support as a bug.

I dont believe having data shuffle around randomly on editable grids could be 'as designed'.


This was a critical issue for us for which we raised a bug and was working with Development to resolve. An initial work around was to create a very poorly designed primary key which go the sorting closer to what was desired, but it still was not a good fit. It also caused concurrency violation issues if a user happened to change/clear a value part of the key, then delete the row.

Off the cuff they suggested building a view of the table with the desired ORDER BY in the view definition. A little bit of tweaking and we were eventually able to get this to work. We ended up doing (SQL, not sure if Oracle allows order by in view definitions):

SELECT TOP 99.9999999 PERCENT * FROM table ORDER BY sort1, sort2, sort3

Note that SQL will ignore the order by of TOP 100 PERCENT is used, hence the all 9s (billions is more than enough for our needs at this time). Its a bit of a hack, but it works and gets around the bad primary key I had created trying to approximate the fix.


Well, the initial work around (TOP 99.9999999 PERCENT) works in SQL Server for "smaller" data sets, but once the table grew larger SQL would not sort the results using the view any longer. I have no idea where SQL breaks down on this, but our production table has over 500k records so its somewhere below that number. We are having to fall back on an incorrect sort, but at least a sort that is somewhat decent for the most critical elements.

MBPM really needs to allow us to specify a sort order on editable business objects.

 You have subscribed and will receive email notifications of updates to this topic. To unsubscribe, uncheck the checkbox.


Related categories

Related tags

Your comment

To leave a comment, please sign in.