>Edward,
>
>>If I will tell you what I really think about SET RELATION, I wonder that you take it as personal offense, so I would just stay within well-known fact that SET RELATION just mask on SEEK() behind the scene, so it cannot be faster.
>
>Not taken as a personal offence :)
>It could be faster if the relations don't have to interpretate (did i spell this right?) about 6 seek commands in P-code. Just the core code of the seek is the same, but the speed gain could come from not having to interpretate the P-code seek commands.
>
>>In regard to way of updating tables etc., it really depends on the way you or me or someone else develops an application. If it's beatiful to you when pointers move in multiple areas automatically, so it's good for you, but not necessarily for me.
>
>Besides that. In reports you almost have to set relations if you want to display data from different tables without making SQL-query's. I'm sure that there are much more cases where SEEK has a serious disadvantage when compared to SET RELATION.

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?