Hi
>Well, if you want to do xBase like row by row processing, no. Although, when you USE a table and process it row by row you are pulling stuff into memory.
Yes, but not load everything, then processing. I've seen that something like this will be possible in the next version of VS.NET
>
>But, you could write VFP SP's in your database to do these large data processing tasks.
>
>>If is so good, why so many "database engines" for NET?
>
>There is ONE data access strategy which connections to many data providers, SQL Server being one, OLE-DB being another. Any data source can be read into a DataReader or DataSet to be used. It is a disconnected design which is solid for distributed applications.
Even in a distributed application make sense to have local data often used to speed up normal application operations. And for this kind of data acces, foxpro engine would be very good, IMO.
>You can search in the dataset as if it were a table, yes. But, if you want to 'search' the whole datatable you're better off with a query, putting the [small] results into a DataSet.
I know, but nothing can beat Foxpro's SET KEY TO :) when I make selections.
>
>>I can bind a Foxpro grid into a 3000 records table in no time because it
>
>What do you need 3000 records in a grid for? The phone book fits millions of names, but I bet you nver want to look at more than a few dozen of them at a time. How? You do a 'query' but looking at the 'index' and finding the right page/column of names, then you look at that. In a distributed app you do the same thing... ask the user for the City, and first few letters of the last name, the query the data, put the 50 or so records in a grid and let them pick one, then use that id to get the rull record.
I don't do such things, I only wanted to say that IS possible, without affecting performance. Would be nice if I can have as many dollars as develpers using "SELECT * FROM {lookup_table}" as command text in command object and then filter needed data after is loaded. And then complains that NET forms are slow :).
>
>>loads only the visible part of the grid from disk. Is somthing like this possible in NET? I'm just curios, I don't have a negative attitude, because I like C# and I want to learn it.
>
>USE ing a table and 'binding' to a grid is not even a best practice in a VFP app these days.
>
>>In this article MSDE or SQL Server CE are recommended.
>>
http://builder.com.com/5100-6387-1058880.html>
>Sure, cause it is pretty ubiquitious. However, if you want to use DBF or MDB is just as doable and works with basically the same code, you just use a different provider.
>
>>But already are many engines with native managed providers for NET. It is sad (for me) that Foxpro engine is not one of them
>
>Yea, I'd like to see a native managed provider for VFP data, that would be cool!!! Of course, Codebase makes one, you just have to pay for it.
Taking into consideration that the VFP OLE DB or ODBC driver is the data engine , that will mean exactly a port of VFP data engine to NET. Will see.
>
>BOb
