>Edward,
>
>>You are about reports, actually about very simple reports only. In most report cases, it's nesessarily to use either SQL-cursor, or UDFs or both. There are no any other places within VFP where SET RELATION will give advantages, but there are many situations when they can kill the system, just think about the fact that row buffering commites changes automatically when pointer moves. IMHO, SET RELATION is more confusing than helpful. What's the idea to move pointers across the board of 6 tables, if you just want values from one of them?
>
>Actualy I use relations in almost every app i write. For e.q.in a article form i can display a parent record very qiuckly (for e.g. Custom code description in a customcode table) where the foreign key is located in the articles table.
>
>Another example is the pricing system i developed for a client which is so complex (13 relations) it could not be done with SQL without keeping up the performance. This is exacly the difference between a SET oriented approach (SQL) and a record oriented approach (XBASE commands like GO TOP, SEEK, AND SET RELATION)
>
>The advantage of VFP is that you can use both, getting the best of two different worlds.
>
>I frequently use SQL to gather the data inclusive foreign key into a cursor, set a relation to the parent tables on the primary key and run the report and display the descriptions of the related parent tables

Actually, I have nothing against your personal preferences, just because it's personal. However, believe me, there is no any performance penalty in SEEK() way and it's not SET oriented approach (I wonder if such thing exists at all :). VFP is rich product and it's pretty natural that there are numerous ways to develop applications.