>"Insufficient key column information for updating or refreshing"

>SELECT RS.*, C.Course_Name
>FROM Registration_Selection RS, Course C
>WHERE School_Id = :School_Id
>AND       Session_Id = :Session_Id
>AND       Child_Id = :Child_Id
>AND       C.Course_Id = RS.Course_Id
>ORDER BY C.Course_Name

>I have set the following properties:

>CursorLocation := clUseClient;
>CursorType := KeySet;
>LockType := ltBatchOptimistic;

>When I try to delete a record from the resulting dataset (TADOQuery.Delete,
>TADOQuery.UpdateBatch(arAll)), I get the following error message:

>"Insufficient key column information for updating or refreshing"

>Can anyone help me with this????

>TKJ

> Todd K. Jones <jon...@omnisystems.com> wrote in message
> news:7tga8a$6tu3@forums.borland.com...

> >   QRegSelection.Recordset.Properties.Item['Unique Table'].Value :=
> > 'Registration_Selection';

> Thanks for sharing that solution.  I'll definitely file that  one away in
> case this question comes up again.  If you don't mind, can you tell me where
> you found this information?

>"Mark Edington (Borland)" wrote:

>> Todd K. Jones <jon...@omnisystems.com> wrote in message
>> news:7tga8a$6tu3@forums.borland.com...

>> >   QRegSelection.Recordset.Properties.Item['Unique Table'].Value :=
>> > 'Registration_Selection';

>> Thanks for sharing that solution.  I'll definitely file that  one away in
>> case this question comes up again.  If you don't mind, can you tell me
where
>> you found this information?

>Mark, please, don't say to us that this "feature" was not tested ...

>maybe the solution by Todd work well in a variety os scenarios, but the
>fact is that is not well tested ...
>what if I joined three tables and want to delete in two ?
>(and there must be a better/easy solution, Todd's method is a dirty
>workaround)

>is that nobody in borland thinked about this scenario ?

>I hate this situation, instead of putting the decisions and the fine
>granularity in the programmer, borland decides to put this
>"intelligence" in a component, now this dumb component take decisions
>for me, oh well ...

>look, I know there are a lot of dumb programmers out there, lot of
>people trying to use a query like a old dbase table, etc, but this
>people usually choose VB.
>Please, don't make us look stupids, *me* is who I want for take
>control of the software, *me* is who I want for desicions in what
>to do ...

>like it or not, TUpdateSql was a control to permit us the behavior
>of the program, you say it was cruft, now we have this problems, and
>you say: 'Oh, I will annotate this workaround just in case'

>I have another idea: FIX the problem.

>--
>  |    Sergio A. Kessler  http://sak.org.ar
>-O_O-  Keep working at it... you will either succeed, or become an expert.

> http://msdn.microsoft.com/library/default.htm

> I then selected the following:

> Sak <s...@perio.unlp.edu.ar> wrote in message
> news:37FBB05F.4F3A3A75@perio.unlp.edu.ar...

> > Mark, please, don't say to us that this "feature" was not tested ...

> Our testing focused on the VCL components encapsulation of the ADO objects.
> By default this also test ADO itself and in fact turned up a number of
> different issues/bugs.  However, when it comes to actually updating data
> this is always done by ADO and not the ADOExpress components.

> The issue Todd brought up would be the same regardless of which development
> tool was being used.  It is an issue with ADO, not Delphi.

> Sak,

> I find you post pretty pre-mature and offensive. The behaviour has nothing
> to do w/ the ADOExpress components. I have the same problem a year ago while
> developing MTS components w/ ADO using VB. I hate to see people quickly
> complaining before actually doing some analysis first.

>borland should have been aware of this *BIG* hole and *BIG* lack
>of control.

>look, M$ has years of history doing pretty bad software, if borland
>want to depend more and more about this software, that's ok, is their
>rigth.

>but if borland want to come up with a good and robust development
>tools they have to do their own thing rigth or /at least/ face the
>problems and provide nice workarounds, instead of blaming M$.

>and there is no much analysis to do, M$ is a factory of bad designed
>software, and now Borland want to depend more and more on this soft,
>you do the math.

>PS: sorry if you feel alluded about the dumb programmers for
>using VB.

>--
>  |    Sergio A. Kessler  http://sak.org.ar
>-O_O-  Keep working at it... you will either succeed, or become an expert.

> If Borland has to follow your recommendation, they might just be better off
> to retreat from Windows, anyway Windows is from M$.

> > I found it at the following link:

> > http://msdn.microsoft.com/library/default.htm

> > I then selected the following:

> Thank you very much.  Also, just FYI if you want to post a URL to the
exact
> page you can find out what it is by turning off the TOC.  I'm not
> complaining mind you, it's just that one click is easier than 10 :).

> Also, it's worth noting that is a new topic in the 2.5 SDK.  I'm glad they
> finally started doc'ing the dynamic properties.  There's alot of stuff in
> there, but most of it is tough to use without docs (although most are
> covered quickly in the OLE DB reference).

> Thanks again,

> Mark