Hi,

> > I added the RequestLive property - that does make sense, right?
>
> I am not sure. The existing procedure already implements the
> checks...
>
> if PreparingSQL and
> KeyLinksAutoDefine and
> not KeyLinksExist and
> not Assigned( FBindingCursor ) and
> not SQLIsAggregate and
> not SQLIsSelectProc and
> not ( SQLUnion.Count > 0 ) then
> begin
>
> Notice that there is no check for RequestLive. That is to say, you
> can request automatic keylinks even when you dont require a live
> dataset. (KeyLinks do have other uses - such as bookmarks).

Aha. Well, in InterBase Workbench, I use the keylinks to get an
editable resultset. As far as I know this is the only way, right?

> I probably should note that IBO already checks for an '*' and if it
> exists then IBO assumes it is an * on the keyrelation and therefore
> assumes that the key fields will exist in the query.
>
> And there is that word "assumes" again :-) It is possible for a joined
> query to be setup with explicit fields from the keyrelation and an *
> from the other relation(s). However in the instance of a joined query
> you would have to have stated which was the keyrelation to have
> autodefine try to work at all. Given this extra requirement, the
> unlikely situation in which th problem would occur, and the fact that
> autodefine on joined datasets is hazardous anyway it seems to me that
> the existing check for '*' is probably OK.

For joined datasets, I don't care much for keylinks - I dont think
joined sets are editable at all ... Never tried it though - but people
wouldn't expect them to be editable. But the current implementation
with Pos is buggy - we figured that out alright...

> I will probably wait for Jason to return before I take this any
> further. I want to know what his response will be to implementing an
> interim prepare to confirm valid keylinks fields. It could have
> considerable impact on applications that rely on KeyLinksAutoDefine
> and try to prepare a number of queries all at once (such as at
> application startup).

Indeed - it is an extra prepare you're doing. On the other hand,
most applications probably have explicit keylinks entered I guess
(not using the word assume :-).

> It may be that he will prefer the simple "full word check" to best
> guess the existance of the key fields. And then let people with more
> complex situations handle it more specifically.
>
> If that is the path he prefers you may need to implement your own
> keylinks automation according to your own preferences - bear in mind
> that the situation of user interactive queries performed via WorkBench
> and other utility tools is considerably different to that of most
> applications, and so special handling of this situation should not be
> unexpected.

It is different - I know.


Thanks for your time,

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."