Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
BUG: VFP7 SP1 REINDEX no longer removes BLOAT from .CDX
Message
From
06/05/2002 15:29:08
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00652071
Message ID:
00653216
Views:
22
>This actually gets me worried. I start sounding like a professor again :).
>
>< g >Probably not a bad thing.

I'm actually getting a Pavlov's reflex here (named after the guy who had so good reflexes... you know, the dog rings a bell and his knee-jerk reflex is to feed the dog) - whenever I start sounding like this, our youngest daughter starts making faces and rapidly cuts her attention span, so I'm always on guard trying to catch myself in time :)

>When I started working in FoxBASE+, I had a awful time because I followed what examples I had. More and more I became convinced that what I had been told was correct. Then, I had a realization. What I had been taught was correct. What I had been taught was designed to work in the real world. It had just been improperly implemented.
>
>Once that sunk in, I became more productive. More often than not, people designed to the exceptions rather than the rules. In doing so, they got things backwards, because design has to be to the rules, and the exceptions have to be handled.
>
>Such it is here. Taking advantage of an undocumented feature goes against the rules. You don't know when or if the feature will change.

Regarding indexes, I remember the reindex causing bloat in 1.02 and maybe 2.0, but can't really be sure about 2.0 because I already wrote a generator for indexs.prg by that time, which actually killed off the cdx files and created them from scratch, just in case, and not primarily to remove the bloat, but rather to make sure a screwed-up tag header won't stop the routine from opening the table.

I do agree with this attitude regarding workarounds. More ofen than we dare confess we develop a pattern the main purpose of which is to circumvent some shortcoming of the current technology. When the time comes to move to a new technology, it's time to rethink the thing: do we really have a problem implementing this old technique in the new version, or is it a problem that we don't really need the technique anymore?

One example was the print into text files I used in DOS days, because machines were slow and some reports took quite a time to run, so their results stayed on disk and could be viewed, printed as many times you want, and even partially printed (yup, I was analysing the textfile, counting formfeeds etc).

Can't do that with reports which go to a laser or a spitter (pet name for inkjets). How did I solve this? I didn't - today's machines are fast enough, you get to view the report properly from within Fox, and the whole thing is unnecessary. Goodbye to printing to txt files.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Reply
Map
View

Click here to load this message in the networking platform