>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