>Kevin,
>
>What you´ve found of course is about the only way you can solve the problem in .NET, execute it on the server. However, this really is going backwards compared to the possibility you have in VFP. You´re limiting your options. To Put it blunlty in a .NET solution you´ve got one database engine, The SQL sever on the backend. With VFP you´ve got two or more. The SQL Server on the backend plus the local database engine on each layer. A real powerfull thought isn´t it?
>

This is totally wrong... ADO .NET is a data engine that is used in conjunction with other data engines. You say limiting... The fact is Walter, binding up the data logic in Fox has two important limitations. 1 - it is limited to the Fox platform - so it is not very portable. 2 - it placed logic that really belongs in another tier. You see going back to the server as problematic. It is really not a big deal. And if you want to get into a disconnected environment - well...we have MSDE.

And for the record, doesn't the ADO .NET DataTable have a select method? Can't some sql be performed locally on the table? I understand that joins between data tables does not work - but that is more of a perceived problem. Walter, the major problem with your premise is you necessarily start from a VFP perspective. As of now, it is clear you have ZERO clue as to how much that limits and flaws the rest of your analysis.


>
1. First of all. A static META data table is best kept on the front end, so you have the best performance.
>

That is nonesense...for two reasons. 1- what is static today, may not be static tomorrow. And2 , assuming we are talking performance, I have two sub points. A - you really don't need the whole table in one shot and B - any time delay we are talking about could be measured in milleseconds. If you only knew how easy your point can be defeated....

>
If displaying a form, I need to translate a lot of captions, the resultset needs to be at the front end (Whether a cursor or dataset).
>

Sure...but the data is best acquired from a server....You see then, if I have a web-version, the same data logic can be RE-USED.


>
2. OTOH, when merging contents in the database with the translation table, you´ll need to do it on the backend.
>

But you don't discuss the pros and cons. Your "analysis" is flawed.


>
3. I don´t like the idea having such tables stored in a backend database since they potentially can be changed, possibly causing problems.
>

As opposed to distributing a DBF that can be corrupted - which can POSSIBLY cause problems. You see the flaw here Walter. Possible issues - insofar as being counter to your point of view are signficant. BUT, possible problems, insofar as NOT being counter to your point of view - are swept under the rug. This is WHY your analysis is illogical, inconsistient, and flawed.


>
In fact it should be totally hidden as I does not have anything to do with the actual buisiness data the application is storing.
>

Black-boxing something has ZERO to do with geography. If phsical constraints on were certain things take place impact your logical design, then Walter, I would say you better refresh those clearly diminished skill of yours (assuming of course you had them in the first place).


>
Going back to the idea that all DML has to be processed on the backend, indeed is going backwards. In VFP you´ve got a choice,
>

Really... I have a 10gb table that I need to perform some DML on... Do I have choice with VFP? I don't think so....I want tx logging with my transactions? In VFP, do I have choice? No. I want security. Do I have a choice in VFP, no...

Going backwards??????? Don't think so Walter...

>>
If you read a hardcore magazine about developments in the database world, you´ll discover there is a trend that you´ll process the data where it is best. And believe me when I look at some of the reports I´ve got, generating a large table of data out of numerous other tables in both a record oriented and set oriented way, it gives me the horrors when I have to move all that processing over to the backend.
>>

Sounds like you have some design problems if you have to jump through hoops here.


>>
Even SQL server is no match when it comes to data munging especially when record oriented operations come into play. You cannot beat the horsepower of 100 modern desktops processing their reports on the frontend, with a full equiped SQL server running 100 complex reports simultaneously.
>>

Care to make a wager here??? You do realize that with 100 "modern" desktops, you are talking about at least $100K in captial. Careful Walter....don't make the same mistake that Mike Hellend did....


The rest is more of the same...

IAC, you do provide entertainment value Walter. Thanks,