Persistent fields are objects that are created and last for the life of
the form or data module their parent component are placed upon, whether
or not they are ever used.  If you have one data module in your
application with lots of tables/queries and lots of fields in each, that
could theoretically eat up more memory than creating stuff dynamically
or looking up fields with FieldByName at run-time.

I'd be interested to know if there are any other considerations.

--
David Cornelius
Cornelius Concepts

On 7/24/2010 6:08 AM, Dale Derix wrote:
> So, what are the downfalls of using persistent field... if any?
>
> Dale
>

Dale,

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

If your field sizes change, the persistent fields don't pick up that size
change.  That's a big one if the end user can change field sizes within your
app.

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

Now shipping Atrex 13.  For more information go to
 http://www.atrex.com/news.asp

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

David

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

If you have persistent fields defined but NotThisOne is not defined in that list you can't access it via FieldByName even. There have been a few posts about this, and I have been caught by it as well. I think its to do with which of the list of fields is used. Things may have changed in different flavours of Delphi.

Roy Lambert

Terry

>If your field sizes change, the persistent fields don't pick up that size
>change. That's a big one if the end user can change field sizes within your
>app.

When users get involved all bets are off


Roy Lambert

David

>Persistent fields are objects that are created and last for the life of
>the form or data module their parent component are placed upon, whether
>or not they are ever used. If you have one data module in your
>application with lots of tables/queries and lots of fields in each, that
>could theoretically eat up more memory than creating stuff dynamically
>or looking up fields with FieldByName at run-time.


That's something I've been keeping an eye on. Its difficult to tell since I didn't do it in a controlled fashion, but I think moving to named constants added c50k on (500+ field constants set up - probably not all used) and adding in c150 persistent fields whilst leaving the constants alone doesn't seem to have made any impact.

I'm also going to start looking at directly accessing the Fields array. Earlier experiments showed that that was faster even than persistent fields (the rankings were Fields[..], persistentfield, FieldByName(..)) so for threads and heavy loops I may start looking at a mechanism to obtain the field positions as a one off hit and then use them.

Roy Lambert

I stand corrected!  I had never heard of that, but I just tried it
(something I should've done before opening my big mouth in a public
forum!) and you are correct.  Very interesting.

--
David Cornelius
Cornelius Concepts

On 7/26/2010 12:45 AM, Roy Lambert wrote:
> If you have persistent fields defined but NotThisOne is not defined in that list you can't access it via FieldByName even. There have been a few posts about this, and I have been caught by it as well. I think its to do with which of the list of fields is used. Things may have changed in different flavours of Delphi.