Hi thomas,

>>I Don't think this is the case. Replacing a server is not something you do overight, however with the cheap and very powerfull desktops today I would think that for CPU resources and 1 to 2 comparison is fair.

>Here I think you underestimate *at least* the work of the DBA. In most "company networks" where I am given a machine I can usually make that machine run the needed jobs in 30 to 80% of the time that was needed when the config was the "company standard". Triple was a special case, but it happened. OTOH, the server usually is looked after, and if the DBA has any brains he will easily surpass the level I reach with half a day of usually forbidden tinkering <g>. Just comparing potential horsepower doesn't count in large companies, especially if you probably also took some time to check your own client station <bg>.

Of course the DBA is some parameter in this comparison. It also depends on the hardware configuration of both client and server. With these powerfull desktops with lots of ram available you often have a situation where the server CPU power is not that different from the client. It might not be a big deal to replace a few clients with new hardware, but you will hesitate to replace the heavy equiped dual XEON processor SQL server with raid 5 controlers etc, simply because of costs.

However, even if the comparison was about 1:3 or 1:4, if the number of clients running processes on the server exceed the 3 or 4, a workstation data munging process pays off.

>>This is exactly why VFP is so powerfull. It both supports set oriented operations through SQL and the record oriented xBase commands. VFP gives you the best of both worlds.

>Yup. But I sometimes wonder if we aren't sometimes spoiled / use the xBase way because it is so damned easy. Cut and paste inheritance ***will*** get you the results faster today and only bite you in the days to come, to give a very loaded anti-example.

So true. You should be aware of what is a valid architecture. For example you'd better not use xBase operations on database tables if your application might be client/server some day. Then use local views or specificly reduce the amount of work by making it possible to use SPT. When working on local cursors (or views) I don't see any problem in using xBase syntax to solve a problem.

>> but be aware that in many datamunging operations the calculated resultset
>>might exceed the original size of the dowloaded set, so this is a very arbritary argument.

>This is a VERY valid point and often overlooked. OTOH, the best practice of .Net (as I interpret it) is to push the needed/where-defined sub parts of the tables into the dataset and "join" there into a hierarchical schema with the datarelation. So I guess the problem is seen by MS, but the need for large parts of the server side table at the client may be underestimated.

I know, but the datamunging capabilities of ADO.NET are limited. True, you can set relations in the very same way as you do with SET RELATION, but if it becomes more complex this is still going to be a PITA.

>>True, but this is the point. In datadriven applications you have lots of (META) data on the client that needs to be processed for various internal reasons (as mentioned in the previous post).

>I group/view META data with "stable lookup data" and am a firm believer it should be on the client. BUT if the client is given the ability to query this data from a *local* database, the technical benefeit is almost the same. So it might boil down to installation/replication issues. Probably a PITA nevertheless.

I totally agree, however I don't see for example MSDE as a valid alternative. It does not have the datamunging capabilities it should have and about every ODBC or OLE DB complient database only supports set oriented access or SPs, and I really hate using SPs for that reason.

The one and only solid solution would be a local database easy accesible through the language, either natively or through add on libraries or classes, supporting both SET oriented and record oriented operations. Probably somewhere in the future .NET will integrate this feature and that will be the time that the GAP between .NET and VFP will close (and a VFP.NET will become achievable).

>On the parts of datamunging buit into the language: I am waiting to see how good the coming integration of the "normal" programming languages into YUKON will be. Imagine a setup where you have the same [easily?] programmable dataengine on client and server, thus you can distribute the "application data" to the clients for fast access and "work data" to the server. Qustion is, will MSDE be enough for local datamunging ?

We will have to see. I suspect not in first instance, but we will be moving towards this architecture I believe (As we already have in VFP). However, I don't think you need something like MSDE on the client, but rather an engine without the server features like security but rather a VFP like engine which is only used to process local data.

>I believe the other players have realized, that "pure" SQL is not enough for "the database" - Oracle is favoring java (small wonder), MS plans to give similar capabilities to SQL-Server with the .Net languages...
>Intersting times ahead. VFP has quite a few strengths, but as we all know has also areas where we have to program around the deficencies. But we are used to that <g>...

Personally I don't believe in poisoning SQL server with more programming capabilities beyond the current set. It is my strong conviction that the SQL server should serve data and not doing any other programming tasks. Extensive datamunging IMO does not belong here. It should be done in the front end or a middle tier. You don't want to burden SQLs performance for these tasks that could be done elsewhere.

The other players in the DB world do virtually have no other choice than implement this as for client software whithout local database processing capabilities this seems an attractive way to get more processing power. However, IMO the DB vendors are providing a solution for problems that exist in the client software development tools. Not the optimal solution if you'd ask me.
However it is not that easy to see for someone who does not have experience in having the luxury of having a local database: In the land of the blinds, OneEye is king.

Walter,