"Harry de Boer" <harry@staaf.nl> wrote in
news:23B90295-B6B0-4E0D-AAFA-DF57E59D1F40@news.elevatesoft.com:

> That would be just a learning curve for us, so maybe no big deal at
> all. Only thing that can be harder is to convert old programs. Either
> way; I'm trusting you choose the best.
>

The best solution, IMHO, would be another EDB component called
EDBSimpleSQLScript which would accept the old style and send it to EDB
in a form it can accept (with necessary limitations e.g. no parameters
allowed).

By the way, Tim, this part of the help file seems to contradict all
this:

http://www.elevatesoft.com/edb1d7_tedbquery_sql.htm

<QUOTE>
TEDBQuery.SQL Property

property SQL: TEDBStrings

Usage

Use the SQL property to specify the text of the SQL statement that the
TEDBQuery component executes when its Open or ExecSQL methods are
called. The SQL property may contain multiple SQL statements as long as
they are separated by semicolons ( </QUOTE>

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.02 build 1)

Chris


Essentially that's what I did for the database creation stuff since I also have some triggers. I use a TStringList container, a custom separator (¬) rather than semicolon and a small function. Its not difficult.

Roy Lambert

Chris,

<< By the way, Tim, this part of the help file seems to contradict all this:
>>

It was "in process" and not complete, although it is now.

--
Tim Young
Elevate Software
www.elevatesoft.com

Chris,

<< The best solution, IMHO, would be another EDB component called
EDBSimpleSQLScript which would accept the old style and send it to EDB in a
form it can accept (with necessary limitations e.g. no parameters allowed).
>>

I'm thinking that might be the best solution.  At any rate, the scripts
*will* use a separate component from the TEDBQuery.  I thought that the way
DBISAM worked was a bit confusing since it wasn't obvious that multiple SQL
statements could be used due to the naming of the component.

--
Tim Young
Elevate Software
www.elevatesoft.com

Harry,

<< If it means less coding (and so less bugs) and even more possible
functionality for us I understand that you lean towards (b). >>

That's the main issue.  If I go with b), then a whole world of new
functionality and power opens up to scripts, including the ability of
scripts to generate SQL themselves dynamically.

<< One question though: with (b): is the old way of writing scripts
(statement1; statement2still possible, or is it a complete new way of
writing them? >>

It would be a completely new way of writing them.

<< That would be just a learning curve for us, so maybe no big deal at all.
Only thing that can be harder is to convert old programs. Either way; I'm
trusting you choose the best. >>

What I'm seriously considering if I go with b) is an option to convert
old-style scripts to the new style in the EDB Manager.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< That's the main issue.  If I go with b), then a whole world of new
functionality and power opens up to scripts, including the ability of
scripts to generate SQL themselves dynamically. >>

Does it have to be either a) or b), or would it be possible to mix the two,
i.e. support both regular and dynamic SQL statements in SQL text ?

Such a combination would be both flexible and powerful.

Ole Willy Tuv

Ole,

<< Does it have to be either a) or b), or would it be possible to mix the
two, i.e. support both regular and dynamic SQL statements in SQL text ?

Such a combination would be both flexible and powerful. >>

Yes, it certainly would.  The issue is code duplication.  If I can figure
out a way to do the compilation for both without duplication, then it will
be easy.  Of course, all of this only applies to scripts - stored procedures
will never have regular statements in them because doing so causes the
database objects referenced in the regulard statements in the procedures to
become bound to the database, and that is a nightmare that I've already
dealt with once last fall during EDB development and don't care to revisit.


--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< Of course, all of this only applies to scripts - stored procedures will
never have regular statements in them because doing so causes the database
objects referenced in the regulard statements in the procedures to become
bound to the database, and that is a nightmare that I've already dealt with
once last fall during EDB development and don't care to revisit. >>

I understand However, I have this strange feeling that when you've
first found the way to do it in scripts, you'll figure out how to get around
it in PSM routines as well

Ole Willy Tuv

Ole,

<< I understand However, I have this strange feeling that when you've
first found the way to do it in scripts, you'll figure out how to get around
it in PSM routines as well >>

Actually, no.  Scripts can be compiled and bound all in one shot, and
the bindings are temporary in the context of the lifetime of the script.
Since procedures are stored in the database, their bindings are essentially
permanent and require that ElevateDB enforce the bindings in order to avoid
all sorts of nasty issues that are encountered when bound objects are
dropped, altered, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com