Hi kevin,

>>>>I suspect this is one of the pitfalls people could fall in when it seems difficult to get your data in a form that is directly usable in your front end, but this is really bad, bad practise.
>>>
>>>I'll rephrase that, the Database was designed badly and with useless naming conventions etc. and in some cases does not follow normalisation rules.
>>>
>>>What I meant is by today's standards the db could be looked at as a whole, because it's an old DB (12 years) it has had a lot of "crap" added to it with no regard as to how these alterations fit into the big picture.
>>>
>>>In other words, I would revisit the DB design as my chosen example DB is IMO fundamentally flawed in some areas.
>>
>>O.K. that makes things clear.
>
>I wander if the test will still be viable if the C# version used an SQL Server instead of Fox tables, you know, the whole Fox vs .Net+SQL Server lark....

I don't think those test compare. If you're doing .NET/SQL server, you should compare it with VFP/SQL server. FYI, I don't think it is fruitfull to include the retrival of any data from the database in a comparison. I think we all agree now that there is not much of difference when retrieving data from a SQL server in .NET or VFP. Only the exception of when using large resultsets, in which .NET can become slugish. I think we should ignore that for now.

The real chalenge would be to see how C# processes data from one form to another out of one or two ADO recordsets and compare this with the performance and ease of its VFP equivalent. This IMO, is the real challange. Again IMO the link to my appointment scheduler example might be a good candidate. If there is not big difference in implementing this (Again from the POV of performance, ease of implementation, debugging and maintenance), then you've got a new .NET believer.

Walter,