Re: foundations of relational theory?

Well put Chandru. My feeling here is that SQL was originally designed as a Data Extraction Tool (i.e. query language). SQL was really nothing more than a 'APPLICATION' that then touched the database. SQL was then extended to do updates and was extended to be a end-all data access application. The nice thing about this model was that it forced all data access to go thru this one app. Any of us that write application understand the benefits of using a standardized module for data access/update.

Data integrity then became an issue. Data contraints were added, then triggers, etc. But I believe we (the industry) has finally realized that this was the wrong direction and has moved towards the 3-tier data model. In this model we do not allow the end user direct access to the database. Instead we develop business modules that the user calls. This model has the advantages of Forced Data Integrity, the end user does not have to know our data model. Essentially it creates customized mini-sql engines for our data objects. As I study this model more and play with it with Microsoft .net, Disconnected datasets, and XML data sets, I really feel this is the future.

In this arena Pick is well positioned to do well. Why? Because we have a well integrated data tool (pick basic) that functions just fine as the language for the Business Logic. Before windows, pick competed just fine because of it's ease of use and speed in this area. Only as windows grew in popularity and picks inability to easily integrate with SQL tools did pick start to decline. I am now writing Pick Business Logic modules that are returning XML Datasets to a Microsoft Visual Basic Front end.

• Patrick