SetFocus seems to break relationship between tables 
Author Message
 SetFocus seems to break relationship between tables

This is the code behind a delete button on a form with a grid

LOCAL OldSelect
OldSelect = SELECT()
SELECT HDRPERMIT
IF !EOF()
 DELETE
 SKIP
 SKIP -1
 ThisForm.Refresh
1/  ThisForm.GrdHdrpermit.SetFocus
ENDIF
SELECT (OldSelect)
2/ ThisForm.GrdHdrpermit.SetFocus

If I perform the setfocus at position 1, the relationship between the parent
and child table is broken, and the grid displays ALL records, allowing the
user to delete whatever they like.  This does not happen immediately.  The
form needs to be closed, returning the user to the parent form.  When the
child form is re-opened the grid displays all records.

At position 2 all works as expected.

Can anyone guide me as to how to make this 'set relation' more reliable.



Mon, 23 Feb 2004 15:16:15 GMT  
 SetFocus seems to break relationship between tables
This does not directly address your problem, but I never
use SET RELATION to populate a grid with related records.
I either use a parameterized view or a temporary cursor.
Relations can be a little wobbly when used in an interactive
situation.  I usually restrict my use of SET RELATION to
controlled blocks of code - usually loops - where I am in
control of the use of the related tables.  This is not a hard
and fast rule, but after years of doing this, I find these
precautions to be very reliable.

-- TRW


Quote:
> This is the code behind a delete button on a form with a grid

> LOCAL OldSelect
> OldSelect = SELECT()
> SELECT HDRPERMIT
> IF !EOF()
>  DELETE
>  SKIP
>  SKIP -1
>  ThisForm.Refresh
> 1/  ThisForm.GrdHdrpermit.SetFocus
> ENDIF
> SELECT (OldSelect)
> 2/ ThisForm.GrdHdrpermit.SetFocus

> If I perform the setfocus at position 1, the relationship between the
> parent and child table is broken, and the grid displays ALL records,
> allowing the user to delete whatever they like.  This does not happen
> immediately.  The form needs to be closed, returning the user to the
> parent form.  When the child form is re-opened the grid displays all
> records.

> At position 2 all works as expected.

> Can anyone guide me as to how to make this 'set relation' more
> reliable.

--
_______________________________________
My e-mail:  t r w 7

_______________________________________


Tue, 24 Feb 2004 00:55:20 GMT  
 SetFocus seems to break relationship between tables
When you say temporary cursor....

Do you mean you scatter/gather information from your active table into a
local cursor, then when the user chooses to save you scatter/gather it back
to the real table?

Does table buffering still apply in this situation, or is load/save now my
responsibility?


Quote:
> This does not directly address your problem, but I never
> use SET RELATION to populate a grid with related records.
> I either use a parameterized view or a temporary cursor.
> Relations can be a little wobbly when used in an interactive
> situation.  I usually restrict my use of SET RELATION to
> controlled blocks of code - usually loops - where I am in
> control of the use of the related tables.  This is not a hard
> and fast rule, but after years of doing this, I find these
> precautions to be very reliable.

> -- TRW


> > This is the code behind a delete button on a form with a grid

> > LOCAL OldSelect
> > OldSelect = SELECT()
> > SELECT HDRPERMIT
> > IF !EOF()
> >  DELETE
> >  SKIP
> >  SKIP -1
> >  ThisForm.Refresh
> > 1/  ThisForm.GrdHdrpermit.SetFocus
> > ENDIF
> > SELECT (OldSelect)
> > 2/ ThisForm.GrdHdrpermit.SetFocus

> > If I perform the setfocus at position 1, the relationship between the
> > parent and child table is broken, and the grid displays ALL records,
> > allowing the user to delete whatever they like.  This does not happen
> > immediately.  The form needs to be closed, returning the user to the
> > parent form.  When the child form is re-opened the grid displays all
> > records.

> > At position 2 all works as expected.

> > Can anyone guide me as to how to make this 'set relation' more
> > reliable.

> --
> _______________________________________
> My e-mail:  t r w 7

> _______________________________________



Tue, 24 Feb 2004 06:37:16 GMT  
 SetFocus seems to break relationship between tables
Yes.  I will create a cursor in the form's Load event
or some other method that runs early in the form
instantiation sequence.  Then I will populate the
temporary cursor whenever the parent table's record
pointer moves.  When I use this approach, I also
have two methods that I add to the form: LoadTempCurs
and SaveTempCurs.  The LoadTempCurs method is the
one that cleans out the records in the temp cursor
then fills in the currently applicable records.
SaveTempCurs scans through the temp cursor and
saves changes back to the source table(s).

Whether you buffer or not is up to you.  If the tables
that are being manipulated via the temp cursor are
used in other places in your form, you may want to
have them buffered.  In this case, in your SaveTempCurs
method, you would need to do a TABLEUPDATE on the
tables involved after saving the data.  If the tables
are only accessed through the temp cursor, then whether
or not they are buffered is personal preference.  I
like to buffer most tables so that the changes only
go down to the table when I want them to.

Keep in mind that I only use this temp cursor approach
when a parameterized view just can't handle what I
want to do.  Using a view is much easier if what you
are trying to do is pretty simple.  The temp cursor
approach gives you absolute control over everything
that is shown in the grid and exactly how and when
data moves to and from the related table(s).

-- TRW


Quote:
> When you say temporary cursor....

> Do you mean you scatter/gather information from your active table into
> a local cursor, then when the user chooses to save you scatter/gather
> it back to the real table?

> Does table buffering still apply in this situation, or is load/save now
> my responsibility?



>> This does not directly address your problem, but I never
>> use SET RELATION to populate a grid with related records.
>> I either use a parameterized view or a temporary cursor.
>> Relations can be a little wobbly when used in an interactive
>> situation.  I usually restrict my use of SET RELATION to
>> controlled blocks of code - usually loops - where I am in
>> control of the use of the related tables.  This is not a hard
>> and fast rule, but after years of doing this, I find these
>> precautions to be very reliable.

>> -- TRW


>> > This is the code behind a delete button on a form with a grid

>> > LOCAL OldSelect
>> > OldSelect = SELECT()
>> > SELECT HDRPERMIT
>> > IF !EOF()
>> >  DELETE
>> >  SKIP
>> >  SKIP -1
>> >  ThisForm.Refresh
>> > 1/  ThisForm.GrdHdrpermit.SetFocus
>> > ENDIF
>> > SELECT (OldSelect)
>> > 2/ ThisForm.GrdHdrpermit.SetFocus

>> > If I perform the setfocus at position 1, the relationship between
>> > the parent and child table is broken, and the grid displays ALL
>> > records, allowing the user to delete whatever they like.  This does
>> > not happen immediately.  The form needs to be closed, returning the
>> > user to the parent form.  When the child form is re-opened the grid
>> > displays all records.

>> > At position 2 all works as expected.

>> > Can anyone guide me as to how to make this 'set relation' more
>> > reliable.

>> --
>> _______________________________________
>> My e-mail:  t r w 7

>> _______________________________________

--
_______________________________________
My e-mail:  t r w 7

_______________________________________


Wed, 25 Feb 2004 01:10:21 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Broken Relationship in Grid

2. Wizstyle.vcx (add button) in relationship (one table to another table)

3. Using same table in several relationships

4. Changeing Relationships between tables displayed in grids

5. Querying many to many table relationships

6. VFP 5.0 Table Relationship Problem

7. VFPro5: Multiple relationships between two tables?

8. Child Order in a Table Relationship

9. VFP3 table relationship question

10. Displaying Table relationship in Grid

11. VFP: Problem with table relationships

12. Relationships between remote tables

 

 
Powered by phpBB® Forum Software