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 stan-

dardization 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 com-

mittee 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 _proce-

dural languages to pick from (BASIC, C/C++ and

Xbase). Or to put it another way, one set of devel-

oper “tools” to use with your choice language. Bill

Gates said this at the ‘92 Comdex launch of Ac-

cess/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 suc-

cessful 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. Be-

sides 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 cor-

rupted, 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:

Fm:

Dick Whetstone

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