Hi David ---

A side note that may be relevant: I always create and modify my views through code for the reason that the View Designer doesn't like parameterized views (THISFORM can only be accessed in a Method error). I write the code into a PRg, run it...if it works, I add it to a MAKEVIEWS.PRG program that has the code to generate all of the applications views.




>
>I have one file in a project where I store all of the code created views each one looks something like:
>
>

create sql view windowsview as;
>SELECT windows.iid, cWindowLetter,;
>  nquantity, nwidth, nheight,;
>  ncostpersqft, nPrice, lnameplate,;
>  lprotectivecovering, llightbox, lframes,;
>  lfinalmeasurement, ;
>  CodesStyle.cValue as cWindowStyle, ;
>  CodesTop.cValue as cWindowTop ;
>  FROM  windows ;
>  INNER JOIN codes as CodesStyle;
>     ON  Windows.istyle = CodesStyle.iID;
>  INNER JOIN codes as CodesTop;
>     ON  Windows.itopshape = CodesTop.iID ;
> WHERE Windows.iproject = ?projects.iID ;
> order by cWindowLetter

>
>If I ever change a view, I just highlight that section of code, rightclick and tell it to Execute Selection. It works just great. I posted my dbcviewprop utility in another thread a few days ago that copies the properties of the underlying fields over to the view properties.
>
>>I need to create a view for a grid which joins 4 tables. In looking at other threads on the topic, I realize I have to do this outside of the view designer. The recommendation was to cut and paste the SQL code created from the view designer and modify it to fix the way the joins work and put it in a prg or a class. I understand that for the SQL part, but I'm still not sure how to code the rest of the view outside of the DBC, that is, the other parts which create the rest of the definition so I can use this in my grid as I would something I created in the view designer. I thought views had to reside within the DBC. Perhaps I'm thinking this is more complicated than it is, but I would appreciate if someone who does this can give me an example.