>>>>>>>Hi,
>>>>>>>
>>>>>>>I review customers' error log files and very often see the error of a certain view (CursorAdapter cursor) not open where it is supposed to be open. Obviously something happens before the error, perhaps another error, that leads to the missing cursor. But customers don't report the errors and so I have to figure out on my own what happens. So I am planning to create a "hidden" log of information. Some information will be written in this log file every time the CA cursor is not open (where it is supposed to be open).
>>>>>>>
>>>>>>>My question is, what kind of information can I write in the log to help me get to the why the problem occurs?
>>>>>>
>>>>>>Since the cursor that is not open is always associated with the certain BIZ object (Cursor Adapter object), I will probably check if the BIZ object is instantiated and some other properties of this BIZ object. Hopefully this will help to track the problem.
>>>>>>Any comments/input would be appreciated.
>>>>>
>>>>>I wouldn't mind some more information on this topic myself.
>>>>>
>>>>>I was recently doing some maintenance on a VMP5-based app. Some columns needed to be added CA classes. While adding them I ran into a couple of problems:
>>>>>
>>>>>1. One of the CAs has a GROUP BY clause. Initially I forgot to add the new columns to that clause (required by default in ENGINEBEHAVIOR 90)
>>>>>
>>>>>2. In another CA some of the added columns are NULLable and in the results of some queries could return NULL values for every row. I ended up having to add NULL to those column definitions in the Schema
>>>>>
>>>>>What surprised me was that these problems caused the creation of the CAs to fail "silently" i.e. there would be no error showing up until a form control tried to use the CA/view as its data source. I had to trace in the debugger, and manually simulate the CA .SelectCmd in SSMS. Also, having the previous (working) code to look at helped. With those aids and educated guesses I was able to figure out what was going on but that's not an approach you can use in production.
>>>>>
>>>>>I'm a bit surprised at this silent failure behaviour, I would have expected the VMP framework to handle it better.
>>>>>
>>>>>Nonetheless, in my case at least the first issue is getting an error (or some other trappable event) to occur at failure of the CA to be properly created. Until that happens, any logging will be of very limited use.
>>>>
>>>>I don't know anything about this framework that you use. But I create a BIZ object that I use for ALL of my table CursorAdapters.
>>>>And the way I check for the error is as follows:
>>>>When the CA object is instantiated and there is an error, my code still instantiates the object. One of the properties of the CA object is VIEW_ALIAS_NAME (name of the alias set to the cursor of the Cursor Adapter). Then I always check (usually in the INIT method of the form where the BIZ object is used) if the cursor of the name VIEW_ALIAS_NAME is open. If it is not open, there is problem and the code returns the error. It works very well.
>>>>
>>>>The problem I experience (of this thread) is the at some point in some other method of the form the alias name VIEW_ALIAS_NAME is closed. This is what I am trying to figure out; where the and what closes this alias.
>>>
>>>Your approach sounds good in general. The only part I'd question is checking for the existence of the cursor in the Form.Init(). That method gets run rather late in the form instantiation process: http://fox.wikis.com/wc.dll?Wiki~FormEventSequence . Most importantly, note that "INIT for each control in the form" occurs before Form.Init(). So if any of those .Init()s are expecting the cursor, that could fail before you hit the Form.Init().
>>>
>>>And if that scenario is actually what's happening, then maybe the CA cursor is never being created, perhaps due to a "silent" failure such as I was encountering.
>>
>>I see your point. All my controls have a code that check if the BIZ object associated with each control is instantiated and if the view is open. So I have never had a problem with my approach.
>
>Until now ... ;)
>
>One thing to check would be if the DataSession is being changed unexpectedly - either with a SET DATASESSION, or by some form or object having a Private datasession when it should be Default or vice-versa.
>
>Aside from that, the next thing I'd try would be a special "instrumented" build (what you're calling "hidden logging"). If your controls all check for their cursors, then presumably that's where you're currently seeing the error and as you say there's not much to tell you why the cursor isn't present.
>
>If you're lucky enough that the error is always happening with the same control, then you just need to instrument the code after the *previous* control in the TabOrder that successfully uses that same cursor. I sometimes use code like this:
>

>* DEBUG
>=MiniDump( {optional parameters} )
>* Optional parameters might be the current object name
>* and currently running method obtained via SYS( 16 ) or PROGRAM( )
>* and/or "This" reference so MiniDump() can get some stuff generically
>* ENDDEBUG
>
>FUNCTION MiniDump
>
>* Optional parameters
>* LPARAMETERS ...
>
>LOCAL ;
>  lcLogFile ;
>  , lcNewInfo
>
>m.lcLogFile = {SomePathSomeFile.log}
>
>m.lcNewInfo = ""
>
>m.lcNewInfo = m.lcNewInfo ;
>  + "Cursor XYZ is USED(): " ;
>  + IIF( USED( "XYZ" ), "Yes", "NO ***" ) ;
>  + CHR( 13 ) + CHR( 10 )
>
>* Add other stuff you want to look at here
>
>* Append to the existing log file:
>=STRTOFILE( m.lcLogText, m.lcLogFile, 1 )
>

>You then make strategic calls to MiniDump(), in your case maybe at the beginning and end of .Init() of controls instantiated prior to the one that fails.
>
>The above is general but you should get the idea.

I am writing the "secret" logging code so I will review your code and see where (if anywhere) to apply it. Thank you!