Subject | Re: [IBO] TIB_Query: Problem with SQL Parsing? |
---|---|
Author | Helen Borrie |
Post date | 2003-09-09T16:07:59Z |
At 03:42 PM 9/09/2003 +0000, you wrote:
should use SQL.Add('a string')
That's how the inline editor populates the SQL property, too.
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.) 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.
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.
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. (I even seem to recall it was a read-only property in Delphi 1 and
2...)
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.
Helen
> > > How did the CR and LF characters get in there? How are youAssigning to SQL.Text is NOT the right way to set the SQL property. You
> > setting the SQL
> > > property?
> >
> > CR and LF characters are standard line-breaking characters in
> > Windows text (strings of a multi-line control).
> > They are being put in there by TIB_Query component itself, more
> > precisely, by its embedded TStrings object (SQL property): "When
> > reading Text, the strings in the list will be separated by
>carriage
> > return and line feed" (from Delphi online help).
> > TIB_Query should have parse TStrings properly, but it looks as it
> > doesn't.
>
>...in some cases (which ones?).
>
>To clarify a little bit more, and to answer the question asked - I
>set SQL property at design time in this case. However, even if you
>do that at run time by SQL.Append or something like that, SQL.Text
>will contain CR+LF.
should use SQL.Add('a string')
That's how the inline editor populates the SQL property, too.
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.) 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.
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.
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. (I even seem to recall it was a read-only property in Delphi 1 and
2...)
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.
Helen