Bruno Krayenbuhl was kind enough to forward some potential code changes to
DBISAM in regard to surfacing the RecordID internal field as a TField
component, thus permitting its usage in FindKey, Locate, SetRange, etc.
However, this involves surfacing the TField somewhere in the Fields property
for the TDBISAMTable and TDBISAMQuery components, preferrably in the first
(0) position.  The possible issue with this is that it will mess with the
FieldCount property (increasing it by 1) and the ordering of existing
TFields will be bumped down by 1 position.

Does this sound like something that you would be willing to tolerate in
terms of a change in an upcoming minor release, or not ?

Thanks for your input,

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

If this is going to be introduced, I think it should be an option at the
dataset level (table/query) that defaults to the current behavior so it
doesn't break existing code. I certainly don't want fields in TFields
that don't correspond to fields I defined in the database table.

I'm not sure why the internal field should even be used for ranges and
locates in a TDBISAMTable since if a database table requires a primary
key it should be part of the field design from the start. I don't know
the reasons its being used so perhaps there is something I am
overlooking. Exposing the RecordID in a TDBIASAMTable only requires the
addition of a calculated field. Exposing the RecordID as part of a query
would only seem to require the use of a function/keyword for the
RecordID to get it into the result dataset, so I don't know why you
would need to mess with the standard behavior to interact with this
value in any visual control. It does simplify things if you want to use
it and you use Select *, but again I think if this is going to be added
it should be optional non-default behavior.

If the field actually exists as an internal TField (I'd have to poke
around a bit, but I would assume that the TField.Dataset property would
have to be nil for this to be the case since setting the Dataset
property is what adds the field to the TDataset.Fields list), why not
just expose it as a property outside the TFields list. This would allow
the value to be examined just like a TField. If you have access to the
TField and DBISAM looks, SetKey and GotoKey are a substitute for FindKey
and it will also be useable for ranges using SetRange and ApplyRange.

No matter how RecordID is internally implemented, Locate is a virtual
method, so you have complete control over detecting RecordID in that
list regardless of whether or not it is exposed in TDataset.Fields and
so there is no reason to make this change for the ability to locate a
record. It seems that the only functionality that is not easily done in
code given the current TDataset functionality is the ability to set a
range on the RecordID - so why not just add a SetRangeByRecordID
function TDBISAMDataset and leave the expected behavior of the TDataset
in tact.

Anyway, if there is a pressing need for this that I am missing, please
don't break code and introduce non-standard behavior by default. Make it
an option.

Thanks,

Sean


Tim Young [Elevate Software] wrote:
> Bruno Krayenbuhl was kind enough to forward some potential code changes to
> DBISAM in regard to surfacing the RecordID internal field as a TField
> component, thus permitting its usage in FindKey, Locate, SetRange, etc.
> However, this involves surfacing the TField somewhere in the Fields property
> for the TDBISAMTable and TDBISAMQuery components, preferrably in the first
> (0) position.  The possible issue with this is that it will mess with the
> FieldCount property (increasing it by 1) and the ordering of existing
> TFields will be bumped down by 1 position.
>
> Does this sound like something that you would be willing to tolerate in
> terms of a change in an upcoming minor release, or not ?
>
> Thanks for your input,
>

Sean McCall wrote:
> Tim,
>
> If this is going to be introduced, I think it should be an option at the
> dataset level (table/query) that defaults to the current behavior so it
> doesn't break existing code. I certainly don't want fields in TFields
> that don't correspond to fields I defined in the database table.

Sorry. Should read:

I certainly don't want fields in TDataset.Fields
that don't correspond to fields I defined in the database table.

>> Does this sound like something that you would be willing to tolerate in
>> terms of a change in an upcoming minor release, or not ?

>Anyway, if there is a pressing need for this that I am missing, please
>don't break code and introduce non-standard behavior by default. Make it
>an option.

I also like the idea of the 'option'.

Regards,
Pat

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:AE30EA88-D81C-498D-A493-E72AC76D8F86@news.elevatesoft.com...
>
> Does this sound like something that you would be willing to tolerate

No.

Robert

Thats a no for me too.

Regards
Gregory Sebastian

Tim,

> Does this sound like something that you would be willing to tolerate in
> terms of a change in an upcoming minor release, or not ?

In one of our application with incorporated data vocabulary we have a common
table structure: first 8 fields in every table are system fields and
everything done on users fields is done with referring to fields with offset
8.

I think that irrespective of position this field in set of fields that will
request a lot of programming with opened Pandorra's box of possible mistakes
and bugs.

If this is the case I am against this posibility.

Regards
Iztok Lajovic

No

It will break a lot of code of working.
This is a very deep change.

Eduardo

Tim,

> Does this sound like something that you would be willing to tolerate in
> terms of a change in an upcoming minor release, or not ?

It breaks code and really doesn't buy me anything that I can't already do
with uniqe ids. Unless it's an optional parameter, I have to say no.

--

---------------------------------------
 Terry Swiers
 Millennium Software, LLC
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

Sean,

<< No matter how RecordID is internally implemented, Locate is a virtual
method, so you have complete control over detecting RecordID in that list
regardless of whether or not it is exposed in TDataset.Fields and so there
is no reason to make this change for the ability to locate a record. It
seems that the only functionality that is not easily done in code given the
current TDataset functionality is the ability to set a range on the
RecordID - so why not just add a SetRangeByRecordID function TDBISAMDataset
and leave the expected behavior of the TDataset in tact. >>

Actually, most of the TDataSet methods are implemented using TFields at some
level or another, including FindKey, SetRange, and Locate.  They use the
TFields for storing values that correspond to the appropriate fields in the
table.  That's why the majority of these don't allow usage of the RecordID
system field currently.

Thanks for the feedback,

--
Tim Young
Elevate Software
www.elevatesoft.com