Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Delphi long string, not RAD.. at all



Permlink Replies: 21 - Last Post: Jun 11, 2015 11:36 AM Last Post By: Jeff Overcash (...
Clement Doss

Posts: 133
Registered: 9/19/00
Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 9:43 AM
Hi,

I'm using Delphi XE8, but this apply to the very first turbo pascal 1.0 <g>

The delphi way to handle long string ( more than 255 chars ) is to split with '+' in each line.

const
   _my_long_string = 'Some line'+
                              'Some Another line'+
                              'Some extra line'+
                              ....
                              'Last one';


In database application, some queries have 220 lines that must be combined with "%s" and "%d" and sometime other expressions. To copy and paste from a delphi editor to a SQL explorer, I need to remove all the quotes and '+' every time. And once I debug it on a SQL Explorer, I must reapply every ' "+ ' and %s and %d..

I guess Marco will not be happy with what comes next... but I have to ask

Why can't we have a "long string" syntax.. It would be very good to write

   _my_long_string = "Some line
                               Some Another line
                               Some extra line
                               ....
                               Last one";
  _my_sql_string = "Select 
                                F1,
                                F2
                                F3
                                F4
                             from T1
                             join T2 on ()
                             join T3 on ()
                             where ...
                                and ...
                                and exists( select 1 from T4 
                                                           where .... )
                            order by 1 ";
  _my_sql_string2 = @'Select 
                                F1,
                                F2
                                F3
                                F4
                             from T1
                             join T2 on ()
                             join T3 on ()
                             where ...
                                and ...
                                and exists( select 1 from T4 
                                                           where .... )
                            order by 1 ';
 


This would be "RADder" since I can Copy/Paste directly from Delphi Editor to SQL Explorer and back.

Initializing long strings this way would help a lot

There you go.. I said it :)

Clément

Robert Love

Posts: 155
Registered: 5/3/07
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 11:48 AM   in response to: Clement Doss in response to: Clement Doss
Why can't we have a "long string" syntax.. It would be very good to write
{code}
_my_long_string = "Some line
Some Another line
Some extra line
....
Last one";

So does the first string have no spaces at the beginning and lots of spaces or tabs before each line in the data?

Or is there some other magic that you propose to deal with the inherit white-space? Would each line have an embedded CR and/or LF and what about platform differences, should this conform to the different platforms if they are embedded?

I am not against this idea, just see some problems that need to be clarified first.

It is supported in many languages although its different in each.

In C# long strings that wrap need a different syntax: @""
In Perl you have to declare an end Mark with "here-document" or qq() and then have to strip the quotes.
In Ruby you syntax an End Mark like in Perl.
In Python you use """
In VB.NET prior to 2015 you could use a hack of inline XML <sql>multi line sql statement</sql>.Value
in VB.NET 2015 you can just use :" and the begin/end and new lines can be inserted.
JavaScript has no support for multi-line strings unless you consider escaping the new line with a \ on the end of each line, but in EcmaScript 6 you will be able use `multline string` to do this.

Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 12:08 PM   in response to: Robert Love in response to: Robert Love
Robert wrote:

It is supported in many languages although its different in each.

In C++, multiple string literals to be concatenated together by the compiler
if they are separated only by whitespace/linebreaks, which get ignored during
the concatenation, eg:

_my_long_string = "Some line"
    "Some Another line"
    "Some extra line"
    ....
    "Last one";


Is the same as doing this:

_my_long_string = "Some lineSome Another lineSome extra line....Last one";


If you want line breaks in the string data, you have to be explicit about it:

_my_long_string = "Some line\n"
    "Some Another line\n"
    "Some extra line\n"
    ....
    "Last one";


Is the same as:

_my_long_string = "Some line\nSome Another line\nSome extra line\n....Last 
one";


--
Remy Lebeau (TeamB)
Clement Doss

Posts: 133
Registered: 9/19/00
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 12:20 PM   in response to: Robert Love in response to: Robert Love
Robert Love wrote:
Why can't we have a "long string" syntax.. It would be very good to write
   _my_long_string = "Some line
                               Some Another line
                               Some extra line
                               ....
                               Last one";</div>
 
 
 So does the first string have no spaces at the beginning and lots of spaces or tabs before each line in the data?
 
Or is there some other magic that you propose to deal with the inherit white-space?  Would each line have an embedded CR and/or LF and what about platform differences, should this conform to the different platforms if they are embedded? 
 </div>
 
The CR/LF will indicate a line break. So the way I wrote my example all the white-spaces should remain untouched. In the case of SQL, that indentation is *very* important to keep the clause readable.
Like in the following example, it's very easy to copy/paste the code: 

Const
_MyCustomerSQL = "
Select CustID,
CustName
from Customer
where CustID = %d
";
  
The idea is to keep the exact layout. In order to remove the white spaces, the code should be written like

Const
_MyCustomerSQL = "
Select CustID,
CustName
from Customer
where CustID = %d
";
{code}

The expression would end at each CR/LF no extra white-space is required.

As for the different platforms, since the code is still written in Delphi under windows, windows CR/LF style should be applied.
And once the targeted platform is select, the compiler should change CR/LF to meet the platform standards.

It would be a great way to initialize long string values :)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 1:26 PM   in response to: Clement Doss in response to: Clement Doss
Clement wrote:

The CR/LF will indicate a line break.

The issue Robert was asking about was the leading whitespace on the *second
and subsequent lines*. Should the syntax preserve or ignore leading
whitespace in the resulting string data?

If it preserves whitespace, then you have to do this:

Const
  _MyCustomerSQL = "
Select CustID,
CustName
from Customer
where CustID = %d";


But lets say such an assignment is on a variable rather than a const, and
the assignment statement is indented quite a ways into the code:

...
  ...
    ...
      ...
        ...
        _MyCustomerSQL = "
Select CustID,
CustName
from Customer
where CustID = %d
";
        ...
      ...
    ...
  ...
...


That could get quite unsightly in larger codebases.

On the other hand, if the whitespace is ignored, the indenting can be handled
more logically:

...
  ...
    ...
      ...
        ...
        _MyCustomerSQL = "
          Select CustID,
          CustName
          from Customer
          where CustID = %d";
        ...
      ...
    ...
  ...
...


But then how do you designate leading whitespace when you really need it?

So the way I wrote my example all the white-spaces should remain untouched.

Which means it is wasted overhead, both in compiling the string data, and
parsing the data at runtime.

As for the different platforms, since the code is still written in
Delphi under windows, windows CR/LF style should be applied.

The code may be written on Windows, but it is compiled for multiple platforms,
and different platforms have different linebreak semantics. For instance,
that is why the RTL declares an 'sLineBreak' constant to begin with.

--
Remy Lebeau (TeamB)
Clement Doss

Posts: 133
Registered: 9/19/00
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 2:21 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Hi Remy :)


The issue Robert was asking about was the leading whitespace on the *second
and subsequent lines*. Should the syntax preserve or ignore leading
whitespace in the resulting string data?

If it preserves whitespace, then you have to do this:

Const
  _MyCustomerSQL = "
Select CustID,
CustName
from Customer
where CustID = %d";


The problem is simpler. In my case it doesn't make sense to assign in the middle of the code 220 lines of query.
The idea is to keep Delphi and SQL code readable.
This code shouldn't be written:
  ...
    ...
      ... 
        MyCustomerSQL := "
                   {220 lines of SQL here}
        ";
   ..
   ..


The code formatting I use looks like:

*const*
    _MyCustomerSQL := "
              {220 lines of SQL here}
     "
begin
    result := format( _MyCustomerSQL,[ aCustID ] );
end;

Or the SQL is in its own unit.

Unit Customer.SQL.const;
 
interface
 
const
   _MyCustomerSQL = "
      Here it goes again
   ";
 


For such long text it doesn't make sense to use in the middle of the code, and mixing chars (like \n) is not a solution either :)

In this case the leading space must be kept not just for layout, but to avoid "merging identifiers with keywords"
Ex: _MySql = "Select
F1,
F2,
F3
From Table
Where F1=1
"
This will be interpreted as SelectF1,F2,F3From TableWhere F1=1 . The SQL server will complain. For that reason the leading space must be kept.

Why not having 2 syntaxes then...
What about a syntax with and without a leading char..
const
   _MyLongConst = !"This constant
                                won't have
                                any leading space"; // This constantwon't haveany leading space
 
  _MyLonqSQL    = "This syntax
                              will keep the 
                              leading space
                             "; // This syntax        will keep the     leading space
 


<RAD>
I just wrote another CTE query with 200 lines RADnesslessly
</RAD>

Clément
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 2:44 PM   in response to: Clement Doss in response to: Clement Doss
Clement wrote:

The problem is simpler. In my case it doesn't make sense to assign in
the middle of the code 220 lines of query.

I wasn't suggesting that the query be 220 lines long. Even a 2-line query
would suffer from the same issues I mentioned.

The code formatting I use looks like:

You really should be using parameterized queries, or even stored procedures,
instead of manually formatted SQL statements. Both for security and performance
reasons.

In this case the leading space must be kept not just for
layout, but to avoid "merging identifiers with keywords"

Ex: _MySql = "Select

F1,

F2,

F3

From Table

Where F1=1

"

This will be interpreted as SelectF1,F2,F3From TableWhere F1=1 .

Line breaks inside the literal would have to be preserved to avoid that:

_MySql = "Select
F1,
F2,
F3
From Table
Where F1=1
";


Equivilent to:

_MySql = 'Select'#13'F1,'#13'F2,'#13'F3'#13'From Table'#13'Where F1=1'#13;


But my issue would be with leading whitespace on each line. Should this:

_MySql = "Select
    F1,
    F2,
    F3
    From Table
    Where F1=1
";


Be equivilent to this:

_MySql = 'Select'#13'    F1,'#13'    F2,'#13'    F3'#13'    From Table'#13' 
   Where F1=1'#13;


Or this:

_MySql = 'Select'#13'F1,'#13'F2,'#13'F3'#13'From Table'#13'Where F1=1'#13;


It would not make a difference to SQL, which you are propsoing a generalized
syntax that could be used for many different things, and leading whitespace
handling may make a big difference in other situations where this syntax
could be used.

Why not having 2 syntaxes then...

Why not have 3 or 4 syntaxes then? Why keep cluttering the syntax at all?
Maybe it would be easier (and safer) to not alter the syntax at all, but
install to integrate a new right-click menu item in the code editor that
simply copies the selected text and strips off syntax elements from it.

What about a syntax with and without a leading char..

Seriously? Now you are just getting crazy...

--
Remy Lebeau (TeamB)
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 3:05 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Agreed its a security issue to dynamically construct SQL statements.
One should definitely use parameters. Even with parameters though SQL
statements can get pretty large and it would be nice to see them
represented as a multi line string.

Also, there's other uses for multiline string. Inline templating is one.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 3:26 PM   in response to: Mike Margerum in response to: Mike Margerum
Mike wrote:

Agreed its a security issue to dynamically construct SQL statements.
One should definitely use parameters. Even with parameters though
SQL statements can get pretty large and it would be nice to see
them represented as a multi line string.

Parameterized queries are precompiled and you don't see the final statements
with values filled in until they are actually executed on the database.
That is where SQL debuggers come into play.

--
Remy Lebeau (TeamB)
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 7:19 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
On 6/10/15 6:26 PM, Remy Lebeau (TeamB) wrote:
Mike wrote:

Agreed its a security issue to dynamically construct SQL statements.
One should definitely use parameters. Even with parameters though
SQL statements can get pretty large and it would be nice to see
them represented as a multi line string.

Parameterized queries are precompiled and you don't see the final statements
with values filled in until they are actually executed on the database.
That is where SQL debuggers come into play.

cant you do something like

select * from testtable where id=:idParam

and then set the idParam in code?
Jeff Overcash (...

Posts: 1,529
Registered: 9/23/99
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 9:18 PM   in response to: Mike Margerum in response to: Mike Margerum
Mike Margerum wrote:
On 6/10/15 6:26 PM, Remy Lebeau (TeamB) wrote:
Mike wrote:

Agreed its a security issue to dynamically construct SQL statements.
One should definitely use parameters. Even with parameters though
SQL statements can get pretty large and it would be nice to see
them represented as a multi line string.
Parameterized queries are precompiled and you don't see the final statements
with values filled in until they are actually executed on the database.
That is where SQL debuggers come into play.

cant you do something like

select * from testtable where id=:idParam

and then set the idParam in code?

Parameters are not macro expansions. This

select * from testtable where id=:idParam

gets preprocessed to this

select * from testtable where id= ?

and sent to the server to be prepared only once. The prepare determines the
plan that will be used and the types for the parameters. Then with the handle
returned to the prepared statement is returned the parameters are set and the
SQL is then executed.

When you close it and change the param and reopen it, the prepare stage does not
happen again, just the setting of the variable(s) to be sent against the handle
you got earlier.

This is much faster particularly in tight loops like processing an input file
into a database. It also lets things like Dates not have to be passed as
strings which requires the client and the server to agree on the Str to Date
formatting, but instead passed as a binary number eliminating formatting from
the equation.

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted corridors of Whitehall.
(Fish)
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 11, 2015 7:29 AM   in response to: Jeff Overcash (... in response to: Jeff Overcash (...

cant you do something like

select * from testtable where id=:idParam

and then set the idParam in code?

This is much faster particularly in tight loops like processing an input file
into a database. It also lets things like Dates not have to be passed as
strings which requires the client and the server to agree on the Str to Date
formatting, but instead passed as a binary number eliminating formatting from
the equation.

I dont get why I cannot prepare

select * from testtable where id=:idParam

once and then just set params using params property of the query object
and call execute

or i can just call ParamByName('idParam').Value = newValue and execute

I do this all the time
Jeff Overcash (...

Posts: 1,529
Registered: 9/23/99
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 11, 2015 11:36 AM   in response to: Mike Margerum in response to: Mike Margerum
Mike Margerum wrote:
cant you do something like

select * from testtable where id=:idParam

and then set the idParam in code?

This is much faster particularly in tight loops like processing an input file
into a database. It also lets things like Dates not have to be passed as
strings which requires the client and the server to agree on the Str to Date
formatting, but instead passed as a binary number eliminating formatting from
the equation.

I dont get why I cannot prepare

select * from testtable where id=:idParam

once and then just set params using params property of the query object
and call execute

or i can just call ParamByName('idParam').Value = newValue and execute

I do this all the time

It is totally dependent on the TDataset descendant you are using.

The BDE for instance required an explicit call to Prepare to prepare it and keep
it prepared until you called unprepare. Otherwise the BDE would unprepare when
the query was closed.

IBX, FireDAC, and I think DBX though only unprepare when the SQL changes (not
parameter values). So in that case explicit calls to prepare are not normally
needed and it is prepared only once the first time used and stays prepared until
the the SQL changes or usually the transaction ending causes an unprepare too
(plans are transaction specific so usually the unprepare is done in case indexes
are changed out from underneath the plan from transaction totransaction).

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted corridors of Whitehall.
(Fish)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 10:09 PM   in response to: Mike Margerum in response to: Mike Margerum
Mike wrote:

cant you do something like

select * from testtable where id=:idParam

and then set the idParam in code?

Yes, that is precisely what a parameterized query is. But you cannot retreive
the final SQL statement as a string after you have populated the parameter
values. The statement only exists in its final form inside the database
engine.

--
Remy Lebeau (TeamB)
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 11, 2015 7:25 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
On 6/11/15 1:09 AM, Remy Lebeau (TeamB) wrote:
Mike wrote:

cant you do something like

select * from testtable where id=:idParam

and then set the idParam in code?

Yes, that is precisely what a parameterized query is. But you cannot retreive
the final SQL statement as a string after you have populated the parameter
values. The statement only exists in its final form inside the database
engine.

Right. I'm saying that if im building an SQL statement is code using
long strings multi line literals would be useful. I dont need to see
the final SQL with params. I need to be able to read the SQL in code
with the : params in it.
Linden ROTH

Posts: 467
Registered: 11/3/11
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 3:39 PM   in response to: Clement Doss in response to: Clement Doss
Clement Doss wrote:
The code formatting I use looks like:

*const*
    _MyCustomerSQL := "
              {220 lines of SQL here}
     "
begin
    result := format( _MyCustomerSQL,[ aCustID ] );
end;

Or the SQL is in its own unit.

Unit Customer.SQL.const;
 
interface
 
const
   _MyCustomerSQL = "
      Here it goes again
   ";
 


For such long text it doesn't make sense to use in the middle of the code, and mixing chars (like \n) is not a solution either :)

Or store it in a DB table ... the only SQL in your app is the one to read the SQL table ... extra fields to describe params etc
--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"
Clement Doss

Posts: 133
Registered: 9/19/00
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 11, 2015 7:53 AM   in response to: Linden ROTH in response to: Linden ROTH
Hi Linden

For such long text it doesn't make sense to use in the middle of the code, and mixing chars (like \n) is not a solution either :)

Or store it in a DB table ... the only SQL in your app is the one to read the SQL table ... extra fields to describe params etc

Store it in a DB Table or resource is not an option for this project.
The long text must be written in SQL tool (such Manager studio for example), worked there for a few hours and then transformed into delphi syntax.
When something changes, I have to get the delphi syntax code and reformat it to SQL syntax, fix and change accordingly, and then reapply the delphi syntax. As it's a lot of work mor and more changes are applied directly into Delphi code. . very risky

In my particular case, those queries will not run in a tight loop. They will run several times during a day though.

Delphi's actual syntax for initializing long strings is not helping, being it SQL query, or any other long text.It might be time for a syntax update :)

Clément
Linden ROTH

Posts: 467
Registered: 11/3/11
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 11, 2015 8:09 AM   in response to: Clement Doss in response to: Clement Doss
Clement Doss wrote:
Hi Linden

For such long text it doesn't make sense to use in the middle of the code, and mixing chars (like \n) is not a solution either :)

Or store it in a DB table ... the only SQL in your app is the one to read the SQL table ... extra fields to describe params etc

Store it in a DB Table or resource is not an option for this project.
The long text must be written in SQL tool (such Manager studio for example), worked there for a few hours and then transformed into delphi syntax.
When something changes, I have to get the delphi syntax code and reformat it to SQL syntax, fix and change accordingly, and then reapply the delphi syntax. As it's a lot of work mor and more changes are applied directly into Delphi code. . very risky

In my particular case, those queries will not run in a tight loop. They will run several times during a day though.

Delphi's actual syntax for initializing long strings is not helping, being it SQL query, or any other long text.It might be time for a syntax update :)

Clément

So write a program to do the transformations ... this will eliminate some of the risk !

--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"
Eric Schreiber

Posts: 2
Registered: 10/8/00
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 2:45 PM   in response to: Clement Doss in response to: Clement Doss
Clement Doss wrote:

In database application, some queries have 220 lines that must be combined with
"%s" and "%d" and sometime other expressions. To copy and paste from a delphi
editor to a SQL explorer, I need to remove all the quotes and '+' every time. And
once I debug it on a SQL Explorer, I must reapply every ' "+ ' and %s and %d..

Seems to me that changing the way long strings are handled in the Delphi editor is kind of solving the wrong problem. The real problem is your approach to debugging these SQL statement strings.

The steps you're going through don't result in you testing what your program is producing. Rather, you're testing what you think the program is producing. Would it not be better to simply let your program do its thing to build your SQL statement, perform all the %s and %d replacements, and concatenations, then use Clipboard.AsText := MySQLString to copy the actual product of your program to the clipboard? You can paste that directly into your SQL explorer, and be confident that you're testing the SQL statement that your program is really generating.

And there's no need to copy and modify the SQL explorer statement back into your Delphi code. Just make appropriate changes in the Delphi editor, and rerun your test.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 3:11 PM   in response to: Eric Schreiber in response to: Eric Schreiber
Eric wrote:

... then use Clipboard.AsText := MySQLString to copy the
actual product of your program to the clipboard?

Or, just let the code execute the SQL queries normally, and use a separate
SQL debugger tool to look at the real queries as they are being executed.

--
Remy Lebeau (TeamB)
Clement Doss

Posts: 133
Registered: 9/19/00
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 10, 2015 4:00 PM   in response to: Eric Schreiber in response to: Eric Schreiber
Hi Eric,

Seems to me that changing the way long strings are handled in the Delphi editor is kind of solving the wrong problem. The real problem is your approach to debugging these SQL statement strings.

The steps you're going through don't result in you testing what your program is producing. Rather, you're testing what you think the program is producing. Would it not be better to simply let your program do its thing to build your SQL statement, perform all the %s and %d replacements, and concatenations, then use Clipboard.AsText := MySQLString to copy the actual product of your program to the clipboard? You can paste that directly into your SQL explorer, and be confident that you're testing the SQL statement that your program is really generating.

And there's no need to copy and modify the SQL explorer statement back into your Delphi code. Just make appropriate changes in the Delphi editor, and rerun your test.

The query is long. It can't be written without SQL tool. There are fields, tables, syntax and performance issue that must be handled in a proper SQL explorer or Analyzer. My point being that the query is born in an SQL environment, and then I have to modified it to suite delphi string limitation. If there are any changes, I can use the clipboard as you mentioned and paste the query in SQL environment, I do the changes, fix everything in the SQL environment and then I have to reapply all the delphi syntax again, being it using "%s" or parameters :)
David Keith

Posts: 196
Registered: 12/10/99
Re: Delphi long string, not RAD.. at all
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 11, 2015 8:23 AM   in response to: Clement Doss in response to: Clement Doss
Clement Doss wrote:

Hi Eric,

Seems to me that changing the way long strings are handled in the Delphi editor is kind of
solving the wrong problem. The real problem is your approach to debugging these SQL statement
strings.

The steps you're going through don't result in you testing what your program is producing.
Rather, you're testing what you think the program is producing. Would it not be better to
simply let your program do its thing to build your SQL statement, perform all the %s and %d
replacements, and concatenations, then use Clipboard.AsText := MySQLString to copy the actual
product of your program to the clipboard? You can paste that directly into your SQL explorer,
and be confident that you're testing the SQ
L statement that your program is really generating.

And there's no need to copy and modify the SQL explorer statement back into your Delphi code.
Just make appropriate changes in the Delphi editor, and rerun your test.

The query is long. It can't be written without SQL tool. There are fields, tables, syntax and
performance issue that must be handled in a proper SQL explorer or Analyzer. My point being that
the query is born in an SQL environment, and then I have to modified it to suite delphi string
limitation. If there are any changes, I can use the clipboard as you mentioned and paste the
query in SQL environment, I do the changes, fix everything in the SQL environment and then I have
to reapply all the delphi syntax again, being it using "%s" or parameters :)

What about taking a stringbuilder, subclassing it & adding a DelphiSQL property. Then write a
getter that parses the SQL and formats it for Delphi consumption? Then when you finish in your SQL
editor you append(SQLEditorString) to the stringbuilder. When you need the Delphi formatted version
just read it:

var
s: UnicodeString;
begin
s := StringBuilder.DelphiSQL;
end;

A bit of work, you'll need to use SQL key words as separators etc. but should be doable.

--
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02