June,

Ah, so you meant the filter as in the WHERE clause of your view. My mistake. Glad you got it working.

We've always maintained different views for a given table mainly based on those WHERE clauses. IOW, we mainly have "SELECT *" based views. The exceptions are when we have "wide" (high byte count per record) tables. Then, we try to pare down to only the fields that are needed for a given task.

We've found that determining which tables are handled which way can only be done through testing speed and server performance.

Otherwise, you're correct. You'll end up with an over-proliferation of views, which leads to an overworked DBA (probably you?)

---J

>Thanks for the reply. My use of terminology may have caught me up here. What I had was two views where I had specified some filter conditions in the view designer.
>
>I am still struggling(?) with "how, when, where and why" to use a new view in MM and VFP, and fear I may have gone overboard in that I seem to have an abundance of views for a relatively simple application. Is this typical, or do most apps have only a few views that are more general, as opposed to a specific view for each aspect of the data?
>
>I have a view that is basically everything in the table, which I could use for just about every aspect of this app, but I got the impression that that was not the "proper" way to handle things as if an app gets converted to remote views, then you don't want to download everything from the back end. Now, this app will probably never be used with remote data, but I figured that good coding practices should be followed regardless. Of course, that requires that I recognize what "good coding practices" are <g>
>
>Thanks,
>
>June