Greg,

Actually I don't use field names like that, but I can see
how RecordID would be a likely candidate for a primary key
field name in a table. This could be an issue for someone
converting an application from another database system.

I do, however, strongly believe in a using single unique
record identifer since it allows for single field foreign
keys which in turn makes lookups very easy to manage. I
actually take it a step further and use long integer "serial
numbers" for my records that encode both a table-unique
sequence number and a table-specific identifer. (Example:
Table ID = 27, Record Sequence = 37 ==> Serial Number =
370027). This way, I can have have tables with database-wide
reference fields and just by examining the serial number I
can determine both the table and the record for drilling
down. In addition, I can detect table corruption if a record
serial number does not conform to the encoding rules for its
table.

Take it easy,

Sean

GregF wrote:

> "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
>
>

Oops... make that a <large integer> serial number

Sean

Sean McCall wrote:
> Greg,
>
> Actually I don't use field names like that, but I can see how RecordID
> would be a likely candidate for a primary key field name in a table.
> This could be an issue for someone converting an application from
> another database system.
>
> I do, however, strongly believe in a using single unique record
> identifer since it allows for single field foreign keys which in turn
> makes lookups very easy to manage. I actually take it a step further and
> use long integer "serial numbers" for my records that encode both a
> table-unique sequence number and a table-specific identifer. (Example:
> Table ID = 27, Record Sequence = 37 ==> Serial Number = 370027). This
> way, I can have have tables with database-wide reference fields and just
> by examining the serial number I can determine both the table and the
> record for drilling down. In addition, I can detect table corruption if
> a record serial number does not conform to the encoding rules for its
> table.
>
> Take it easy,
>
> Sean
>
> GregF wrote:
>
>> "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
>>

Stefano,

<< If you make them usable in the next release (Dbisam 4) I use it and the
problem is solved!; >>

I wish it were that easy for everyone.  It's easy for us to make that
change, but it would break every application that relies on the field
positions being like they are now, especially for altering tables, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Sean,

<< 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 >>

Actually, the hash is gone and the current name for version 5 is simply
RowID.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,
in porting, we are working on rename our RecordID to ID; please don't change
RecordID to ID, or we still to rechange names!


Stefano Monterisi

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel
messaggio news:477C10BA-44C5-4765-A30B-EF482356A600@news.elevatesoft.com...
> Stefano,
>
> << If you make them usable in the next release (Dbisam 4) I use it and the
> problem is solved!; >>
>
> I wish it were that easy for everyone.  It's easy for us to make that
> change, but it would break every application that relies on the field
> positions being like they are now, especially for altering tables, etc.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Stefano,

<<  in porting, we are working on rename our RecordID to ID; please don't
change RecordID to ID, or we still to rechange names! >>

You won't find the word "Record" anywhere in ElevateDB.  It is now the
proper SQL term - "Row".

--
Tim Young
Elevate Software
www.elevatesoft.com