Hello,

> Assigning to SQL.Text is NOT the right way to set the SQL

property. You

> should use SQL.Add('a string')

Why? Please elaborate.

> That's how the inline editor populates the SQL property, too.

That is irrelevant. As I pointed out before, SQL.Text property DOES
contain CR+LF characters as line breakers regardless the way
SQL.Strings is being populated (unless it is one long string, of
course). You may easily confirm that fact using Delphi debugger.

> You can put the whole statement into one string if you want;

although the

> benefit of breaking up the strings is that it gets stored in the

DFM with

> your own formatting (indents, etc.)

Exactly. Readability is the whole point of source code formatting,
whether it is Delphi code or SQL statement, isn't it? The programs
are being written for people to read, not for computers :)

> If you do it the right way, the
> parser reads the strings one by one and there won't be CRs and LFs

at all.

Incorrect. There is no such "right way" to achieve that. CR+LF will
be present in SQL.Text, if it is populated line by line.

> There are a lot of TStrings around IBO so, if you want to indulge

your

> compulsion to assign to Text, this won't be the only place you'll

bump into

> this problem.

Please understand, I do not have any problems with CR+LF (neither
does TQuery, TIBQuery, and other query components I know; however,
TIB_Query does). Therefore, unless the problem manifests itself, I
do not intend to take any "preventive" measures. And the problems
seems to be only with SQL property for now.

> In fact, it makes no sense to assign to or read the Text property

of a

> TStrings unless there is some specific formatting or parsing

reason to do

> that.

Exactly. I did not try to do that until I got a problem with that.
Remember, there is no other way to get rid of CR+LF other than
either put the whole SQL statement in one line, or remove CR+LF from
SQL.Text (which effectively creates one-line SQL anyway).

> I doubt if it's even practicable to allow the SQL property to

misbehave and

> permit you to do it the wrong way, and then have the parser trim

out the

> unwanted CRLF characters, since people do sometimes want to store

these

> characters inside string data.

I believe "misbehaving" is a result of a bug in TIB_Query, and that
is the reason the subsequent reconstructive surgery is required.

Best regards,
D.P.