Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Key violation with GetNextPacket - only Delphi 7

149 views
Skip to first unread message

Ole Juhl

unread,
May 6, 2003, 3:25:52 AM5/6/03
to
Hi

I try to move a midas application from Delphi 5 to Delphi 7. On some of my
clientdataset I have set the property PackedRecord > 0. When i use the
GetNextPacket method on these clientdataset I get an error "Key violation"
in Delphi 7 but not in Delphi 5. Why this difference ?. Anybody knows how I
can repair ?.

I use:
Delphi 7
Connection to SQL Server 2000 using ADO connection

Ole


Mikko Laiho

unread,
May 9, 2003, 10:47:47 AM5/9/03
to
Ole Juhl wrote:

> I try to move a midas application from Delphi 5 to Delphi 7. On some
> of my clientdataset I have set the property PackedRecord > 0. When i
> use the GetNextPacket method on these clientdataset I get an error
> "Key violation" in Delphi 7 but not in Delphi 5.

Today I hit to the same problem. I'm also moving my Midas/Datasnap
application from D5 to D7. I have PacketRecords=100 on many
ClientDataSets and some, not all, give 'Key violation' error when
scrolling the dataset past 100th record. Clearly the fetch of next
datapacket from the server fails but what is the key in this case
and how to violate it as the database (Interbase) is quite happy
with it's keys.

Could somebody kindly shed some light?

--Mikko

Dave Rowntree

unread,
May 9, 2003, 6:08:34 PM5/9/03
to
Does your SQL Select statement have parameters?

--
-Dave Rowntree

Ole Juhl <o...@lr.dk> wrote in message
news:3eb7...@newsgroups.borland.com...

Mikko Laiho

unread,
May 12, 2003, 9:11:14 AM5/12/03
to
Dave Rowntree wrote:

> Does your SQL Select statement have parameters?
>

Mine does not have any parameters. But I found a difference
between those queries with have no problems and those
which raise 'Key violation' at the fetch of next datapacket:

If the SQL select feeding the DatasetProvider joins two (or more)
tables in such a way that the "master table" rows are repeated
many times then the 'Key violation' comes up. If the primary key
of the "master" table does not have repeating values then no
problems. It seems that the presence of primary key columns
in the result set does not affect in any way.

--Mikko

Dave Rowntree

unread,
May 12, 2003, 8:46:44 PM5/12/03
to
Mikko Laiho wrote

> Mine does not have any parameters. But I found a difference
> between those queries with have no problems and those
> which raise 'Key violation' at the fetch of next datapacket:

Have a look at QC#3515. I have provided a fix/workaround.

> If the SQL select feeding the DatasetProvider joins two (or more)
> tables in such a way that the "master table" rows are repeated
> many times then the 'Key violation' comes up.

I would expect it to. The whole point of a PK is that each row/record must
be unique.

> If the primary key
> of the "master" table does not have repeating values then no
> problems.

Good. It sounds to be working as designed then.
--
-Dave Rowntree

Mikko Laiho

unread,
May 13, 2003, 7:14:47 AM5/13/03
to
Dave Rowntree wrote:
>
> Have a look at QC#3515. I have provided a fix/workaround.

Thanks Dave, I will take a look at it.

>
> > If the SQL select feeding the DatasetProvider joins two (or more)
> > tables in such a way that the "master table" rows are repeated
> > many times then the 'Key violation' comes up.
>
> I would expect it to. The whole point of a PK is that each row/record
> must be unique.
>

Of course, if the result set needs to be updated. But for read-only
reporting purposes it should be possible to create joins where
the master table rows are repeating. And I can't understand
why the 'Key violation' complaint does come up if all records
are fetched in a single lot.

Anyway my quick solution was to set PacketRecords to -1 and
accept the possible network delay when result set is large.

Regards,
--MIkko

Ole Juhl

unread,
May 14, 2003, 4:32:40 AM5/14/03
to
Thanks. Where can I find QC#3515 ?. I tried to search at bdn.com,
codecentral for id 3515. But that ID is not found.

Ole Juhl


"Dave Rowntree" <daver@away_spam.brookswood,co.uk> wrote in message
news:3ec0...@newsgroups.borland.com...

Dave Rowntree

unread,
May 14, 2003, 6:23:47 AM5/14/03
to
Ole Juhl wrote

> Thanks. Where can I find QC#3515 ?. I tried to search at bdn.com,
> codecentral for id 3515. But that ID is not found.

http://qc.borland.com/
--
-Dave Rowntree

Dave Rowntree

unread,
May 14, 2003, 6:33:09 AM5/14/03
to
Mikko Laiho wrote
<snip>

> Of course, if the result set needs to be updated. But for read-only
> reporting purposes it should be possible to create joins where
> the master table rows are repeating. And I can't understand
> why the 'Key violation' complaint does come up if all records
> are fetched in a single lot.

For a read-only CDS, when the SQL select does not use parameters, try
removing the pfInKey flag from the DSP.DataSet PK field(s) ProviderFlags.
You should then be able to use CDS.PacketRecords > 0. I haven't tried this
but the theory seems reasonable <g>.
--
-Dave Rowntree


Ole Juhl

unread,
May 14, 2003, 7:51:28 AM5/14/03
to
Thanks a lot. QC#3515 fixed my problem.

Ole Juhl

"Dave Rowntree" <daver@away_spam.brookswood,co.uk> wrote in message

news:3ec2...@newsgroups.borland.com...

Dave Rowntree

unread,
May 14, 2003, 5:30:18 PM5/14/03
to
Ole Juhl wrote

> Thanks a lot. QC#3515 fixed my problem.

You are welcome. Glad it fixed the problem for you.
--
-Dave Rowntree


Mikko Laiho

unread,
May 15, 2003, 4:01:50 AM5/15/03
to
Dave Rowntree wrote:

>
> For a read-only CDS, when the SQL select does not use parameters, try
> removing the pfInKey flag from the DSP.DataSet PK field(s)
> ProviderFlags. You should then be able to use CDS.PacketRecords > 0.
> I haven't tried this but the theory seems reasonable <g>.
> --

Resetting ProviderFlags option pfInKey to False eliminated the error,
thanks.

What I'm still wondering : If CDS considers key values important why
doesn't
it complain when I fetch the whole dataset in a single packet
(PacketRecords=-1)?

Thanks Dave!

--Mikko

Dave Rowntree

unread,
May 15, 2003, 11:50:08 AM5/15/03
to
Mikko Laiho wrote:
> What I'm still wondering : If CDS considers key values important why
> doesn't
> it complain when I fetch the whole dataset in a single packet
> (PacketRecords=-1)?

When you set pfInKey against the DSP.DataSet TField(s) MIDAS creates a
unique index (called 'PRIMARY_KEY') on the pfInKey field(s), which it passes
to the CDS.

I did a test against an MSSQL DB using ADO.
It appears that validation against indices is only carried out when changes
occur to an already open CDS. I'm not really convinced that this makes
sense.

--
-Dave Rowntree


Mikko Laiho

unread,
May 16, 2003, 7:45:22 AM5/16/03
to
Dave Rowntree wrote:

>
> When you set pfInKey against the DSP.DataSet TField(s) MIDAS creates a
> unique index (called 'PRIMARY_KEY') on the pfInKey field(s), which it
> passes to the CDS.
>
> I did a test against an MSSQL DB using ADO.
> It appears that validation against indices is only carried out when
> changes occur to an already open CDS. I'm not really convinced that
> this makes sense.
>

So the appending of the next data packet to the data already in CDS is
regarded a change comparable to an insert row operation. Smells like
a bug to me...

Thanks Dave,
--Mikko

Dave Rowntree

unread,
May 16, 2003, 12:19:37 PM5/16/03
to
Mikko Laiho wrote:
> So the appending of the next data packet to the data already in CDS is
> regarded a change comparable to an insert row operation. Smells like
> a bug to me...

As I said, it doesn't seem very logical to me either. Why don't you post the
problem to QC with a test case app in Attachments that demonstrates the
problem.
--

0 new messages