Reordering of key fields leads to key violations (Pdox 5.0) 
Author Message
 Reordering of key fields leads to key violations (Pdox 5.0)

Today's detective story for bug-hunters?
Who could please help me with this::(Sorry about the length, but precision is required.))

I have a huge Paradox 5.0 table (513,466 records). It was keyed on its first three fields, let us
call them A, B and C. All these fields were of Integer type. I needed the table to be keyed on A,
C and B instead. Changing the order of the key field should not make any difference. However, the
 simple restructuring (achieved by moving field C one step higher in the Restructure Table dialog
box and waiting for about an hour ...) resulted in a changed file with 507,546 records, plus a
table of key violations of 5,920 records.Yes, it adds up, but there ought to be no key violations.
Right?

Then I compared the violating records with both the original table and the changed table. I found,
them, of course, in both files - and no duplicates in the original. In other words, the records in
the key violation table plus the changed table do make up the original table in terms of number of
records, but not in terms of contents. So which 5,920 records didn't make it to neither the
changed table nor to the violation table? (Rhetorical question; but identifying them would require
quite some effort.:-) )

The search I did in the original file for identifying records from the violation table was not
very sophisticated. I used the search facility (Ctrl+Z, exact match) and searched in field B (or
C)for records identified by looking at the violation table. As expected this brought up the first
occurrence of the searched for value of B (or C). I then continued the search for the correct
record by repeatedly pressing Ctrl+A. As expected, this eventually brought me to the record I was
searching for. But then something odd happened. When I next pressed Ctrl+A (one or several
times),the cursor did not move off the record,even though other records below it in the table did
in fact contain the search value.No error message was given. Or in other words, once the  original
record corresponding to the violating record had been found, repeated searches just looped on this
record, as if it did itself consist of multiple identical records, ready to violate the key during
re-keying.

It may belong to the story that several attempts at rekeying aborted with a 'System Error: Cannot
read from drive C. Success was achieved only after logging out of my LAN.



Tue, 09 Mar 1999 03:00:00 GMT
 Reordering of key fields leads to key violations (Pdox 5.0)

Today's detective story for bug-hunters?
Who could please help me with this::(Sorry about the length, but precision is required.))

I have a huge Paradox 5.0 table (513,466 records). It was keyed on its first three fields, let us
call them A, B and C. All these fields were of Integer type. I needed the table to be keyed on A,
C and B instead. Changing the order of the key field should not make any difference. However, the
 simple restructuring (achieved by moving field C one step higher in the Restructure Table dialog
box and waiting for about an hour ...) resulted in a changed file with 507,546 records, plus a
table of key violations of 5,920 records.Yes, it adds up, but there ought to be no key violations.
Right?

Then I compared the violating records with both the original table and the changed table. I found,
them, of course, in both files - and no duplicates in the original. In other words, the records in
the key violation table plus the changed table do make up the original table in terms of number of
records, but not in terms of contents. So which 5,920 records didn't make it to neither the
changed table nor to the violation table? (Rhetorical question; but identifying them would require
quite some effort.:-) )

The search I did in the original file for identifying records from the violation table was not
very sophisticated. I used the search facility (Ctrl+Z, exact match) and searched in field B (or
C)for records identified by looking at the violation table. As expected this brought up the first
occurrence of the searched for value of B (or C). I then continued the search for the correct
record by repeatedly pressing Ctrl+A. As expected, this eventually brought me to the record I was
searching for. But then something odd happened. When I next pressed Ctrl+A (one or several
times),the cursor did not move off the record,even though other records below it in the table did
in fact contain the search value.No error message was given. Or in other words, once the  original
record corresponding to the violating record had been found, repeated searches just looped on this
record, as if it did itself consist of multiple identical records, ready to violate the key during
re-keying.

It may belong to the story that several attempts at rekeying aborted with a 'System Error: Cannot
read from drive C. Success was achieved only after logging out of my LAN.



Tue, 09 Mar 1999 03:00:00 GMT
 Reordering of key fields leads to key violations (Pdox 5.0)

Today's detective story for bug-hunters?
Who could please help me with this::(Sorry about the length, but precision is required.))

I have a huge Paradox 5.0 table (513,466 records). It was keyed on its first three fields, let us
call them A, B and C. All these fields were of Integer type. I needed the table to be keyed on A,
C and B instead. Changing the order of the key field should not make any difference. However, the
 simple restructuring (achieved by moving field C one step higher in the Restructure Table dialog
box and waiting for about an hour ...) resulted in a changed file with 507,546 records, plus a
table of key violations of 5,920 records.Yes, it adds up, but there ought to be no key violations.
Right?

Then I compared the violating records with both the original table and the changed table. I found,
them, of course, in both files - and no duplicates in the original. In other words, the records in
the key violation table plus the changed table do make up the original table in terms of number of
records, but not in terms of contents. So which 5,920 records didn't make it to neither the
changed table nor to the violation table? (Rhetorical question; but identifying them would require
quite some effort.:-) )

The search I did in the original file for identifying records from the violation table was not
very sophisticated. I used the search facility (Ctrl+Z, exact match) and searched in field B (or
C)for records identified by looking at the violation table. As expected this brought up the first
occurrence of the searched for value of B (or C). I then continued the search for the correct
record by repeatedly pressing Ctrl+A. As expected, this eventually brought me to the record I was
searching for. But then something odd happened. When I next pressed Ctrl+A (one or several
times),the cursor did not move off the record,even though other records below it in the table did
in fact contain the search value.No error message was given. Or in other words, once the  original
record corresponding to the violating record had been found, repeated searches just looped on this
record, as if it did itself consist of multiple identical records, ready to violate the key during
re-keying.

It may belong to the story that several attempts at rekeying aborted with a 'System Error: Cannot
read from drive C. Success was achieved only after logging out of my LAN.



Tue, 09 Mar 1999 03:00:00 GMT
 Reordering of key fields leads to key violations (Pdox 5.0)

Today's detective story for bug-hunters?
Who could please help me with this::(Sorry about the length, but precision is required.))

I have a huge Paradox 5.0 table (513,466 records). It was keyed on its first three fields, let us
call them A, B and C. All these fields were of Integer type. I needed the table to be keyed on A,
C and B instead. Changing the order of the key field should not make any difference. However, the
 simple restructuring (achieved by moving field C one step higher in the Restructure Table dialog
box and waiting for about an hour ...) resulted in a changed file with 507,546 records, plus a
table of key violations of 5,920 records.Yes, it adds up, but there ought to be no key violations.
Right?

Then I compared the violating records with both the original table and the changed table. I found,
them, of course, in both files - and no duplicates in the original. In other words, the records in
the key violation table plus the changed table do make up the original table in terms of number of
records, but not in terms of contents. So which 5,920 records didn't make it to neither the
changed table nor to the violation table? (Rhetorical question; but identifying them would require
quite some effort.:-) )

The search I did in the original file for identifying records from the violation table was not
very sophisticated. I used the search facility (Ctrl+Z, exact match) and searched in field B (or
C)for records identified by looking at the violation table. As expected this brought up the first
occurrence of the searched for value of B (or C). I then continued the search for the correct
record by repeatedly pressing Ctrl+A. As expected, this eventually brought me to the record I was
searching for. But then something odd happened. When I next pressed Ctrl+A (one or several
times),the cursor did not move off the record,even though other records below it in the table did
in fact contain the search value.No error message was given. Or in other words, once the  original
record corresponding to the violating record had been found, repeated searches just looped on this
record, as if it did itself consist of multiple identical records, ready to violate the key during
re-keying.

It may belong to the story that several attempts at rekeying aborted with a 'System Error: Cannot
read from drive C. Success was achieved only after logging out of my LAN.



Tue, 09 Mar 1999 03:00:00 GMT
 Reordering of key fields leads to key violations (Pdox 5.0)

Quote:

>Today's detective story for bug-hunters?
>Who could please help me with this::(Sorry about the length, but precision is required.))
>I have a huge Paradox 5.0 table (513,466 records). It was keyed on its first three fields, let us
>call them A, B and C. All these fields were of Integer type. I needed the table to be keyed on A,
>C and B instead. Changing the order of the key field should not make any difference. However, the
> simple restructuring (achieved by moving field C one step higher in the Restructure Table dialog
>box and waiting for about an hour ...) resulted in a changed file with 507,546 records, plus a
>table of key violations of 5,920 records.Yes, it adds up, but there ought to be no key violations.
>Right?
> But then something odd happened. When I next pressed Ctrl+A (one or several
>times),the cursor did not move off the record,even though other records below it in the table did
>in fact contain the search value.No error message was given. Or in other words, once the  original
>record corresponding to the violating record had been found, repeated searches just looped on this
>record, as if it did itself consist of multiple identical records, ready to violate the key during
>re-keying.
>It may belong to the story that several attempts at rekeying aborted with a 'System Error: Cannot
>read from drive C. Success was achieved only after logging out of my LAN.

I believe that there is some other underlying problem here, such as a damaged
table or LAN problems.  However, it's also well worth mentioning that if you
are going to restructure a large table in this way, you should begin by
removing the primary-key designation from the fields ... then reorder them ...
then put the key back.  This should save hours in itself, and it might bypass
the bug if you found one.


Tue, 09 Mar 1999 03:00:00 GMT
 
 [ 5 post ] 

 Relevant Pages 

1. Reordering of key fields leads to key violations (Pdox 5.0)

2. Paradox Key Violation - changing a keyed field

3. Case-Sensitive Sort of Key Field - Pdox 5.0/Windows95

4. INSERT INTO TABLE KEYED ONLY ON IDENTITY COLUMN RESULTS IN KEY VIOLATION (6.5)

5. Violation of PRIMARY KEY constraint Cannot insert duplicate key in object

6. Preventing Key Violation for duplicate keys

7. PDOXWIN 5.0: Lock up with key violation

8. Q: Primary key constraint violation with datetime field

9. Indentity field causing primary key violation

10. Problem in incremental field and when it happens key violation

11. Problem in incremental field and when it happens key violation


 
Powered by phpBB® Forum Software