Date/Time for .CDX file

Dear Friends,

I have a fairly sizeable file (but is 'multicated' and different in size  in
several hundred sub-dirs).

I have to ensure that this file has up-to-date indexes. If it doesn't, I
rebuild the .CDX index with five separate 'tags'.

I do have a fairly complex function for evaluating whether the index has to
be rebuilt (e.g., go to each of the tags and determine if 1st and last recor
ds
can be found for each of the five tags, etc)

However, one of my tests is to ensure that the date & time of the index file
is *not older* than the date/time of the database file.

In some instances, the index file 'falls behind' in time even though at
least one tag is activated and is being used, and fields are being replaced,
and the file is closed.  When I look at the 'time' of the .cdx file  it is
sometimes a minute or so 'behind' the time of the database.

Q: Aside from changing a key to 'blank', then replacing a key field with the
original value,  is there any other simple way to 'force' the updating of th
e
.cdx file so the time of the .cdx file is >= to the time of the database ??

TIA,

-Mel Smith

Mel,

>Q: Aside from changing a key to 'blank', then replacing a key field with th
e
>original value,  is there any other simple way to 'force' the updating of t
he
>.cdx file so the time of the .cdx file is >= to the time of the database ??

Could by any chance what you see have anything to do with committing
and/or caching? What about the usual registry hacks from Nick's NT
networking page?

Klas

-------
klas dot engwall at engwall dot com

Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]

Klas says:

>Could by any chance what you see have anything to do with committing
>and/or caching?

I don't know.  What I do after accessing and replacing fields in the
database is to close the dbf and then (at the Command Prompt) look at the
dates/times of both files, and then find that the .cdx file is from seconds 
to
minutes *behind* the .dbf date/time. Since I'm testing this on my own Win98S
E
machine in Arizona, and am not on a network here, I thought that *both* file
s
would have identical dates/times.

So, I'm looking for a quick method to ensure the .cdx file is kept 'in step'
with the dbf file when tags are active (which, for me they almost always are
 !)


>What about the usual registry hacks from Nick's NT
>networking page?

From down here now in Arizona, I'm not able to do registry hacks in Canada
(and have never done a hack anyway). and  I'm frightened of this :))


-Mel Smith

On 17 Nov 2004 19:28:16 GMT,
Mel Smith <medsyntel@aol.comnocrud> wrote:
> Dear Friends,
>    I have a fairly sizeable file (but is 'multicated' and different in siz
e  in
> several hundred sub-dirs).
>    I have to ensure that this file has up-to-date indexes. If it doesn't, 
I
> rebuild the .CDX index with five separate 'tags'.
>    I do have a fairly complex function for evaluating whether the index ha
s to
> be rebuilt (e.g., go to each of the tags and determine if 1st and last rec
ords
> can be found for each of the five tags, etc)
>    However, one of my tests is to ensure that the date & time of the index
 file
> is *not older* than the date/time of the database file.

This is wrong. The DBF may be changed and index not update when
you modify non-indexed field. Also some other things may force
database updating when index does not have to be updated.

>    In some instances, the index file 'falls behind' in time even though at
> least one tag is activated and is being used, and fields are being replace
d,
> and the file is closed.  When I look at the 'time' of the .cdx file  it is
> sometimes a minute or so 'behind' the time of the database.

This is the second problem different OS-es may update file i-nodes or
directory items in different time / operations.

> Q: Aside from changing a key to 'blank', then replacing a key field with t
he
> original value,  is there any other simple way to 'force' the updating of 
the
> .cdx file so the time of the .cdx file is >= to the time of the database ??[/color
]

There is no way to use correctly such mechanism due to differences in
operating systems and DBF updates which don't cause index modification.

best regards,
Przemek

Przemek,

Thanks for the information. I'll change my index-checking function.

-Mel Smith

Mel,

>   So, I'm looking for a quick method to ensure the .cdx file is kept 'in s
tep'
>with the dbf file when tags are active (which, for me they almost always are !)[/co
lor]

Now that The Master has spoken I won't try to make any further
suggestions in this area <g>.
 
>
>   From down here now in Arizona, I'm not able to do registry hacks in Canada[/colo
r]

I suppose you would have to wait until your Canadian office comes out
of the ice next spring <g>.

>(and have never done a hack anyway). and  I'm frightened of this :))

There is nothing to be frightened of if you apply the .reg files from
Nick's site. It is quite painless, actually - not at all like going to
the dentist <g>. In the mean time you can go to ...

http://www.witzendcs.co.uk/html/nt_networking.html

... to learn about how to make NT/Win2K/XP cooperate with Clipper
applications.

Regards,
Klas

-------
klas dot engwall at engwall dot com

Spammers, please use this address :-) mailto:postmaster@[127.0.0.1]

Klas,
Thanks for the info. I don't feel so 'fearful' now.

-Mel

Klas says:

>Could by any chance what you see have anything to do with committing
>and/or caching?

I don't know.  What I do after accessing and replacing fields in the
database is to close the dbf and then (at the Command Prompt) look at the
dates/times of both files, and then find that the .cdx file is from seconds 
to
minutes *behind* the .dbf date/time. Since I'm testing this on my own Win98S
E
machine in Arizona, and am not on a network here, I thought that *both* file
s
would have identical dates/times.

So, I'm looking for a quick method to ensure the .cdx file is kept 'in step'
with the dbf file when tags are active (which, for me they almost always are
 !)


>What about the usual registry hacks from Nick's NT
>networking page?

From down here now in Arizona, I'm not able to do registry hacks in Canada
(and have never done a hack anyway). and  I'm frightened of this :))


-Mel Smith

Klas,
Thanks for the info. I don't feel so 'fearful' now.

-Mel