Boy, Barbara, I wish I'd been using the UT and could have read this message when * I * attempted to use views...after gaving up a number of times, I finally got it, but it was an initial struggle...good response!
J
>Hi Peter,
>Thanks for the good description of what you're doing and where your problems are. It makes it much easier to answer. And your naiveté (I had to check the spelling too) is nothing more than inexperience - we all started at the beginning originally.
>
>Point 1: Be careful what you name tables and fields. If you use any of the VFP reserved words you will have random difficulties later on. In your code, BAR is a reserved word, as is _TALLY. I know you're using the 'TALLY' without the initial '_' but it could still cause problems. Look up "Reserved Words" in the Help file and change any tables/fields that use those words.
>
>One of the most common problems for new users is using 'desc' for a field holding a 'description'. When you call that field in a SQL-Select VFP sometimes (not always) confuses your field with the "descending" clause.
>
>Point 2: Using a filter in a table of more than 100 records is asking for trouble. What will happen if you want to show records 1 and 500,001? The poor user will wait for 10 minutes while the computer checks all the records inbetween. (Of course I'm exaggerating here, as indexes will speed it up).
>
>So Point 3 is obviously views. The view designer can be confusing until you've done a few, and this is particularly true of parameterized views. The best thing to do is some 'practice' views on a table where you know what the result SHOULD be.
>
>I don't think you'll have much trouble with the Fields and Join tabs of the View Designer - those are pretty straightforward. The end result matches a similar SQL-Select, and you can check what you've done by clicking 'SQL' on the View Designer menu. If you want the view to be updateable (so data is saved to the master tables when you call TableUpdate() ) you'll have to go to the Update Criteria tab. Make sure the key field is marked correctly, then check all the other fields as updateable, and check the Send SQL Updates box in the lower left corner.
>
>The filter is just a 'WHERE' clause, and you got the syntax right for the parameter "?vp_eventid". Now the view will want a value for vp_eventid when it runs. When you click the RUN button, it asks you to enter the vp_eventid value. In your code, however, you put:

>vp_eventid = 12345     && obviously enter character/numeric as required
>sele v_user
>requery()

>and the program accepts YOUR value and runs the view.
>
>Point 4 is getting the right data at startup. First, prepare the view with two parameters: eventid and barnum. When you add a view to the DataEnvironment, one of the properties is NoDataOnLoad. It defaults to FALSE, and you will be asked for the value of vp_eventid. Change it to TRUE.
>Then, when the user has picked BOTH the event and the barnum values in the combos set your variables for EventID and BarNum and then requery the view as above. Finally, refresh the grid to show the data.
>
>I presume you'll want to put the code that requery()s the view in the InteractiveChange() code of the two combos (so either one updates the grid). If that is the case, then be sure you use the combo value as your parameter, NOT the field value of the table in the combo. When you open the form, the combo is blank because the user hasn't picked a value. However, the record pointer of the table that is the rowsource for the combo is at the first record, so it will have a value - but NOT the one you want. If you use the combo.value property, then the grid will stay blank until the user picks a value. As insurance, you can check for this and require values in both combos before the grid can be requeried.
>
>Peter, this is a lot of information. Feel free to ask more questions here or email me (click on the white envelope by my name) if you need more details.
>
>Good luck,
>Barbara
>
>
>
>>Barbara....
>>
>>Hi....
>>
>>Actually, my nievity (sp) to VFP.... I have in the DE, the cursor for the TALLY table, a filter that reads...
>>
>>tally.eventid=event.eventid and tally.barnum=bar.number
>>
>>This seems to work. When the combo's switch the event.eventid or bar.number, the grid updates correctly
>>and displays the records, just not at the preferred times.
>>
>>
>>A view has been suggested for me but... a) I have never used one b) when I tried to create one, i got totally
>>lost c) when I created one with a ?vp_eventid... parameters, as I RAN the form a box appeared asking me
>>for the value for the parameters (not what I want the user to do) d) I wasn't sure HOW to get the view to
>>manipulate the tally table correctly as the changes are being made.
>>
>>
>>I stumpled upon the FILTER option in the DE when someone suggested I use a SET FILTER to control the
>>table. I am probably being to picky, for it seems to be working, just not 100% to my liking. Here is an example...
>>
>>- When the form starts, the combos are blank - nothing listed (so is the grid)
>>- When the user picks the EVENT (no bar yet), the grid fills. It appears to be filling with data that matches
>>the event and the FIRST bar in the list even though it isn't displayed in the combo. I worked around that by
>>setting the BAR to the first record and displaying it on the init. It works, not by choice though.
>>- When the user picks an EVENT, if that event internal flag says it is ready to be processed, it is to go on and
>>continue with the processing. If not, it messageboxs a warning, clears the combo, and sets focus back to the
>>combo. Unfortunately, the grid is STILL populated with the old data at this time. Again, not desireable. This
>>also happens if the user goes and changes the event a midstream... and the changed to event is an invalid one
>>at this time also. The event is blank, but the grid still shows records for a previous event.
>>
>>Bit confusing for me, REALLY confusing for the user who is by far not computer literate.
>>