Hi kevin,

>I was actually more interested in the local-data performence, I think I may have to try something else, the string handling side of it I'm not too bothered about.

I don't see how your example has much to do with the local data-engine. The scan is very quick and percentage wise does not play any role in the whole picture.

>I would be very interested in performance with the local data-engine, perhaps if you were to knock up some powerful local data-engine tests I might be able to try it in C# and potentially spot weaknesses in ADO.Net.

Well, of course there are numerous examples thinkable, but for a start you could do something like:

1. Of a retrieved resultset, display the results in a grid. In C#, use a suitable control (datagrid?) and in VFP use a VFP native grid. Assuming that it takes the same amount of time to get the resultset from the backend into C# and VFP respecitvely, record the time that is needed to fill the grid. Let's do this for 10 records and 100 records.

2. My favourate: From a retrieved dataset, get the upper boss of a random employee. In VFP you can use an index and a loop, In c# You've got to dig into the derived collection. Lets test this for 100 and 1000 records.

3. A very common one for reporting. Some integer value from the backend translates into a meaningfull character value or is a key to another local table. Munge the data so that it becomes one table again suitable for reporting (Note that in VFP you'd probably use a SQL SELECT Command to do this. Since C# is not capable of doing this locally, you'd probably end up doing relations in ADO.NET). Let's do this for 10, 100 and 1000 records.

4. From a retrieved dataset increase the value of any numeric column with 1 for any odd value. Lets do this for 10, 100 and 1000 records.

5. From a retrieve dataset containing a year, replace the value of any column with a any value for every leap year.

Of course, everyone is free to add some more.


>Thanks
>Kev