Up til now when I've used FieldByName I've just typed the fieldname in but I'm thinking of creating a dedicated unit to hold all the fieldnames as constants. Is it worth it, and if so why?

Roy Lambert

Roy Lambert wrote:

<<<Up til now when I've used FieldByName I've just typed the fieldname in but I'm thinking of creating a dedicated unit to hold all the fieldnames as constants. Is it worth it, and if so why?>>>


YES.  It is definitely worth it in my opinion.  If you faithfully only use your constants for the field names you will virtually eliminate query errors due to misspelled field names.  If you don't have the correct field name (constant), your program simply won't compile.  I do the same thing for index and table names.

I have also found it helpful when I can't quite remember the name of a field.  If it's wrong, the IDE underlines it, After one or two tries I usually get it right.. much faster than having to look it up in my code.

I started doing this two years ago and it has worked out so well for me that now I use constants and variables for just about all of the values in my code.

Dale

Nice idea.  It would make it very easy to change field names in code.

Steve

Just to present a different viewpoint and to hear what other people do
and why, I would like to ask why there would be a heavy use of
FieldByName?  I create as many persistent fields from the component at
design time as possible and use them wherever I need to access table
values.  My use of FieldByName is very rare and in fact I only use them
when the field is not known ahead of time.

Why is FieldByName so popular?  What is its advantage over persistent
fields?  The mistyping of a field name and not discovering it until
runtime (if you happen to run that exact piece of code) seems like a
severe disadvantage--which is why I've shied away from it.

--
David Cornelius
Cornelius Concepts

On 7/22/2010 8:35 AM, Roy Lambert wrote:
> Up til now when I've used FieldByName I've just typed the fieldname in but I'm thinking of creating a dedicated unit to hold all the fieldnames as constants. Is it worth it, and if so why?
>
> Roy Lambert
>
>

David


The reason I'm asking the question is that with DBISAM I used tables almost exclusively.

I find that with ElevateDB, either due to my improving knowledge, better engine architecture, changing application needs or some other reason I'm using more queries. Often these are generated on the fly, or have bits in them that will be changed at run time both of which prevent or at least make it difficult to define persistent fields in the IDE.

I still have loads of tables (and some queries) with persistent fields since I (rightly or wrongly) consider them more efficient (no need to look through the field list each time) and more helpful (ctrl-space and a few characters gets the field) .

I realised yesterday I now had loads of these and wasn't happy with my old approach of just typing the name in. My reaction has been to set up a unit with ALL of the fields in the database in it, and I'm trawling the app to get the other on-the-fly fields and adding in SQL parameters.

With that preamble I'll move on to specifics

<<why there would be a heavy use of FieldByName?>>

Two reasons. One as above for queries where its not as easy to get persistent fields, but the other one is where tables are created in code, either in-memory tables or in units that will be used in threads. Where I can I drop table components onto a datamodule or form, but that's not always possible.

<<I create as many persistent fields from the component at design time as possible and use them wherever I need to access table values.>>

Me to.

<<Why is FieldByName so popular?>>

It isn't with me, its a usage I find I'm having to adopt rather than wanting to use.

<<What is its advantage over persistent fields?>>

The only one I can think of is that its a bit easier to get going, and if you change a field definition (eg varchar(20) -> varchar(30)) there are no changes to make. Also if you add a field you can access it. Width persistent fields if you declare some then the others effectively disapear (been caught with that one a few times).

On the downside using FieldByName is less efficient since a lookup has to be done to obtain the fields position in the array. You already mentioned another big downside(mistyping). The final one, which I'm not sure about, is how efficient it is having your code littered with literals. I have no idea what the compiler does either with wadges of 'ThisFieldName' or a defined constant ThisFieldName = 'ThisFieldName' which is then splattered everywhere.


Roy Lambert

David


Here's a little example where I find FieldByName invaluable

  if Message.LParam = 11 then emst := 'Current' else emst := 'Archive';
  nlhMessageDlg('The Email search ' + lu.EMSearches_Name.AsString + ' is finished with '
   + lu.EMSearches.FieldByName('_' + emst + 'Hits').AsString + ' hits in the ' + emst + ' emails'
   , mtInformation, [mbOK], 0);

I could solve it differently but I find this more comprehensible.

Roy Lambert

<<<
Just to present a different viewpoint and to hear what other people do
and why, I would like to ask why there would be a heavy use of
FieldByName?  I create as many persistent fields from the component at
design time as possible and use them wherever I need to access table
values.  My use of FieldByName is very rare and in fact I only use them
when the field is not known ahead of time.
>>>


Actually, I don't have any good reason's for not using persistent fields.  I just never developed that habit I guess. Maybe I should revisit them.

Dale

Dale,

<< Actually, I don't have any good reason's for not using persistent fields.
I just never developed that habit I guess. Maybe I should revisit them. >>

Persistent fields already solve the problems that Roy wants to solve with
constants, especially compile-type checking.   The only issue is that they
aren't available to you if you're executing dynamic SQL statements.

--
Tim Young
Elevate Software
www.elevatesoft.com

I didn't intend all the questions to be independent, just different
aspects of the same issue.  But thanks for being so thorough in your
response.

Your reasons for using or not using persistent fields resonate closely
with mine.  I much prefer the type-checking at design time and feel it's
somewhat more efficient if there's no need to lookup the field at run
time with the name.  If I were to use many instances of FieldByName, I'd
definitely have a "constants" unit.  There's no difference at run-time
between a literal string or a constant that points to a literal string.

Thanks for your feedback.

--
David Cornelius
Cornelius Concepts

On 7/23/2010 12:17 AM, Roy Lambert wrote:
> David
>
>
> The reason I'm asking the question is that with DBISAM I used tables almost exclusively.
>
> I find that with ElevateDB, either due to my improving knowledge, better engine architecture, changing application needs or some other reason I'm using more queries. Often these are generated on the fly, or have bits in them that will be changed at run time both of which prevent or at least make it difficult to define persistent fields in the IDE.
>
> I still have loads of tables (and some queries) with persistent fields since I (rightly or wrongly) consider them more efficient (no need to look through the field list each time) and more helpful (ctrl-space and a few characters gets the field) .
>
> I realised yesterday I now had loads of these and wasn't happy with my old approach of just typing the name in. My reaction has been to set up a unit with ALL of the fields in the database in it, and I'm trawling the app to get the other on-the-fly fields and adding in SQL parameters.
>
> With that preamble I'll move on to specifics
>
> <<why there would be a heavy use of FieldByName?>>
>
> Two reasons. One as above for queries where its not as easy to get persistent fields, but the other one is where tables are created in code, either in-memory tables or in units that will be used in threads. Where I can I drop table components onto a datamodule or form, but that's not always possible.
>
> <<I create as many persistent fields from the component at design time as possible and use them wherever I need to access table values.>>
>
> Me to.
>
> <<Why is FieldByName so popular?>>
>
> It isn't with me, its a usage I find I'm having to adopt rather than wanting to use.
>
> <<What is its advantage over persistent fields?>>
>
> The only one I can think of is that its a bit easier to get going, and if you change a field definition (eg varchar(20) ->  varchar(30)) there are no changes to make. Also if you add a field you can access it. Width persistent fields if you declare some then the others effectively disapear (been caught with that one a few times).
>
> On the downside using FieldByName is less efficient since a lookup has to be done to obtain the fields position in the array. You already mentioned another big downside(mistyping). The final one, which I'm not sure about, is how efficient it is having your code littered with literals. I have no idea what the compiler does either with wadges of 'ThisFieldName' or a defined constant ThisFieldName = 'ThisFieldName' which is then splattered everywhere.
>
>
> Roy Lambert
>

You know what I'd do in this case?  I'd create the query with both
fields, create persistent fields for both, then branch the code
afterwords pulling the value from the one I want.

In cases where I've needed a different where clause or where I can't
finish the SQL at design time, I actually create a usable SQL to create
the persistent fields that I know I'll need, then comment out part of
the SQL in the query component and finish it in code.  But by that time,
I already have the persistent fields I need.

I'll bend over backwards to have persistent fields rather than use
FieldByName--but that's just me!

--
David Cornelius
Cornelius Concepts

On 7/23/2010 12:38 AM, Roy Lambert wrote:
> David
>
>
> Here's a little example where I find FieldByName invaluable
>
>     if Message.LParam = 11 then emst := 'Current' else emst := 'Archive';
>     nlhMessageDlg('The Email search ' + lu.EMSearches_Name.AsString + ' is finished with '
>      + lu.EMSearches.FieldByName('_' + emst + 'Hits').AsString + ' hits in the ' + emst + ' emails'
>      , mtInformation, [mbOK], 0);
>
> I could solve it differently but I find this more comprehensible.
>
> Roy Lambert
>