Pack: Deleted records return alive
Davide Guolo
1) I close the dbf
2) I reopen it exclusively
3) pack
4) I recreate the NTX indexes (index on...)
Some records previously marked as <deleted> are now live on the table (I do
not know if is true also the reverse)
I saw nothing strange on the table looking at it with DBU.
It contains 12479 records before packing (after pack they are about 8700)
Table's size is 1.398.035 bytes
Is there some known issue with pack I'm not aware of ?
Clipper 5.2e - RtLink - WinXP
TIA
Davide.
Joe Wright
Like you, I have heard of these problems but have never experienced
them myself. But where there's smoke there might be fire. I never
'pack' large or critical tables. Having marked whichever records for
deletion, I do this..
use table
copy to t for ! deleted()
use
erase table.dbf
rename t.dbf to table.dbf
I don't 'sort' a table either. I do this..
use table
index on key to t
copy to t
use
erase table.dbf
rename t.dbf to table.dbf
I avoid 'pack' and 'sort' most of the time.
--
Joe Wright mailto:joeww...@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Davide Guolo
> them myself. But where there's smoke there might be fire. I never
> 'pack' large or critical tables. Having marked whichever records for
> deletion, I do this..
Thanks Joe.
I'll follow your method too.
Hi,
Davide.
Mario Schulz
it a verz large table. We have changed our pack-routines a long time ago to
copy and/or append in a new empty table. We don´t have problems with deleted
records, but in large tables we hav had problems with memofiles in this way.
As we changed it to copy/append this problems went away. Possible it is the
same problem...
bye,
Mario
--
concept Software
Mario Schulz
Rehhorster Straße 8
23619 Zarpen
Tel.: 04533 / 79 89 89
Fax.: 04533 / 79 83 00
"Davide Guolo" <daNOSP...@tin.it> schrieb im Newsbeitrag
news:i5fnc.44497$Qc.17...@twister1.libero.it...
Davide Guolo
> it a verz large table.
1.4 Mb ? - I don't think so.
> We have changed our pack-routines a long time ago to
> copy and/or append in a new empty table. We don´t have problems with
deleted
> records, but in large tables we hav had problems with memofiles in this
way.
> As we changed it to copy/append this problems went away. Possible it is
the
> same problem...
This table do not have memo fields (I never use them if possible), but
thanks for your suggestion.
I'm even more sure that "copy to" is the right way to go.
Hi,
Davide.
Alejandro
Why don't you simple blank the record (for every field) and then recycle
?
It's the only solution for a network database (I don't know if it's your
case), it's very fast and you don't need to do a new reindex.
Alejandro
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Davide Guolo
> Why don't you simple blank the record (for every field) and then recycle
> ?
it's a very old ( and quite unsupported :-) ) app. I don't want to rework on
the logic.
Thanks for the suggestion anyway.
Davide.
Mario Schulz
> > it a verz large table.
>
> 1.4 Mb ? - I don't think so.
i forget the <g> :-)
bye,
Mario
Davide Guolo
> 1) I close the dbf
> 2) I reopen it exclusively
> 3) pack
> 4) I recreate the NTX indexes (index on...)
>
> Some records previously marked as <deleted> are now live on the table (I
do
> not know if is true also the reverse)
I tried "COPY TO", "APPEND FROM" , with and without "SET DELETED ON/OFF".
Nothing worked.
After more researches I found that on the table there were duplicate
records, some of them were <deleted>, some other were not, but the latter
weren't visible because the index were corrupted.
So, PACK works well. When reindexing, the "hidden" records were live, not
the previously deleted ones.
I finally solved the problem looping the records using the damaged index and
copying them to a new table, then recreating a new, corrected index.
Just to let you know, hoping this could help someone else in future.
Thanks for all your help guys.
Davide.
gabor salai
news:3cLoc.51529$Qc.20...@twister1.libero.it...
nice to see it works, and you are satisfied!
but, i fear, you made things little bit more complicated than neccessary.
usualy works for me [working from dbu]:
have file opened in natural order [no indices]
press "hot_key" <f6>-copy_to
to dbf name: new.dbf
for clause: !deleted()
when copied, open new.dbf andf create indices you want.
[this is also the fastest way to pack dbt files]
regarding duplicated keys [they caused the problem]:
i have one small utility which easily discovers them.
if you are interested, i can send it to you.
Davide Guolo
> usualy works for me [working from dbu]:
> have file opened in natural order [no indices]
> press "hot_key" <f6>-copy_to
> to dbf name: new.dbf
> for clause: !deleted()
This couldn't work because in this way I'll have some records on the new
table that weren't needed (the records that were not visible opening the dbf
WITH the corrupted NTX)
I know this is a very strange behaviour, but I think that a some point the
index were corrupted, so some records seems to were no more live on the
table.
The customer, instead of reindex the table, did reinsert the missing records
(so in the table there were 2 records =, but 1 of them was hidden, because
it was not present on the ntx)
After some time he deleted the visible record, thinking all were ok (because
1 record, !deleted(), were still on the table, but not on the index).
On this situation, if you PACK, COPY TO, APPEND FROM and so on, the "hidden"
record will always come back live (and this should be the correct
behaviour), causing a "logical" problem (it seems that a deleted record
returns alive, but it's not true)
> regarding duplicated keys [they caused the problem]:
> i have one small utility which easily discovers them.
> if you are interested, i can send it to you.
I would be glad to look at it, if you don't mind.
You can send me it removing NOSPAM from the e-mail address.
Thank you
Davide
gabor salai
yes, strange situation, when you have to rest on corrupted index.
but, also, as you found, it was a logical starting point for repairing
database.
utility [prg & exe] is sent to your mail.
Turan Fettahoglu
> records, some of them were <deleted>, some other were not, but the latter
> weren't visible because the index were corrupted.
You still use .ntx indexes. I bet you introduced a new index and forgot to
open it after a USE command. So the index is not updated.
If you still are investing time and brains in your application, switch to
CDX indexes!
HTH
Turan
Joe Wright
Fair advice I suppose, if your supposition is correct, but that
would not be a corrupted index but a programming error.
I have several years experience, first with dBASE II and dBASE III
and now Clipper and Visual FoxPro. I have not experienced any
problem with the index system corrupting its own indexes.
I have experienced unexpected results when I update a key field in
an indexed table. Rather than learn all about what happens when you
modify keys on the fly, I have determined not to do it at all.
In practice, i use indexes to order tables for information retrieval
only, setting relations and seeking. I do not usually update an
indexed table and never on a key.
Davide Guolo
thanks Gabor, I'll give it a look.
Hi,
Davide.
Davide Guolo
> You still use .ntx indexes. I bet you introduced a new index and forgot to
> open it after a USE command. So the index is not updated.
I always use a unique function to open a table with all its associated
indexes.
This customer is used to backup/restore archives from floppy disks.
Maybe the index were corrupted by a diskette error.
> If you still are investing time and brains in your application, switch to
> CDX indexes!
This is a very old app. I don't plan to release updates anymore.
BTW, I bought Clipper 5.2 on 1992 and never upgraded to 5.3
If I'm not wrong, the CDX indexes were buggy in 5.2, full stable support
were introduced only with 5.3.
This is why I've always used NTX indexes.
Thanks for your help.
Davide.
Stephen Quinn
> This customer is used to backup/restore archives from floppy disks.
> Maybe the index were corrupted by a diskette error.
Why backup something that can be re-created??
You gain very little or nothing when you try to compress them.
--
HTH
Steve Quinn
R. Totale
<daNOSP...@tin.it> wrote:
>Steve,
>
>> Why backup something that can be re-created??
>> You gain very little or nothing when you try to compress them.
>
>You are right, there isn't any logical reason to do it.
>He does it only because either the DBF or the NTX are in the same
>subdirectory, so it is easier to backup all the files included there.
>
>I know, I could write my own backup/restore utility to zip and backup only
>the DBF files, recreating indexes when restoring them, but he is used to use
>some external Windows utility to do it (maybe only cut&paste), and I do not
>want to reinvent the wheel.
Be a true consultant and encourage the poor man to buy a second hard
drive, and show him how much nicer it will be to press a button and
make his backup to that rather than sit there feeding floppy disks
into the machine all day long...
Davide Guolo
> Be a true consultant
I am already :-)
> and encourage the poor man to buy a second hard
> drive
This is not my work.
In addition, he is using removable devices to port his data to different
locations.
Hi,
Davide.
Nick Ramsay
A USB pen drive is a cheap & very reliable way of doing this - much
faster & easier to deal with than floppies, too.