Reading the replies to Tim's post about RecordID prompts a question - how many out there reference fields by their index rather than their name or as persistent fields?

ie who uses Fields[x].As.... rather than FieldByName(fld).As.. or tablefield.As...

Roy Lambert

Roy,

<< Reading the replies to Tim's post about RecordID prompts a question - how
many out there reference fields by their index rather than their name or as
persistent fields? >>

I was curious about that also.

--
Tim Young
Elevate Software
www.elevatesoft.com

I do, in code which is a tight loop around what could be thousands of
rows. At the start I find the index of each field, then use that inside
the loop. I hope it is faster! Certainly should be given there can be 30
fields.

I also used them for manipulating the order.

/Matthew Jones/

Roy

I do it in just a few cases where I want to process, in a loop,
a series of fields which have no commonality in their names.  
For those tables I just make sure I add any new fields to the end
of the list!  But maybe there is a better (safer) way?

Malcolm

Roy,

> Reading the replies to Tim's post about RecordID prompts a question - how
> many out there reference fields by their index rather than their name or
> as persistent fields?
>
> ie who uses Fields[x].As.... rather than FieldByName(fld).As.. or
> tablefield.As...

I do in one of our most important application named Panorama. Due to fact
that this application in data dictionary driven the fields are addressed by
their position indicated by a position fileld in data dictionary. User has
the tool to build the table via data dictionary and field names in data
dictionary are merely descriptions of field and phisical name of a field is
composed by a common literal named 'polje' and some number given by data
dictionary. There are many reasons for such design with more pros for it as
contras.

Proposed RecordId as first field in field set will cause to make tremendous
changes to this application with huge possibilities to make mistakes.

Iztok Lajovic

Tim Young [Elevate Software] wrote:
> Roy,
>
> << Reading the replies to Tim's post about RecordID prompts a question - how
> many out there reference fields by their index rather than their name or as
> persistent fields? >>
>
> I was curious about that also.
>
I prefer to create my dataset fields at run-time and maintain direct
references.  When I do need to find a TField or do something like
arrange fields or change visibility, I use both Fields[AIndex] and
FindField(AName). I don't like FieldByName because it can raise an
exception. I prefer to test myself:

AField := ADataset.FindField(SomeName);
if AField = nil then begin
  DoSomething;
end; {if field not found}

Sean

I uses indexes for speed reason on many places, where I know exactly what
the fields of the Query are. Thiis means at local places at runtime like
this case:

{ only a sample }
procedure GetDescription(const APartNo:String): String;
begin
 with TDBISAMQuery.Create(nil) do
 try
     RequestLive := True;
     SQL.Text :=
       'SELECT Description ' +
       'FROM Media ' +
       'WHERE PartNo = :PARTNO';
     Open;
     Result := Fields[0].AsString;
     Close;
 finally
   Free;
 end;
end;

Such code exists very much im may applications.

I do never use the field index fo any query, wich is not at the same palce
in the code as the code itself. No designtime Query I will access this way,
but as you see for local temporary queries this is very handy and is faster,
than FieldByName.

I think the addition of a special RowID field will be the much better
solution, so anyone who wnats that field in the Select, can write it in the
Select. Sample:

SELECT RowID, Field2 FROM Table1

DBISAM should now handle that RowID field internally as a normal field. This
way everyone will be happy as this will not break any code at all.

Regards
Rolf


"Roy Lambert" <roy.lambert@skynet.co.uk> schrieb im Newsbeitrag
news:5A8CC5CB-83EF-4842-9BD1-4AD2BBFA76CB@news.elevatesoft.com...
> Reading the replies to Tim's post about RecordID prompts a question - how
> many out there reference fields by their index rather than their name or
> as persistent fields?
>
> ie who uses Fields[x].As.... rather than FieldByName(fld).As.. or
> tablefield.As...
>
> Roy Lambert

Roy

I do,

X := Query.Fields[0].AsInteger;

similar to Rolf. Breaking this is simply a no go for me

Arnd

Roy Lambert wrote:
> Reading the replies to Tim's post about RecordID prompts a question - how many out there reference fields by their index rather than their name or as persistent fields?
>
> ie who uses Fields[x].As.... rather than FieldByName(fld).As.. or tablefield.As...
>
> Roy Lambert

While I can see the point of some of the other posts, I guess I'm one of the
ones who don't see the value of not referencing by name.

With proper naming, you could do PART1, PART2, PART3, then refer by
PART+STR(IDX) essentially.

I wouldn't be affected either way.

Lance



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:043DC283-78D2-4F94-8C3A-E9A98D8B342E@news.elevatesoft.com...
> Roy,
>
> << Reading the replies to Tim's post about RecordID prompts a question -
> how many out there reference fields by their index rather than their name
> or as persistent fields? >>
>
> I was curious about that also.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Referencing by index is direct. Referencing by name involves looping
through fields and doing a string compare with field names. Not a big
deal on a small scale these days, but if done enough with a large number
of records I'd venture to guess it adds up. I remember coding in
assembly and being very attuned to saving a few CPU cycles by examining
which instructions were used, so maybe I'm just a bit sensitive to these
kind of things. Processors are so fast these days it just might not make
a difference.

Sean


Lance Rasmussen [Team Elevate] wrote:
> While I can see the point of some of the other posts, I guess I'm one of
> the ones who don't see the value of not referencing by name.
>
> With proper naming, you could do PART1, PART2, PART3, then refer by
> PART+STR(IDX) essentially.
>
> I wouldn't be affected either way.
>
> Lance
>
>
>
> "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
> message news:043DC283-78D2-4F94-8C3A-E9A98D8B342E@news.elevatesoft.com...
>> Roy,
>>
>> << Reading the replies to Tim's post about RecordID prompts a question
>> - how many out there reference fields by their index rather than their
>> name or as persistent fields? >>
>>
>> I was curious about that also.
>>
>> --
>> Tim Young
>> Elevate Software
>> www.elevatesoft.com
>>
>