At 05:02 PM 15/03/2006, you wrote:

>Now to be sure, I searched for "tstringlist limitations"
>and somewhere someone says that tstringlist can handle up to 4 gb of
>data. I don't know if I would ever or would ever like to load 4 gb of
>text into tstringlist, but I guess that's enough to assure my
>paranoid thinking. It won't hurt though to consider "what-ifs". Would
>you like to comment on this? Thank you.

Let's say you're using a bigint for your gl code (max 20 bytes
possible). Let's say your account description is 60 bytes. "=" 1
byte. Thats 81 bytes per account. 4 Gb (if that's the limit, it
seems extraordinarily high) could accommodate approximately 53
million accounts. I have a slight feeling that something else in the
system might break before you needed that many strings in your
stringlist. (I'm trying to visualise what a stack of 53 million
sheets of A4 looks like in the printer room...)

Here's a little tip from the wise, though. I worked on a project
where the Big Gun lead programmer used the NAME=VALUE trick to
process calls for phone company billing. The monthly bills used to
take all night and half the next day to run, for big telcos, much
longer. (Well, it WAS mssql server!) He was very precious about his
Delphi code and wouldn't let anyone else suggest anything to tune the app.

Then he went on an overseas holiday for 6 weeks. I got left
babysitting the servers over a weekend (the time we reserved for the
really big billing runs). For one particularly large telco it had
reached the point where the bill-printing app just hung up repeatedly
at about the third or fourth account, because the DB server would
time out before the app had finished processing this darned stringlist.

Eventually, cold, alone and very, very tired, late on the Sunday
night, I went into this guy's sacred code and replaced these
stringlists with PAIRS of stringlists. I put the NAME element in one
and the VALUE element in the other, and changed the code so that the
app would find the key in stringlist 1, get the strings[] index and
use it to pick up the VALUE from the second stringlist. After that
fix, the billing reports for that customer ran in 4 hours instead of
needing 2 days, and no timeouts.

So, it's a long story with a short moral: think laterally as well as
longitudinally. :-)

Helen