David


I have found a really good reason to use constants - I've spotted that I've used minor variants (eg StartDate, WantedDate, StartingDate) for essentially the same thing. I'm going to be doing some tidying up

I'm also going to revisit forms where I have tables and haven't used persistent fields for some reason and see if I should.

<<There's no difference at run-time
between a literal string or a constant that points to a literal string.>>

However, the .exes have grown a bit - strange but true.

Roy Lambert

I almost always use constants instead of literals.  Even for one-off
situations.  They're self-documenting and often grouped with other
declarations, making them nicely organized.

--
David Cornelius
Cornelius Concepts

On 7/23/2010 7:43 AM, Roy Lambert wrote:
> David
>
> I have found a really good reason to use constants - I've spotted that I've used minor variants (eg StartDate, WantedDate, StartingDate) for essentially the same thing. I'm going to be doing some tidying up

David,

I use the same approach as you do - persistent fields whenever possible,
if they are not available at design time but are known ahead, create
them with a query - exactly as you said, and only use FieldByName when
there is really no means of knowing the field names  ahead in design
time or in particular cases when the trouble of creating them is clearly
greater than the benefits.

--
Fernando Dias
[Team Elevate]

Thanks for the feedback.  I sometimes wonder if the habits I've
developed over the years are good or bad.  It's useful to look around
and compare notes with others occasionally.

--
David Cornelius
Cornelius Concepts

On 7/23/2010 9:40 AM, Fernando Dias wrote:
> David,
>
> I use the same approach as you do - persistent fields whenever possible,
> if they are not available at design time but are known ahead, create
> them with a query - exactly as you said, and only use FieldByName when
> there is really no means of knowing the field names ahead in design time
> or in particular cases when the trouble of creating them is clearly
> greater than the benefits.
>
> --
> Fernando Dias
> [Team Elevate]
>

David / Fernando


With you posts I'm beginning to wonder why I've slipped into using FieldByName as much as I have (around 700 occurrences through the app). I shall have a revisit and see how many I can annihilate.

Hmmm I wonder if Tim could manage persistent parameters for queries/scripts?

Roy Lambert

So, what are the downfalls of using persistent field... if any?

Dale

Dale

>So, what are the downfalls of using persistent field... if any?

I'm feeling generous so I won't suggest just reading my other post

The only real downside I know of is that if you don't declare them all as persistent any that aren't so declared essentially vanish and can't be accessed in any way.

Roy Lambert

Roy,

<< Hmmm I wonder if Tim could manage persistent parameters for
queries/scripts? >>

I don't think you'd want that, frankly.   The number of parameters is
usually pretty small, so there isn't as much performance benefit, and the
benefits of having the parameters automatically adjust when the SQL is
changed would be negated.

--
Tim Young
Elevate Software
www.elevatesoft.com

David


Just for interest.

As I'm working through my app merrily converting FieldByName to persistent fields I have discovered one circumstance where I have to use FieldByName and one where its easier to use it.

The circumstance where you have to use FieldByName is where you pass a table/query as a parameter to a procedure/function. I can see no sane way round that. If you have a suggestion I'd be interested.

The other one - Bit of background first: Years ago when I first used Delphi W95/W98 had a limited number of file handles and Paradox used one for each file in the table per instance of a table so I developed the habit of using one copy of the table on a datamodule and switching context. Since the main app had a main form with a page control with a subsystem a page it was real fun keeping things in sync as the user clicked around. However, it made it easy to use persistent fields everywhere since there was only one copy of the table.

I still use a main form with a page control, but rather than developing directly on the page I use a form and then parent the form to a page. I've moved from a single central datamodule to having one of those for lookup/occasional use tables to each form having its own tables/queries. This way I can have multiple copies of a page (eg projects) without worrying about having to keep them in sync.

Some of the tables may only use one or two fields and for those its convenient to use FieldByName with no persistent fields. Otherwise you either have to get all fields or make sure you have identified every field used in a lookup, .Locate, .FindKey etc or else.

Roy Lambert

Huh?  You can always access any field with FieldByName, whether or not
it was declared as a persistent field.

--
David Cornelius
Cornelius Concepts

On 7/24/2010 6:55 AM, Roy Lambert wrote:
> The only real downside I know of is that if you don't declare them all as persistent any that aren't so declared essentially vanish and can't be accessed in any way.