>What about relations when using a numeric PK?, this is right out of Fox Help for set relation:
>
>"If eExpression1 is numeric, it is evaluated when the record pointer in the parent table is moved. The record pointer in the child table is then moved to record number eExpression1"
>
>eExpression1 is of course the relational expression, maybe I'm missinterpreting this, I've never actually tried it, but it sounds like something I don't want, anyone want to shed some light on this?

I don't use set relation, seek, or locate. Everything I do is set based and parameterized. As an example, suppose I have a table containing customer information and another containing invoices for those customers.

View1 (Parent) Contains customers
View2 (Child) Contains invoice headers for all customers.

If I SetRelation between them, a couple of things happen. First, and most importantly, when I move the record pointer in the parent record, the engine has to sort through and decide what records to disply. Second if I move the record pointer in the child record. There will most likely be performance issues when the pointer jumps between blocks of records. The child records may be scattered about in the table, and the engine has to jump around in the table. If we're talking about relatively few records, it probably won't be a performance problem, but if we are talking about large quantities of rows 500,000 for example, the performance problem could be significant.

On the other hand, lets look at the structure of the views.

View1 is based on an SQL statement.

SELECT * FROM custfile

View2 is also based on an SQL statement.

SELECT * FROM invchdr WHERE cust_id = ?ncust_id

If you just browse View2 without anything else, you will be prompted for a value for ncust_id. If you provide a value for ncust_id beforehand Fox opens the view with with the results for that parameter.

Now, mechanically we have a form with two sections. A group of text boxes and such for the customer, and navigation buttons to move around them. The navigation buttons perform a simple function. They move the record pointer in the parent view, and call a method of the form or where ever that requeries the child view.

ncust_id = View1.cust_id
REQUERY("View2")
THISFORM.mygrid.REFRESH()

This methodology takes very little code, runs very very quickly against either file share or remote data, and never ever misses a beat. Setting Relations can be problematic if the record pointer gets confused, which in my experience happens with frightening regularity.

One other benefit of this methodology is that it is very easy to migrate the app from file share to a client server domain.

Regards,

Jason