>Very good response, Joe,

Thanks, Cecil.

There's one technical area that I should address, and that's the reasoning behind VPM's proprietary data dictionary. Perhaps, I can explain why we think it makes sense.

To understand why VPM has its own data dictionary, we must take a trip down memory lane. We must go back to the introduction of Visual FoxPro in 1995. If my memory serves me correctly, in 1995 there were five significant players in the FoxPro framework world: FoxExpress, Doug Hennig's AppMaker, the predecessor to Codemine (I forget its name), Tom Rettig's Office and ProMatrix.

When the framework vendors saw VFP 3.0, I think it is safe to say that we all felt that the data dictionary provided by the VFP DBC was not sufficient. It simply did not contain enough meta-data. We all realized that we would need to extend the DBC to include the things that a full data dictionary needed to have.

Tom Rettig rather quickly published a document that described his methodology for extending the DBC. As one would expect, Tom's DD extensions were quite ambitious. Tom was very thorough.

A group of companies that had announced that they would be developing either "Codebook" compliant or compatible products announced that they would be developing their own standard for extending the DBC which they labled "DBCX" for "DBC Extensions". Originally, the folks at FoxExpress took on the responsibility for coordinating the development of the DBCX standards.

We, on the other hand, already had an extensive data dictionary that we did not want to give up. Consequently, we decided to adopt our own standard for DBC extensions based on our own data dictionary structure. That's what we did, and our users seem to feel that the ProMatrix data dictionary and the related ProMatrix data engine with all its data integrity features are major strengths of ProMatrix. The data dictionary allows much of the functionality of a VPM application to be data-driven. And when used in a client-server configuration, the ProMatrix data dictionary's entity, domain and referential integrity functionality allow much of the load to be taken off the database server. Data validation and referential integrity can be peformed by the front-end or a middle-tier before data hits the database server.

However, there was another factor at play in our decision to keep such an extensive data dictionary independent of the DBC. We realized that when the time came to build versions of ProMatrix for platforms other than VFP, our data dictionary and data engine could be easily ported to those other platforms. We couldn't so easily do that if we had built our data dictionary functionality into the DBC.

This concept will be featured next month when we release the ProMatrix Data Server. (You've probably seen references to the PDS in our newsgroups.) The PDS is an XML Web Service with all the functionality of the ProMatrix Data Dictionary and data engine. The PDS is a middle-tier business/data object that can be used by any front-end client that can access an XML Web Service to access virtually any backend database (i.e., FoxPro, SQL Server, Oracle, etc.). The PDS provides all the data handling, data integrity and data tools provided by a VPM Enterprise application. For example, a developer who needs to quickly create an ASP.NET Web Application to access an Oracle database can use the ProMatrix Data Server and avoid all the work required to create his own business and data objects.

The beauty of this concept for VPME users is that if they already have set up the VPME data dictionary for an application and now need to create, say, an ASP.NET or .NET Windows Forms application, they can simply run a utility routine to load the PDS DD from their VPME DD and the PDS will be 90%+ set up. They will then be able to focus on building the presentation layer of their ASP.NET application with calls to the PDS as needed to retrieve, insert, update and validate data and to perform functions such as retrieving field properties from the DD.

Right now the PDS has been built in VFP 7.0. When we create a version of the PDS written in C# and using ADO.NET, we won't have to change the data dictionary structure much at all, if any.

Does this help you better understand the capabilities of the ProMatrix DD and why we have it?

Best,

Joe