John,

>BTW Walter... this is a good discussion.. :)

I'm glad we agree. ;-)

>>What about non-c/s envroments (I mean without a database server) ? Second I very much like the idea of having both large datasets in the back-end as the front end: The back-end for transaction purposes, referential integrity, security, the front end for OLAP and reporting purposes (this won't burden the database server in processing trancactions, minimizing concurrency problems). So IMO they're not mutual exclusive. As I said before in a previous conversation, replication of data is a powerfull feature (if possible in your environment).

>If it is a non-data environment, why bother with VFP?

Well, why not ? If VFP is the language you know best and don't run into issues that cannot be done (or can be avoided) in VFP, why skip VFP ? The point is, that I don't like the idea of having two different programming languages in one project or application when not (absolutely) neccesary. For example, for maintainance it reqiures skilled programmers who are familiar with both. Given the fact that it's hard to find a skilled VFP programmer these day's, don't even think about a person who's skilled in both.

>As far asl OLAP goes - ADO-MD handles that in conconjunction with SQL-Server.

Could you explain this a bit more, I don't know too much about ADO. Where is the data (handled for OLAP purposes stored ?) If still on the server, you would not have the advantage of taking off serious processing loads off the database server. This can become important if you want to have a secure isolation level in which reading locks could block update transactions. Another strategy would be then only generating long reports in batch at nighttime, but I really think we should forget this past and move along.

>As far as data replication goes, all the more reason why to use other tools like SQL-Server. IMO, data belongs on the server, and only a minimal amount should be returned to the client...

IMO C/S is a relative thing. I did not mean that the replicated data is stored on the workstation, but on a regular file server in a Lan environment. I know you'll come up with the question: what about WAN environments. You're right this one could a bit more difficult to apply replication, as participants (subscribers) could not be available or only have a unreliable connection at the moment of scheduled replication. But still, if (one to a limited number of) LANs are connected with the server through a (reliable) WAN, replication to a (heterogenious) databasesystem could solve many performance issues.

As for the data belongs to the server argument: I can imagine that if it regards sensitive data, and replication into an environment where the DBF oriented files can easely be accessed, you could have a security problem. Though there are possible mechanisms to protect this data, it might be a better idea to skip the replication or make sure that only unsecure data is used. Of course, you'll not need all the data stored in the database server, only usefull data should be replicated to the VFP database. When applying D(distributed)RDBMS concepts (though this technology seems to be rather dead), data belongs there where it is most frequently accessed. Let's say that Site A generates data, but in Site B this data is frequenly accessed, then why not replicate the data from site A to Site B, so that 1: the database of A is not accessed with loading queries of SITE B and 2: the WAN connection is not used when quering this data.

In any case, I think that it may be a wise decision to take this replication mechanism into consideration when developing a C/S (thus with any database server) VFP application.

>As you said in this thread, we cannot wait for enhancements which are already available in other environments. As we both don't know what VFP has to offer in the next version, I don't draw conclusions on future enhancements. As for the benefits of OO in UI development I don't agree: Much of my personal framework as other commercial frameworks rely on inheritance. Without inheritance I probably would not program in VFP.

>Inheritance on the UI is important.. And for the most part, the world knows a good deal of what will be in the next version... As for what I know personally, no comment...

NDA ?

>Tell me then, despite the fast database engine, am I to conclude that even with that, if inheritance did not exists, you would not program in VFP? It would seem that the fast local db-engine you are trotting out in reality, is not that important...

It's a calculation of things, Yes, the data engine is very important. But if inheritance would not exist I'd probably would look for other environments. Delphi looks like a good alternative. It has earned much respect in software development and it looks as if it's going to be available at the LINUX os and seem to have a bright future for that reason. I don't know too much of delphi, but since it's developed by borland, it seems to me that it would work nicely with data. I'm sure not as fast as VFP, but personally I find inheritance just a bit more important than having the most fastest local database engine in the world. To me it's just like choosing between a using a PIII 800-Mhz with out a printer and a PIII 600 with a laserprinter.

>See notes above. IMO C/S and VFP specific data centric commands are not mutual exclusive.

>Well, if I need stuff like this, I am not cut off from it. Instead of binding it my app logic, I may elect to use a stored proc instead....

Yes, this is another alternative, but since I'm not an expert on the SQL server (7) implementation of data centric commands that can be used for DML actions, I doubt if you're as flexible as using VFP commands.

>Could you explain this a bit more. I don't understand why VFP's data centric language cannot play an important role in any layer of a N-tier approach.

>I did not say that at some point, VFP could not play an important role in one or more tiers...

>The point I am making is that VFP does not have the advantages that folks claim it has. The advantages being trotted out are 5+ years old. Guess what, the rest of the world has caught up. Look at the progress VB has made. Match that up with the progress VFP has made. In the past 5 years, VFP is roughly 80% the same product. It would appear the innovations are bypassing VFP in favor of other VS tools...

I could not comment on that one. But to summarize: I think that lot's of jobs can be done in either development tool. Sure, if I encounter situations where VFP could not get the job done and VB is the most easy way to fill up the gap, I might consider of using this (or hire some else to do the job). But my standpoint is: If VFP is your development tool of choice, try to do as much as posible (and acceptable) in VFP and look outside the VFP box for those cases you cannot solve otherwise.

Sidenote: I try hard to investigate before I open my mouth (sorry folks if you get another impression), I sure don't buy easy made statements. In the past I showed that I'm willing to critisize general accepted principles, as I will in the future. Sometimes I'm right, something I don't, sometimes both, sometimes just a matter of opinion. But this is really not the issue: it's about that there is thought about and we all can learn from a constructive discussion (God.. I love discussions !). It's up to the reader to draw it's own conclusions to make up whats right for his own situation.


Regards,

Walter,