Michelle,

First, I don't think there is necessarily anything wrong with the "old way". Except see changes below (you may already do this in "real life").

Another way to do it is to have an error flag property in your application object. Or, you can have an error manager object (a private variable, created in your main program). The error handler would set properties in these objects. Again, see changes even further down.

HTH,

steve


>I think I'm not being clear. Maybe because I'm rather confused by all this myself. :)
>
>Anyway, I don't want to return false, I want to return my result object. That part I can handle. The part I am having trouble with is letting the code that caused the error know an error has occured. The old way I would have done it is like this:
>

LOCAL lcOldError, llWasError
lcOldError = on("error")
ON ERROR llWasError = .T.
USE tablename
on error &lcOldError
IF llWasError
  *-- Use AERROR to get the info and then deal with it
ENDIF

>
>With doing things the OOP way, I don't have the ON ERROR anymore. Instead, if the USE fails, it goes to the error method.
>
>So I have:
>
>

>USE tablename
>IF <b>oErrorManager.errorSet</b>  && An error occurred
>  loResult.lSucceded = .F.
>  loResult.cError = <b>oErrorManager.message</b>
>ELSE
>  loResult.lSucceded = .T.
>ENDIF
>
>RETURN loResult
>

>
>What I don't know is how to make the IF statement know there was an error and what that error is.
>
>Thanks,
>
>Michelle
>
>
>>Hi Michelle,
>>
>>How about returning a .F. from the DataOpen Method? Passing the return value (.F. in this case) up the calling chain. Your error handler can trap the error and do whatever action you require.
>>
>>Robert