Don't go this way at all. It's difficult for the user. What happens when you get thousands of records? It's much too difficult to find the one you need.

Go completely with a C/S concept. For data access you have two choices. 1) Cursor Adapter or 2) Local Views for VFP data and Remote Views for MySQL. It's easy to switch the forms back and forth at runtime.

As for the user getting data, provide search capability. For example, provide the ability for the user to search for a customer number or for last name or something else. The user will then type that into a search box and the results will be returned. If a single record is found, display it in the standard edit form. If multiple records, then display them in a grid where the user can pick the correct record.

Use NoDataOnLoad on all the forms so they don't have to query anything until the user requests something. I've seen many developers struggle when moving from VFP, where all the data is always available, to C/S, where you only work with subsets of the data. Keep in mind that things like LOCATE, SEEK, GO TOP, GO BOTTOM don't apply. Remember that data you will always work with a small portion of the data, and it will be retrieved, updated, and deleted via SQL commands.


>We are developing a project using DBF tables, that in a (not so distant) future, could use a mySql backend.
>So we are trying to study a user interface that could be easily adapted to this hypothetical scenario.
>
>At present, the majority of our table maintanance forms present a pageframe in which:
>- the first page contains a grid with the (parent) records of the table.
>- the others pages contain the record detail and the child records.
>
>Could you tell me about your experiences with this aspect?
>Any suggestion or example to see?
>
>Thank you.