The answer, in my mind anyway, is "It depends".

The irrefutable fact is that as soon as you place a parameter like this on a view then you run into exactly this problem. That is the reason that all of my forms (most anyway) have two types of views ... the view they use to do the Create, Update and Delete with and the views they use to do the Reading or Viewing with ... I call the latter Proxies. The proxy view have just enough columns from the SQL Server table so that the user can identify which record they want to mess with. They then double click on the lookup grid and I populate the view parameter of the main view (usually the iID from the proxy) with the iID from the proxy. This lets me bring back the ENTIRE record from the server for one and only one record.

Also, you don't have to retrieve the iID from the proxy view, in your case you can retrieve the group number, populate the main view's view parameter with that and then requery the main view that way.

But to more directly answer your question I don't know of a way to make a view "ignore" an existing view so as to receive all of the records ... unless it is something like an empty string which always returns .T. on a substring match if on the right hand side of the equation.

The answer also depends upon the following, the type of backend you are using. SQL Server is much more strict that VFP when it comes to that exact same string example above.

Another approach is to come up with some trick with the data so that one of the values you enter meets a substring match. For example, let's assume your group code is an A, B, C, D, E ... you could create a character column in your table that contains TWO positions, the first one being common to all records, lets say a "1" in the first position. The second position could be reserved for one of the real codes.

cGroup

"1A" - belongs to group 1
"1B" - belongs to group 2

This way your view parameter for all records could be vp_cGroupCode = "1" ... the code for returning group one is vp_cGroupCode = "A".

Something like that has to be engineered to make one view work like you are talking about ... the trick here is that the column upon which you are querying has to be string in order to gain the benefit of a substring match provided by VFP's native tables. Otherwise, try using a proxy.

Best,

CT



"A