StrataFrame Forum

Propagating changes to a LookupEdit

http://forum.strataframe.net/Topic23823.aspx

By Kirk M Sherhart - 7/15/2009

If I have a DevExpress LookupEdit bound to a BBS for its lookup values, will changes to the BBS's underlying BO (adds, delete, edits) be automatically propagated to the LookupEdit? For example, if a record is deleted from the BO, the next time the LookupEdit is selected, the value would not be presented for selection.



If not, what's the best way to capture and propagate the changes?
By Peter Jones - 7/15/2009

Hi,



Presumably the edits are being carried out by 'other users' so, without a receiving db update events (which can be done via a notification event - there is a property for this in each BO but I forget its name) I guess the easiest way would be to refresh the lookup edit's data source every time it receives focus.



Cheers, Peter
By Kirk M Sherhart - 7/15/2009

Actually, the situation is within a single app. For example, a shared PeopleBO might be used in one "domain" for normal adds/edits/deletes, while in another domain PeopleBO would be used in a LookupEdit as a population source (via a BBS.).



Would adds/edits/deletes in the shared PeopleBO automatically propagate to the LookupEdit's lookup values?



Hope that helps explain the situation.
By Peter Jones - 7/15/2009

Hi Kirk,



I presume that your domains are different users logged in on different workstations in which case I think my original suggestion still holds. Now SF does have facility called Shared Data Tables which I have never used - maybe the parent table that your lookup BO refers to can be based on a shared table in which case you could trap the BO's. AfterSave event to know that a change has been made and then refresh you lookup BO. But, as far as I know, shared data tables are only applicable when running multiple SF forms on the one workstation - the contents of a BO cannot be shared across multiple workstations. This being said I believe common data can be shared across multiple sessions in an ASP environment.



Cheers, Peter
By Trent L. Taylor - 7/16/2009

Kirk,



I am a little unsure of what you mean by Domains as this generally indicates a networking environment or a web domain. So depending upon your definition of a domain, the answer may vastly change. But within a single session, you can use a shared data table across as many BO innstances as you like and they will share the contents. This may be what you are looking for. But in regards to auto-updates from the server without a times query, you would have to use query notifications...if this is what you mean by a domain. In this case, the data is changing on the server, not the client side, so you will need to be notified or discover, depending on the route you take, to find out if the list needs to be updated.



I generally recommend against SQL query notifications as you can get into a permissions battle at times. The approach that we generally use if automatic updates are necessary to the client cache, is to create a threaded timer (System.Threading.Timer) that calls a sproc on the server every X number of seconds and SUMs up all of the row versions and then we will do a compute of the local data table to see if these numbers match. If so, the cache is up to date, otherwise a query is necessary to get any missing records.



So again, the definition of domain can have a dramatic impact on what needs to be done here. Hope this helps! Smile
By Kirk M Sherhart - 7/16/2009

Hi all



I'm sorry to use such a loaded word as "domain." Let me try again.



Suppose I have a single SF application with two open windows. One window uses a shared PeopleBO to perform normal edits (add/deletes/edits) on PeopleBO itself. The second window uses the PeopleBO as a population source (via a BBS) to a DevExpress LookupEdit



Will adds/edits/deletes done to PeopleBO be automatically propagated through the BBS to the population values of the LookupEdit, or must some other refresh be done?



A simple scenario might be: the user corrects a misspelled name using the PeopleBO window. Switching to the second window, the user edits some other data using a PeopleBO-populated LookupEdit. Will the corrected name appear in the LookupEdit's popup list?



Sorry for any confusion.






By Trent L. Taylor - 7/16/2009

If you use a shared data table then you should get exactly what you are looking for then. This is one of the purposes of a shared data table. Otherwise a simple requery could be called when the form is activated. But you might try the shared data table first to see if that is what you are looking for.
By Greg McGuffey - 7/16/2009

Kirk,



In this case, you'll want to go with Peter's suggestion and have an event fire when a property is changed. There is a setting in the Business Object Properties were you setup events related to property access/edits. I believe you'd want to have events fire when properties have changed. You can either have a single event for all properties or an event for each property. (See the Configuring Business Objects help topic).



Once you have that setup, you can then subscribe to that event on the form with the LookupEdit. Within the event handler, you'd just requery the LookupEdit to refill it (or however you fill the lookup values with that control).
By Edhy Rijo - 7/16/2009

Hi Kirk,



I have the same kind of scenario as yours but I don't use DevExpress, I have SF comboboxes in other forms, and what I do is in the DropDown to force a Combobox.Requery() to make sure the data is updated.



I know this may not be the most effective way to handle that, but if the lookup BO does not have many records it may be acceptable to you. On the other hand Trent suggestion to have some sort of mechanism to see if the data has changed via a SP looks interesting.

The approach that we generally use if automatic updates are necessary to the client cache, is to create a threaded timer (System.Threading.Timer) that calls a sproc on the server every X number of seconds and SUMs up all of the row versions and then we will do a compute of the local data table to see if these numbers match. If so, the cache is up to date, otherwise a query is necessary to get any missing records.