Hi
I've tried something like this too, with VFP, but using the local embedded Firebird engine and ODBC. The VFP lookup tables "version" was far more responsive (nothing can beat SEEK or SET KEY TO...). Data transfer through ODBC added some overhead, I think. Maybe something like "direct data access" without the need of loading everything in memory is really missing in NET, otherwise I don't see any reason for existance of something like CodeBase NET, VistaDB NET, TurboDB.NET or Apollo database engine. And the use of MSDE for local data processing/persistance is, IMO , something too much. (All above mentioned engines have about 1M)


Dorin
>
>>>I've tried many approaches to make it responsive because it must work over DSL connections with a limit of 256k. Having those tables saved locally through download and some sort of "fake" replication seemed the most efficient solution for our case (max of 40 connections from 4 branches). It simply fly. Wait time is only when a transaction is saved on server or something is retrieved from server, but typically not the data used in lookups.
>
>Yes, I agree. However, you can download lookups as a mdb and use ADO.Net with SQL locally, which is quite acceptable for lower-volume lookups. It does involve more work and I agree it is important not to present this as irrelevant, or (remarkably) as an "advantage" of dotNET just because it can be done!
>
>Regards
>
>j.R