>>I think you need to realize that most of these apps do have a -real- DBMS interface via LDAP and ADO and automation; there are lots of things which benefit from a non-relational data model, and incurring the overhead of integration of a database into everything doesn't fly - anyone else remember PICK? There were many othr fail db-centric systems which failed.
>
>And let's not forget about IBM's System 38, where the DBMS was built into the hardware.

VAX VMS had a indexing and table routines at the OS level, so all the languages uset them as system calls. It had trimmed char fields (yes, a variable length string, which was converted to full length on read, so COBOL thought everything's normal) and other stuff which worked regardless of the language. You could write a record in Pascal and read it from Basic.

> I hardly think that the database requirements of Outlook or Outlook Express would significantly tax the capabilities of VFP.

While we're at it, does anyone do messages export into VFP tables, but not by using Outlook's own export? That thing doesn't export such small and unimportant things as dates and times, and the message header seems to vanish in a puff of M$, because there's no way you can see it anymore. Not that I know.

>To the extent that these products do make appropriate use of generic database functions, those were poor choices to make my point.

Actually, you did make a point. If ever in Outlook (2000 in my case) you get back to a message you replied to, try to click on the info line (the yellow one where it says 'click here to find related messages'). The times it gives me are at least twice as long as the average time I get on UT for "See the entire thread". I'm using 56K modem from home. One would think Outlook had some indexes on message IDs to keep related messages together.