Ed,

>XBASE per se is not bad, but in general, expanding on the set of things done with the xBASE dialog, rather than migrating to the newer technologies, seems counterproductive. I certainly don't want to expand the xBASE-ish nature of the language for no real gain - everything he asks for can be done with the DE,

Nope, You can't use this view as a source for a SQL-select command. The trick is that I want to save the VFP-view configuration under a VFP-view name, and being able just to USE it, like you're able with a SQL-view. If you look closely you'll see the OO components within this approach. Preferrably I want to hide the actually implementation of the VFP-view, so the underlying tables and relations should not be visible (or may a switch to turn it on and off for debuggin purposes)

>and the more people move from xBASE, procedural thinking towards OO, set-oriented approaches, the more we'll be able to easily exploit new database technologies within the VFP framework.

I'm talking about new technologies within the VFP framework.

I think you missed the point here. The discussion is about the difference about SQL and the native VFP xBase approach. Talking about new/old technologies, SQL is invented BEFORE there was xBase. SQL is really a bad implementation of the Relational Model, and should be revised really. Problem in this field is that we all are working with SQL, so major changes to the SQL standard seems fairly impossible.

In this topic I adressed a mechanism (if applied) wich shows a far better implementation of the relational model (Yes this is my own observation). Which has/can have HUGE performance advantages over any SQL implementations.

As discussed in a DUTCH database specific magazine, the implementation of SQL in the relational model is a real PIG. If it was implemented correctly it should be blazingly fast without the limitations the current ANSI 92 standard offers

Sadly, to make it a SQL-select-killer there must be done something about the limitations of rushmore (though i might look into that more throughely).

As for the OO thing. I don't see that having anything to do with my request. There are many discussions about real OO databases but not one of them seems to get a fair market share. Besides, when you look at the relation model it won't be difficult to see that there are OO mechanism available (I wonder if the term OO even existed when the relation model was inveted: Codd 1970) To give an example of OO within my solution: this view implementation automaticly inherits the record, field and RI validation rules. Tables can be seen as objects, fields can be seen as properties (or even objects).

Further on if the discussed mechanisme is applied it hides the undelying implementation (encapsultation) and can be used within local view (SQL or VFP) itself again. Even SQL-views could be a part of a VFP view (are you still there ?)

AS for NON - SQL DBMSs you might look at Navision (a Danish product) wich is a logistic-account ERP package for medium-large sized businesses (getting fairly popular here in holland). Its implementation is based on more or less the same priciples where xBase is based on. They've got their own database server wich performs pretty well. They've also developed a SQL-server variant wich is much slower and requires much more resources to do the same job. For references you might talk to someone who is an Navision Expert.

If we want xBase to survive there are invovations needed. I'm suggesting one, though it's clear that you don't see any future for the xBase language.

Walter,