I really thought there was a requery method that would just re-run the last query used to populate a business object, but for the life of me I can't find it.

Here's what I'm trying to do:  I have a business object tied to a DevExpress grid using a BBS, the user may run a function that will archive 1, 5, 17, ?? rows from the linked table to some archive table on the backend using a stored procedure, and I need to refresh the BO and thus the grid to reflect the changes.  However, since the user may of called one of several different FillBy's or ran some custom lookup I would have to do a lot of work in my form tracking the last SQL (and applied filters).  It seems to me the BO should be able to just store off the last ran SQL, and then just re-run it.

TiA

Jason Seidell

Jason Seidell

Programmer/Analyst

Infinedi

The framework doesn't provide this functionality...and for the very reasons you mentioned. There's just no way the framework can know enough about how you filled a BO to have any idea how to refill it automatically, because it provides so many ways to fill a BO. So, you're best bet is to track how they filled the BO and then you could just recall that code. On many of my forms I have a refresh button that just calls the appropriate fill code again. Sometimes I also attempt to reselect the row they were viewing (this isn't in a grid though). The code tends to be in form's as that is were I actually know how to refresh the BO.

Hi Jason,

Assuming the archived data is removed from the data view the grid is bound to you could just execute the grids RefreshDataSource method.

Like Greg we also have a Refresh button on all forms so data can be reloaded using changed data selection criteria and to pick up changes made by other users.

Cheers, Peter

Yeah but my point is why couldn't the BO just capture the last SQL statement used to fill it, and then the requery would just re-run the last SQL statement???  Bypassing/ignoring whether the SQL statement came from a Fill method or a FillDataTable, and not having to store the where parameters.

Jason Seidell

Programmer/Analyst

Infinedi

I guess I don't understand the benefit or use of what you are trying to explain here.  Not that it may not be a valid enhancement request.  But there is not a method that just executes a Requery on a BO at the moment.  We have this functionality with our ListViews, Lists, and Combo controls.  But I have, to date, not run into a scenario or a need where the BO is caching queries for re-execution. 

If you have this need, you could implement it yourself very easily within your BaseBO (if you have one).  You can just override the query methods of the BO, for example the FillDataTable, and then cache this off yourself.  If you have a BaseBO setup, then you could implement this in an hour or less.  ANd if you don't currently have a BaseBO, this might be a good time to create one and then inherit your BOs from your BaseBO that has this caching logic.

I have a work table of items that need processed, which the user might run a various fillby or lookup to pull back only a subset of records, and then a batch command maybe ran that would process and thus remove a number of those records.  However those sub-commands are using stored procedures and thus no updating to the business object.  Once the batch command completes the grid/BOs still show records that no longer exist on the database because the records were pulled out from underneath the BO on the database.  So I want an easy way to refresh the dataset without resorting to trying to track the last ran FillBy and the parameters used.

Jason Seidell

Programmer/Analyst

Infinedi

The idea about creating a baseBo sounds good to me, that's what I will follow and I'll see how this works out.

Thanks to all for the great input!! 

Jason Seidell

Programmer/Analyst

Infinedi