Hi Tim,
It's possible assign another name to RecordID field ?
I have several project that already have their RecordID field (our
fieldname) that we use for search, order, master/details operations, etc.
We have to change all those fields for solve the problem, because your
RecordID is not visible for all operations;  It is better (for us) if is
possible to change in the Dbisam source the name of RecordID automatic
field, if you have saved it into a variable.

Thanks in advance,

Stefano Monterisi

Stefano,

<< It's possible assign another name to RecordID field ? >>

You can do so if you have the source code.  It's in the dbisamcn.pas unit:

  RECORDID_FIELD_NAME = 'RecordID';

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi, Tim,

This solve a lot of problems on porting from Dbisam 3 to Dbisam 4;
Please publish this in release 5 (even RecordHash fieldname), so we can
adjust more comfortable particular situations (mine is a particular
situation).

Thanks!

Good Job.

Stefano Monterisi

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel
messaggio news:2069922E-D370-442B-B458-1456F253EBFD@news.elevatesoft.com...
> Stefano,
>
> << It's possible assign another name to RecordID field ? >>
>
> You can do so if you have the source code.  It's in the dbisamcn.pas unit:
>
>   RECORDID_FIELD_NAME = 'RecordID';
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Stefano,

<< This solve a lot of problems on porting from Dbisam 3 to Dbisam 4; Please
publish this in release 5 (even RecordHash fieldname), so we can adjust more
comfortable particular situations (mine is a particular situation). >>

It's a constant in ElevateDB currently, but it can be moved to the resource
file also.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Maybe it would make sense to use field names unlikely to
cause a conflict in version 5 like and just leave them as
constants:

EDB_Sys_Record_ID
EDB_Sys_Record_Hash

Sean

Tim Young [Elevate Software] wrote:

> Stefano,
>
> << This solve a lot of problems on porting from Dbisam 3 to Dbisam 4; Please
> publish this in release 5 (even RecordHash fieldname), so we can adjust more
> comfortable particular situations (mine is a particular situation). >>
>
> It's a constant in ElevateDB currently, but it can be moved to the resource
> file also.
>

Sean McCall wrote:
> Tim,
>
> Maybe it would make sense to use field names unlikely to
> cause a conflict in version 5 like and just leave them as
> constants:

Many developers are using the new field names. I don't think that it's a
good idea to break their code just to satisfy one user - sorry. I don't even
think that's it a good idea to make the field names changeable as
properties. Some metastructures should be hard to change.

Ralf

"Ralf Mimoun" <nospam@rad-on.de> wrote in message news:4DC87D75-78FD-4AD3-865C-462EB3342CF9@news.elevatesoft.com...
> Sean McCall wrote:
>> Tim,
>>
>> Maybe it would make sense to use field names unlikely to
>> cause a conflict in version 5 like and just leave them as
>> constants:
>
> Many developers are using the new field names. I don't think that it's a good idea to break their code just to satisfy one user -
> sorry. I don't even think that's it a good idea to make the field names changeable as properties. Some metastructures should be
> hard to change.
>
> Ralf
>
>

I think that Sean is mostly right
Tim needs to use less "generic" field names
but at the same time Sean also needs to use
less generic field names.

I stay far far away from using generic terms
and always use specific names

However I am ambivalent over the use of any field called RecordID
as an old data analyst I would maintain that every record
should be unique and if the fields within the table
can't make it so then you need to re-assess the table structure

gregF

GregF wrote:
....
> Tim needs to use less "generic" field names
> but at the same time Sean also needs to use
> less generic field names.

Good point.

....
> However I am ambivalent over the use of any field called RecordID
> as an old data analyst I would maintain that every record
> should be unique and if the fields within the table
> can't make it so then you need to re-assess the table structure

I understand that the db engine need such a field. And I understand Tim that
he publishes it (if you have smething, why don't you show it?). But I would
never ever use the field or the hash field in my code. IOW: You are right.

Ralf

Hi, Tim,
the real problem is this:
If I can see and use those 2 fields like other fields (master-detail
operation, filter, indexes, etc.) giving them better visibility, I can use
them without problems; Mine RecordID is an AutoInc like the internal Dbisam
one; So if you make it completely usable as other fields, I use your
RecordID without effort; But this is possible only in release 5, we have
already talked about in a mail in the past;
If you make them usable in the next release (Dbisam 4) I use it and the
problem is solved!;

Good Job,
Stefano Monterisi

"Ralf Mimoun" <nospam@rad-on.de> wrote in message
news:4DC87D75-78FD-4AD3-865C-462EB3342CF9@news.elevatesoft.com...
> good idea to break their code just to satisfy one user - sorry. I don't
even
> think that's it a good idea to make the field names changeable as
> properties. Some metastructures should be hard to change.
>


As long as it is optional, it is no big deal IMO. Like being able to select
the extensions. Most folks will leave them at DAT and IDX, but some might
need to change them.

Robert