>>>I had an awful time with the following view until I realized some interesting behaviour with views.
>>>
>>>CREATE SQL VIEW "LV_OBJECTDECORATORLIST" ;
>>> AS SELECT Decorator.winobjkey, Decorator.decobjkey, Decorator.decoratorname, Decorator.price, ;
>>> Objdeco.objdecokey, objdeco.objcompkey, ;
>>> NVL(Objdeco.default, .F.) AS ldefault, Objdeco.default, IIF(ISNULL(Objdeco.objdecokey),.F.,.T.) AS checked FROM ;
>>> vwin!decorator LEFT OUTER JOIN vwin!objectdecorator Objdeco ;
>>> ON Decorator.decobjkey = Objdeco.decobjkey and objdeco.objcompkey = ?v_objcompkey ;
>>> WHERE Decorator.winobjkey = ?v_winobjkey
>>>
>>>You will notice their are two view parameters. The interesting thing is that whether the view is opened as USE LV_OBJECTDECORATORLIST NODATA or the nodataonload property is set for the cursor object, it ALWAYS requests a value for the v_objcompkey. It must be some requirement when the parameter is used in the outer join statement and not the where clause. I solved the problem by including the parameter with a dummy value in the opentables method of the class that defines the cursor object.
>>>
>>>At any rate, NODATA does not work with a view of this type.
>>
>>I don't know whether you are using the view designer or write them in code, but I write them in code, saves the definitions in case the DBC goes bad like GENDBC and because I often have views too complex for the view designer. Anyway I have never experienced this problem. In the top of the prg that has all the create view statements, I have all the possible parameters declared as PRIVATE, then they are initialized. All my create view statements run fine without being prompted.
>>
>>Steve
>
>This view was created from a program but I can open it in the view designer. If you create an outer join of this type, you will even be asked for the parameter value when saving (even when running the program that creates the view). But only the parameter used in the ON condition.
>
>The purpose of this view is to display ALL possible choices (data from one table) with the child items that match from another table. I get a view with the selected items checked and the not selected items (no child record) unchecked. The view actually works very well, but the behaviour is unusual.



Chalk up another strange one for VFP.

Steve