I'm not sure I understand your question but I'll put in my $0.02...

<< I am interested in discussing the pro's and con's of having a single business object based on a view with multiple view parameters, or having multiple views, each with only the parameters required. On some of my tables, the number of frequently searchable fields could be as many as say eight to ten, but most commonly no more than one to three. Each criteria is unique enough to warrant and index for speed, and so regardless of the approach, I would think optimization would not suffer. >>

It kind of depends on the purpose of the application - if these are combo box look-ups you may need to have them seperated into different views. However, if you have a grid display situation one view with several view parameter would be the way to go.

The part of having one business object is a little confusing for me - If these views are not updatable and are simply support views for a specific business object then having one business object with several views is perfectly acceptable. If you have several views that need to be updated, unless they are part of the same family of tables, you should have a business object for each view. Again, I'n not sure what it is you're trying to do so it's a little difficult to make any recommendations on the best use for business objects and views.

<< I am thinking more along the lines of maintenance. The bizobj can fill in any unused or unsupplied parameters, and in doing so, would reduce the number of views and environments I must maintain. >>

While making maintenance easier you might restrict yourself when it comes time to scale. What if you need these views elsewhere or they become updatable in the future? Although, I see nothing wrong with what your trying to do it's hard to determine if in the future you loose encapsulation. Say for example you decide to put several views in one business object and there is code in several methods specifically for each view - if any of those views are used elsewhere you start duplicating code at that point. Worse yet, you change on code base and forget to change the other.

<< Currently this I am using local views, but this could go to SQL server in fairly short order, so if there are RV/SPT issues here as well, any thoughts would be helpful. >>

If this is the case, you may want to place each view in it's own business object. What this will buy you is the ability to scale individual tables one at a time. Most system, especially production systems, are not built or upsized over-night - even if they are you still need time for debugging and tuning. Most of the projects that I've dealt with when upsizing data is done portions at a time.

One other thing to keep in mind - performance in FoxPro is never the same when updsize to SQL Server. You may end up changing code in order to gain better performance from one to the other.

Hope this helps...