Key violation bug

[viana]

Hello,

Since i updgraded to RAD Studio 2007, i'm having a lot of 'Key violation' exceptions, but i'm not doing any insert or edit or even deletes. The error occurs simply by selecting records using commandtext in TClientdataset.

Exact exception text is :

Project XXXXXXXX.EXE raised exception class EDBClient with message 'Key violation'.

The error occurs only if packetrecords is <> -1. If packetrecords is equal -1, the error does not occurs. It seems to be a issue when fetching records.

I'm quite sure this is a D2007 bug, because i run the same project compiled in D6 and everything works fine.

I could open a QC issue, but problem is that to simulate the problem, i need to provide a .GDB (i'm using Firebird) with some example records and a example query. Can i send this files in QC ? Please give me directions and i'll be glad to do it in order to help finding the problem.

I'm having to workaround a lot of queries and changing packetrecords to -1 in order to program works... I usually use packetrecords = 25, and i think it's not a good idea change it to -1, specially for big result sets.

Any ideas would be very appreciated.

Thanks in advance.

[viana]

Hello,

Actually, i found that there is already a QC entry for this problem :

http://qc.borland.com/wc/qcmain.aspx?d=4498

The problem related in this QC is exactly the same problem i have, and it seems to happens since D7.

Is there a chance that it will be fixed ?

Thanks

Post by viana
Hello,
Since i updgraded to RAD Studio 2007, i'm having a lot of 'Key violation' exceptions, but i'm not doing any insert or edit or even deletes. The error occurs simply by selecting records using commandtext in TClientdataset.
Project XXXXXXXX.EXE raised exception class EDBClient with message 'Key violation'.
The error occurs only if packetrecords is <> -1. If packetrecords is equal -1, the error does not occurs. It seems to be a issue when fetching records.
I'm quite sure this is a D2007 bug, because i run the same project compiled in D6 and everything works fine.
I could open a QC issue, but problem is that to simulate the problem, i need to provide a .GDB (i'm using Firebird) with some example records and a example query. Can i send this files in QC ? Please give me directions and i'll be glad to do it in order to help finding the problem.
I'm having to workaround a lot of queries and changing packetrecords to -1 in order to program works... I usually use packetrecords = 25, and i think it's not a good idea change it to -1, specially for big result sets.
Any ideas would be very appreciated.
Thanks in advance.

[Dave Nottage [TeamB]]

Post by viana
http://qc.borland.com/wc/qcmain.aspx?d=4498
The problem related in this QC is exactly the same problem i have,
and it seems to happens since D7.
Is there a chance that it will be fixed ?

Apparently not, since it has been closed with a resolution of "Won't
do".

The reason:

"The keyviolation error is correct. The bug is that there is no
checking for duplicate key values on the initial load. While we could
fix that problem, there is a strong probability that would break
existing applications and there would be little benefit to making that
change. It also likely to have some impact on the initial load time."

AFAICT you might need to change your query, or leave PacketRecords at
-1, if you're not returing a large result set.

[viana]

Post by Dave Nottage [TeamB]

Post by viana
http://qc.borland.com/wc/qcmain.aspx?d=4498
The problem related in this QC is exactly the same problem i have,
and it seems to happens since D7.
Is there a chance that it will be fixed ?

Apparently not, since it has been closed with a resolution of "Won't
do".
"The keyviolation error is correct. The bug is that there is no
checking for duplicate key values on the initial load. While we could
fix that problem, there is a strong probability that would break
existing applications and there would be little benefit to making that
change. It also likely to have some impact on the initial load time."
AFAICT you might need to change your query, or leave PacketRecords at
-1, if you're not returing a large result set.

Dave,

Thank you for your reply.

But imho, if there is a bug, the bug should be fixed and there is no sense to not fix it because there are already applications running and workarounding the bug.

In my case, i needed to change all my packetrecords to -1, just like in the paradoxx and desktop applications. If my result set is large, all records will be fetched. I don't see the point ; you have the property packetrecords but you can't use it, because there is a bug ; codegear knows the bug, but the bug won't be fixed.

And the stranger thing is in D6 and previous versions this worked fine.

I think that codegear should fix it and release it in a optional update, or something like. What i really don't agree is not fix a important problem like this.

Thanks.