Tim

Q1. I seem to remember some time ago you saying there was a way to avoid the renaming of the .bpls for DBISAM if you moved to a more upto date thing than D5. Does that apply to ElevateDB because it would be nice not to have to mess around with my home brew components when you go from 1.01b1 to 1.02b1 to 1.03b1

Q2. Any idea of timescales for scripts to make their reappearance?

Q3. Any chance (if so any idea when) we can use parameters for things like field, table and database?

The latter two would have eased greatly my altering a component to use in-memory table rather than editing a read-only result set.

Roy Lambert

Roy,

<< Q3. Any chance (if so any idea when) we can use parameters for things
like field, table and database? >>

Parameters are placeholders for values (data). I don't think mixing values
and identifiers would be a good idea, if doable at all.

Ole Willy Tuv

"Ole Willy Tuv" <owtuv@online.no> wrote in message
news:B3423A59-761A-4077-8926-1E37CE66979D@news.elevatesoft.com...
> Roy,
>
> << Q3. Any chance (if so any idea when) we can use parameters for things
> like field, table and database? >>
>
> Parameters are placeholders for values (data). I don't think mixing values
> and identifiers would be a good idea, if doable at all.
>
> Ole Willy Tuv
>

I agree it's probably not a good idea.  But Firebird does have a SQL
extension that lets you do something like this, using its 'EXECUTE
STATEMENT' command.  EXECUTE STATEMENT takes  a string argument and attempts
to execute it as a sql command.  So you can construct a stored procedure
that takes several string arguments, e.g, the name of a column and a table,
then within the stored procedure construct a sql string that does something,
e.g., 'SELECT ' || COLUMN_VAR || '  FROM ' || table_var || ';' and feed it
in as argument of the EXECUTE STATEMENT.

Although it exists in Firebird it's not something they recommend you to use,
both because generating sql this way is prone to runtime errors and because
it's generally slow because statement needs to be reprepared each time it's
run.

-- Herb

Ole


Interesting. And the reason this is not a good idea is? Bear in mind I'm doing exactly that by using stringreplace.

Roy Lambert

Roy,


> Interesting. And the reason this is not a good idea is? Bear in mind I'm doing exactly that by using stringreplace.

It prevents a SQL statement being held in a prepared/precompiled state
which is the whole purpose of using parameters in the first place. If
you just want to make arbitrary alterations then there are other tools
for that job ("Format" being the one I personally use most often).

Eryk

Roy,

<< Q1. I seem to remember some time ago you saying there was a way to avoid
the renaming of the .bpls for DBISAM if you moved to a more upto date thing
than D5. Does that apply to ElevateDB because it would be nice not to have
to mess around with my home brew components when you go from 1.01b1 to
1.02b1 to 1.03b1 >>

I've still got it on my list of things to-do.

<< Q2. Any idea of timescales for scripts to make their reappearance? >>

They will definitely be available by the end of summer.  Right now I'm
concentrating on getting the ODBC driver and ADO.NET data provider
completed.

<< Q3. Any chance (if so any idea when) we can use parameters for things
like field, table and database? >>

No, definitely not.

--
Tim Young
Elevate Software
www.elevatesoft.com

Herbert,

<< I agree it's probably not a good idea.  But Firebird does have a SQL
extension that lets you do something like this, using its 'EXECUTE
STATEMENT' command.  EXECUTE STATEMENT takes  a string argument and attempts
to execute it as a sql command.  So you can construct a stored procedure
that takes several string arguments, e.g, the name of a column and a table,
then within the stored procedure construct a sql string that does something,
e.g., 'SELECT ' || COLUMN_VAR || '  FROM ' || table_var || ';' and feed it
in as argument of the EXECUTE STATEMENT. >>

ElevateDB has the exact same capability:

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



--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Interesting. And the reason this is not a good idea is? Bear in mind I'm
doing exactly that by using stringreplace. >>

It may appear that way on the surface, but that is not what is going on in
the engine.  Parameters are very efficient because they are treated as
constants and don't require a re-prepare of the statement.  If you start
allowing parameters for identifiers, then you effectively revert back to
re-preparing the statement for every execution.

Also, it is the job of the client application or developer to specify the
statements, and the engine's job to execute them.  How the statement is
built is entirely up to the client application or developer.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< And the reason this is not a good idea is? >>

The reason is that values and identifiers are completely different SQL
elements. Identifiers are database object names, while values are data
retrieved from or stored in database objects. How would you determine if a
parameter passing the character string value 'X' denotes a value or an
identifier ?

<< Bear in mind I'm doing exactly that by using stringreplace. >>

That's different from using parameters.

Ole Willy Tuv

Tim

>I've still got it on my list of things to-do.

Good.
>
><< Q2. Any idea of timescales for scripts to make their reappearance? >>
>
>They will definitely be available by the end of summer. Right now I'm
>concentrating on getting the ODBC driver and ADO.NET data provider
>completed.

When does summer end in your part of the world. In the Scottish Highlands, judging by the weather its already ended

><< Q3. Any chance (if so any idea when) we can use parameters for things
>like field, table and database? >>
>
>No, definitely not.

OK I'll have to continue to use StringReplace.

Roy Lambert