Hi Andrea,

>
>Whoa ! Well, if I've understood you right, as long as you need to fetch different data-sets from the same table for sifferent purposes it's ok to have different views, because the only thing that they've in common is the main updatable table and not the parameters...
>Anyway, if you're using the *same* updatable view in all six forms, be sure to have a default data session or you'll have to requery it each time...
>
Yup, that's right. *s*

Actually, I am using PDS with these forms, as they are modeless and can all be active at one time. So they will be requerying the updatable view independantly of each other.

I can't take any credit for the idea, as it's part of the framework I am using, but I sure look good to my client.

>>These forms are working quite nicely at this time, thanks to Steve's pointer on using the sequential join syntax for the updatable view.
>
>Yes, I've discovered the trick only two or three days before Steve's message, and now everything works well. If you accept another suggestion, look for the gendbc.prg program in the tools folder of VFP. It gives you the code for your entire database, including views, and could be very useful to generate .prg(s) for complex views. Just build an updatable view with no more than two joined tables, and adjust every parameter like default values, rules and so on. Then run gendbc.prg and you'll have the code skeleton to make a more complex one....
>

Yes, Mr. GenDBC and I are old friends. Steve's tip on using a FUNCTION/END FUNCTION in a procedure was right on target too. Obviously, this is a very common approach to dealing with more than just simple views.

Talk to you later...

Kendall