Data Access Worldwide Knowledge Base
Article ID 2150 Article Title INFO: Relationship not updated when changing grandparent in dbGrid Article URL http://www.dataaccess.com/kbasepublic/KBPrint.asp?ArticleID=2150 KBase Category VDF (GENERAL) Date Created 07/29/2005 Last Edit Date 07/29/2005
Article Text
PROBLEM:
We have observed a problem whereby the DbGrid class does not update when a grandparent record is changed using its lookup. However, an update is triggered if a valid key is entered into the column and you tab out, which forces a find, and you navigate off the row. Returning to the row keeps the change.
SOLUTION:
The DD support two types of should-save checks - should_save and should_save_row
Should_save does the following:
1. If changed_state = T, return T
2. If parent_changed_state = T, return T (note: parent_changed_state means the DDO's parent record was changed)
3. Send should_save to all DDO parents (which will propagate up)
So, if a DD field is changed, or a DD's parent is changed for the DD and all of its parents, it is true. Basically, this catches all possible changes. This is the really sensible change check and it is what most DEOs use to figure out if a change exists.
This created some problems with dbGrids. Assume the following - you change data in an order header and then enter the dtl grid without saving those changes. If you used the above should_save, you get a save-needed every time you changed rows until you save a dtl item or until you clear all.
So, should_save_row was introduced which:
1. If changed_state = T, return T
2. If parent_changed_state = T, return T
This only checks for changes in the main DD (either a field change or a new parent selected). If you use this, when you enter the dbGrid and change rows, you don't trigger a save event for each row change.
The sample we see here shows a hole. If a grandparent is found via a dbList or a find key, the parent's parent_changed_state is set true. Should_save sees this, but should_save_row does not see this. If you enter with a keypress, the grid's changed_state is set true (because you typed in it) and that's why it saves there.
In this situation, we suggest doing the following:
In the dbGrid object (or sub-class), do the following:
Function Row_Changed Returns Integer
Handle hoDD
Boolean bChanged
Get Changed_State to bChanged
If not bChanged begin
Get Server to hoDD
If hoDD Get Should_Save of hoDD to bChanged
End
function_return bChanged
End_Function
Contributed By:
John Tuohy
Company: Data Access Worldwide
Web Site: http://www.dataaccess.com
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2010 Data Access Corporation. All rights reserved.
The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.