The LA Fox Developer Newsletter

February 1994

XPro User Group News (con’t)

their product line. My evaluation? MSFT can be trusted with the future of FoxPro as much as any business that desires success and profits. And, I think they have pretty much demonstrated that desire, to understate it.

Fm: Randy Unruh To: PeterStelman Peter,>>Xbase standards.. .OOPs Whatever the outcome of the committee’s work, it provides a valuable forum where the Xbase vendors (MSFT, Borland, CA etc.) can discuss OOPs syntax standardization without committing collusion (since it is essentially public discussion). And, I assure you they have discussed the issues and will have the opportunity to continue to do so. Though a committee cannot dictate standards fast enough to meet the market,it can recognize the best solutions that appear over time. Out of that it can make standards decisions that will tend to hold down too much divergence. So, Xbase will be around awhile longer.

Fm: Randy Unruh To: Bernie Mondschein Bernie,>> MSFT will eventually have to decide which of its products to throw its weight behind. Why does it need to be exclusive? If you _reatly_ understand MSFT’s long-term strategy, it consists of an eventual single product, with _three _procedural languages to pick from (BASIC, C/C++ and Xbase). Or to put it another way, one set of developer “tools” to use with your choice language. Bill Gates said this at the ‘92 Comdex launch of Access/FoxPro 2.5. I know, I was invited by MSFT as part of the multimedia event to talk to the press about these products. Since Xbase syntatically is a better language than BASIC or C/C++ for data- oriented application development, it is unlikely MSFT would hobble their effort of evolving successful database products by excluding Xbase. And,since the MSFT stated goals of abilities/ capabilities for each round of the next release is well known, I see nothing to indicate that MSFT has the least intention of abandoning FoxPro in favor of Access or Visual Basic.

Fm: Randy Unruh To: Daniel Weese Daniel,>>.. .not even Microsoft can kill the DBFN0, but it will eventually evolve or wither away. Besides the fact that I’m a member of the X3J19 Xbase Standards Committee and get to see what all of the vendors position is on this issue, it makes

sense that the DBFs days are numbered. After all do - you want to stay limited to ten character field names and passive, or at best “linked”, data dictionarys? Something better will evolve in the not-to-distant future. The hope is that it will be something standard.

The following message was in regards to a question a fellow named Tom Meeks posted. In particular, it was a response to a question regarding the phenomena of CDX Bloat.

Fm: Randy Unruh To: Tom Meeks Tom,>>(Append deleted records).. .This has some effect on the CDX bloat. CDX bloat happens when you change tag expressions (INDEX ON whatever TAGalready_ exists). This happens because the existing copy of the tag is left in the CDX file and a new one is created. This was done (I suspect from the experience of having worked at Ashton Tate where Xbase compound index files were invented) for performance reasons. If this was not done, the index file would have to have the existing TAG removed in an operation similar to a dbf PACK. The way around this is to DELETE TAG ALL and recreate the tags or to issue a REINDEX. I generally don’t recommend the latter option within applications because if the TAG headers that store the information have been corrupted, the operation will fail or produce unreliable results. Anyway, appending records (deleted or not) does not cause CDX bloat. P.S. I couldn’t agree more that Dick’s operational descriptions are great reading !<s>

That last line is in reference to a fellow named Dick Whetstone who manages a MIS operation at the Christian Broadcasting Network. They work in FoxPro and the interesting point is the large number of users and developers working with large datafiles. I believe some of his messages will be interesting reading so here are a few:

As a side note to the earlier discussion on archive storage needs, we finally reached a consensus on the archive media and have ordered an optical “jukebox” system that will provide us with the capability of putting our archival data on permanent media. This is really good news to me, the less data that is out there on hard disk volumes, the less I have to worry about. Structure changes are pretty rare but they do happen. We spent months in datamodeling sessions during the design phase and consequently things were pretty

Page 4