Walter,

>Well, not necessarily. For optional parameters, yes you use overloaded methods. For flexible parameters, you can either use overloaded methods or have your parameters simply be object types and test for type in code. There's always several ways to skin a cat. <g>

I know... beaten by my own words.... Anyways it was about the statement that strong typing is not neccesarely a benefit to the developer.

>>The case argues that if you've got to implement a SQL query in ADO.NET by iterating through collections and/or calling a collection of ADO.NET methods, you have to do a lot of programming to mimmick the SQL command (The SQL SELECTs internals). In this process you can write a lot of bugs because these types of queries normally are not simple.

>No, you don't *have* to iterate through rows in the DataRowCollection. You can use a the .Select() method of a DataTable to return an array of rows that you need. Pretty simple.

First of all the SELECT() method only does filtering and sorting is not comparable with a SQL SELECT statement. No support for joining other tables, subqueries, grouping, summary calculation etc. IOW no support for SQL SELECT queries.

Second, how do you think the select method will execute this query? It does not have no concept for indexes (except maybe for the PK?) so it cannot optimize. It has to iterate through the collections to do the calculations.

>Yes, of course I know how DataViews work. You're correct that they wouldn't be optimized, but with smaller DataSets, it wouldn't be a problem. If you have larger DataSets, then you most likely wouldn't use a DataView.

Well for datamunging tasks this performance difference with VFPs approach becomes significant even with one or a few hundred records.

Walter,