Hi, Michelle. I know what you mean about the parameterized views! But it gets to be second nature after a while. I've been making the transistion to PVs sloooowly. :-) I made major progress yesterday though: I had a troublesome grid that I solved with a PV because it was the _easiest_ solution I could think of. I'm pretty pleased.

As for programmatic views. The way I started _that_ transistion was to start a view in the designer (I still start there!), and then I copy the sql statement to a PRG I keep of my view definitions and add the create view code--which I learned by using Steve Arnott's GENDBCX program (www.stevearnott.com) I even do this for really simple views so that if my DBC gets damaged I can recreate the views really easily.

FWIW, here's one of my view procedures

***********************
PROCEDURE vwCUECARDS
CREATE SQL VIEW "CUECARDS" ; 
AS select cue, userid, id, phrase as phrase, upper( phrase ) as uPhrase from cuecard order by 3 nofilter

=DBSetProp('CUECARDS', 'View', 'UpdateType', 1)
=DBSetProp('CUECARDS', 'View', 'WhereType', 3)
=DBSetProp('CUECARDS', 'View', 'FetchMemo', .T.)
=DBSetProp('CUECARDS', 'View', 'SendUpdates', .T.)
=DBSetProp('CUECARDS', 'View', 'UseMemoSize', 255)
=DBSetProp('CUECARDS', 'View', 'FetchSize', 100)
=DBSetProp('CUECARDS', 'View', 'MaxRecords', -1)
=DBSetProp('CUECARDS', 'View', 'Tables', 'cuecard')
=DBSetProp('CUECARDS', 'View', 'FetchSize', 100)
=DBSetProp('CUECARDS', 'View', 'Comment', "CueCards")
=DBSetProp('CUECARDS', 'View', 'BatchUpdateCount', 1)
=DBSetProp('CUECARDS', 'View', 'ShareConnection', .F.)
=DBSetProp('CUECARDS', 'View', 'Prepared', .F.)
=DBSetProp('CUECARDS', 'View', 'CompareMemo', .F.)
=DBSetProp('CUECARDS', 'View', 'FetchAsNeeded', .F.)

*!* Field Level Properties for CUECARDS
* Props for the CUECARDS.id field.
=DBSetProp('CUECARDS.id', 'Field', 'KeyField', .T.)
=DBSetProp('CUECARDS.id', 'Field', 'Updatable', .F.)
=DBSetProp('CUECARDS.id', 'Field', 'UpdateName', 'cuecard.id')
=DBSetProp('CUECARDS.id', 'Field', 'DataType', "C(17)")
* Props for the CUECARDS.cue field.
=DBSetProp('CUECARDS.cue', 'Field', 'KeyField', .F.)
=DBSetProp('CUECARDS.cue', 'Field', 'Updatable', .T.)
=DBSetProp('CUECARDS.cue', 'Field', 'UpdateName', 'cuecard.cue')
=DBSetProp('CUECARDS.cue', 'Field', 'DataType', "M")
* Props for the CUECARDS.userid field.
=DBSetProp('CUECARDS.userid', 'Field', 'KeyField', .F.)
=DBSetProp('CUECARDS.userid', 'Field', 'Updatable', .T.)
=DBSetProp('CUECARDS.userid', 'Field', 'UpdateName', 'cuecard.userid ')
=DBSetProp('CUECARDS.userid', 'Field', 'DataType', "C(17)")
* Props for the CUECARDS.phrase field.
=DBSetProp('CUECARDS.phrase', 'Field', 'KeyField', .F.)
=DBSetProp('CUECARDS.phrase', 'Field', 'Updatable', .T.)
=DBSetProp('CUECARDS.phrase', 'Field', 'UpdateName', 'phrase')
=DBSetProp('CUECARDS.phrase', 'Field', 'DataType', "C(50)")
* Props for the CUECARDS.uphrase field.
=DBSetProp('CUECARDS.uphrase', 'Field', 'KeyField', .F.)
=DBSetProp('CUECARDS.uphrase', 'Field', 'Updatable', .F.)
=DBSetProp('CUECARDS.uphrase', 'Field', 'UpdateName', 'uphrase')
=DBSetProp('CUECARDS.uphrase', 'Field', 'DataType', "C(50)")
ENDPROC
*****************************************

>Ok. I see what you mean.
>
>I used a paramaterized view and I finally got the thing to work since you guys told me not to use append blank. :)
>
>One thing I don't like is that I have to have a variable with the same name as used in the view for the parameter. For instance, I keep the client ID in thisform.cid, and when I want to requery the view, I need to do LOCAL cnum, cnum = thisform.cid, REQUERY(). That's a pain. I wish I could do REQUERY(thisform.cid) and have it fill in the parameters like that.
>
>I also don't have a clue how to make a view outside the view designer, and some stuff I want to do is too complicated for the designer. I can see the syntax for programatically creating a view, but how do you get it in the database? Do you create it in the command window? Or do you need to run a program to create it each time you run the app?
>
>Talk about getting off topic... :)
>
>-Michelle
>
>
>>Just that I've gone to using SET KEY TO in the child table instead of SET RELATION. The effect is that the child table iis ~filtered~ to match the parent record. So, it doesn't matter if you have the child or parent (or some other) alias selected.
>>
>>That said I'm actually starting to move my development to using parameterized views, but it's not always the quickest solution for me.
>>
>>I hadn't used SET KEY until someone mentioned it here. I *believe* it's faster than SET RELATION. I haven't done any benchmark testing on, though.
>>
>>>I got everything up to the last line. How does SET KEY TO come into this?