Hi Aleksey

I do not remember anything in the doucmentation telling me about the details of error handling that you just mentioned. If I had known that I would have constructed my class differently. I assumed the Try/Catch would catch all errors. Now I know that it will not I will build my class appropriately.

I am not blaming you but there sure does seem to be alot missing in the documentation not only on cursor adapters but on other items as well. I find it aggravating that I have to spend so much time experimenting just to find out how things work.

However, I must say that you have been very helpful in your discussions with me and others regarding cursor adapters.

Thanks
Simon


>>Hi Aleksey
>>
>>I have already done something like you suggested below to trap for the condition. However, it raises another question. If an error is reported by AErrors() why was it not trapped by the Try/Catch error handling? I had wrapped my code in the Try/Catch specifically to catch any errors but it never did. So I did not think to use in the Aerrors() functions. It seems that both the Aerrors and Try/Catch should both detect the error.
>>
>>This makes me think that there is a bug in the Try/Catch error handling mechanism.
>>
>>Simon
>>
>
>Hi Simon,
>
>It is difficult to say anything specific without knowing exactly what your code looks like.
>
>However, CursorAdapter methods do not raise an error and do not throw an exception in case of failure. They indicate a failure thru output parameter (similar to TABLEUPDATE function) and provide the error information for AERROR function. Any exception/error that happens inside of those methods must be caught by the CursorAdapter and transformed into appropriate return value to indicate the failure. That makes those errors not trappable by outer TRY/CATCH by design.
>
>Thanks,
>Aleksey.
>
>
>>
>>
>>>>Hi Aleksey
>>>>
>>>>I finally tracked down the source of the problem. I discovered that "MultiLocks" was turned off in the forms with private datasessions which caused the cursorattach method to fail. In forms without private data sessions "Multilock" was on so everything worked fine.
>>>>
>>>>This was hard to find since it did not trigger any kind of error or warning. It seems to me that some kind of message should have been trigger warning me that "multilocks" for turned off
>>>>
>>>>Thanks,
>>>>Simon White
>>>>
>>>
>>>Hi Simon,
>>>
>>>I guess, you've become a victim of a doc BUG.
>>>1. Help topic for AutoOpen method says that it reports an error in case of failure. This is incorrect, in case of failure, AutoOpen returns .F. .
>>>2. DataEnvironment.OpenTables method doesn't report any error if AutoOpen method fails, I can't find this information in VFP help, but this is the expected behavior.
>>>
>>>The following code, shows that both CursorAttach and AutoOpen do report failure with correct error. However if you rely on default AutoOpen and OpenTables behavior, you will not get the error during Form loading process.
>>>

>>>CLOSE DATABASES all
>>>CLEAR
>>>SET MULTILOCKS ON
>>>
>>>DELETE FILE multilockstest.dbf
>>>CREATE table multilockstest (f1 I)
>>>INSERT INTO multilockstest VALUES (1)
>>>USE
>>>
>>>LOCAL oCA as CursorAdapter
>>>oCA=CREATEOBJECT("CATest1")
>>>
>>>
>>>? "Default data session."
>>>? [SET("Multilocks")], SET("Multilocks")
>>>
>>>IF !oCA.CursorFill(.F.,.T.)
>>>	?"CursorFill failed!!!"
>>>	AERROR(aerrors)
>>>	DISPLAY MEMORY LIKE aerrors
>>>ELSE
>>>	?"CursorFill succeeded!!!"
>>>	SELECT (oCA.Alias)
>>>	LIST
>>>ENDIF
>>>
>>>oSess=CREATEOBJECT("Session")
>>>SET DATASESSION TO oSess.DataSessionId
>>>SET MULTILOCKS OFF
>>>
>>>LOCAL oCA1 as CursorAdapter
>>>oCA1=CREATEOBJECT("CATest1")
>>>
>>>
>>>? "Private data session."
>>>? [SET("Multilocks")], SET("Multilocks")
>>>
>>>IF !oCA1.CursorFill(.F.,.T.)
>>>	?"CursorFill failed!!!"
>>>	AERROR(aerrors)
>>>	DISPLAY MEMORY LIKE aerrors
>>>ELSE
>>>	?"CursorFill succeeded!!!"
>>>	SELECT (oCA1.Alias)
>>>	LIST
>>>ENDIF
>>>
>>>IF !oCA1.AutoOpen()
>>>	?"AutoOpen failed!!!"
>>>	AERROR(aerrors)
>>>	DISPLAY MEMORY LIKE aerrors
>>>ELSE
>>>	?"AutoOpen succeeded!!!"
>>>	SELECT (oCA1.Alias)
>>>	LIST
>>>ENDIF
>>>
>>>
>>>
>>>
>>>
>>>DEFINE CLASS CATest1 AS CursorAdapter
>>>	DataSourceType="NATIVE"
>>>	Alias="test"
>>>	SendUpdates=.F.
>>>
>>>
>>>	FUNCTION CursorFill(luseCursorSchema, lNoData, nOptions, Source)
>>>		NODEFAULT && this is important
>>>		LOCAL lRetVal
>>>		lRetVal=.T.
>>>		TRY
>>>	    	IF(this.CursorStatus!=0)
>>>    	    	USE IN (this.Alias)
>>>	    	ENDIF
>>>
>>>	    	USE multilockstest IN 0 AGAIN ALIAS (this.Alias) SHARED
>>>
>>>    		lRetVal=this.CursorAttach(this.Alias)
>>>    		IF !lRetVal
>>>				? "CursorAttach FAILED !!!"
>>>				AERROR(errs)
>>>				DISPLAY MEMORY LIKE errs
>>>				USE IN (this.Alias)
>>>			ENDIF
>>>		Catch
>>>			lRetVal=.F.
>>>		ENDTRY
>>>	    RETURN lRetVal
>>>	ENDFUNC
>>>ENDDEFINE
>>>

>>>
>>>If you want the error to show up, try to override AutoOpen method like this:
>>>

>>>	FUNCTION AutoOpen()
>>>		NODEFAULT && this is important
>>>		IF !DODEFAULT()
>>>			AERROR(errs)
>>>			ERROR errs(1,1)
>>>		ENDIF
>>>	ENDFUNC
>>>

>>>
>>>I'll make sure that the help is corrected.
>>>
>>>Thanks,
>>>Aleksey.