True, but you cannot do much about the 'incompleteness of VFP'.
When you get the 'Target engaged' error it is probably to late for VFP itself to tell what the error was, because the error actually happend on SET RELATION, and it was not trapped. The event that triggers the error (selecting the target table) may happen in a different program/method.
One thing that I learned (the hard way) was to use SET RELATION as little as possible. In VFP I use parameterized views in 99% of cases where I used SET RELATION before.
The error traping mechanism of VFP is richer than FPD/FPW, you have the old ON ERROR, the newer ERROR event, and the newest TRY/CATCH - but to set up a solid error handling is more complex than before. VFP also has un-trapable errors.

>Thanks for your response, which certainly helps with my present problem.
>
>However, my message has more to do with VFP's error messages, pointing out two different issues:
>
>[1] Sometimes users get a gray "Program Error" box with options that they cannot possibly understand. I would think that VFP should allow us to create a "clean" application, where such programmer-like error messages should not occur.
>
>[2] There are a number of error messages (such as the two mentioned, but there are certainly many more) that convey so little information as to be close to of no value. Knowing that there is a problem with DynamicBackColor, for instance, is of little value if VFP does not identify the column with the problem. (In fact, sometimes settings for DynamicBackColor are simply ignored altogether, it seems, without any notification).
>
>Thus, I'm not as concerned with this particular instance of a problem so much as I am bothered by the incompleteness of VFP's error reporting mechanism.
>
>
>>Most of the time you get the error 'Cyclic Relation' on SET RELATION when you attempt to set a cyclic relation.
>>This is a scenario when you DO NOT get an error even if you set a cyclic relation:
>>-Let's say we have 3 tables: A,B,C, ordered by some index.
>>-Select A and set relation to ... into B, ... into C
>>

>>   A
>>  / \
>> B   C

>>-Select B, and set relation to ... into C
>>

>>   A
>>  / \
>> B - C

>>This is a cyclic relation that (V)FP allows you to set without eror. However, you get 'Table is aleady engaged...' when you select A. I see it as a bug.
>>
>>
>>>It seems that there are occasions when users of my EXEs get the gray "Program Error" box with a message like:
>>>

>>>   Target Table is already engaged in a relation
>>>

>>>along with choices to Cancel, Ignore, etc.
>>>
>>>Now, I have an "ON ERROR" which is supposed to shield the users from such programmer-nonsense, either by attempting to correct the problem, or, more likely, to save some relevant information for me to fix.
>>>
>>>First question: Why in the world does the user get this message? In my EXEs, I never want my users to see such balderdash.
>>>
>>>Second question: When I run this in my development environment, I get the same message box, with the option to Suspend -- but suspending does not leave at the offending line of code (which, so far, I am unable to discover).
>>>
>>>Third (related question): There seem to be a slew of related program errors which give error messages without providing any debugging assistance ... my favorite has to do with a failed DynamicBackColor ... I learn that it has failed, but there is no indication for which column. Is there any hope of getting error messages that provide enough information as to actually learn where the error is occurring?
>>>
>>>Thanks.