Tim,

The SQL file produced from performing the Reverse Engineer Function in the ElevateDB
Manager does not have any separators between the SQL statements.

Can this go on the wish list?

Thank you . . .

--
Richard Harding
Windella Computer Knowhow
28 Freeman Drive
Lochinvar NSW 2321
Phone:    61 2 4930 7336
Mobile:    0419 016 032
email:    rharding@wck.com.au

Richard,

<< The SQL file produced from performing the Reverse Engineer Function in
the ElevateDB Manager does not have any separators between the SQL
statements.

Can this go on the wish list? >>

Sure, but keep in mind that the output from the reverse-engineering is not
in executable form anyways since EDB does not support scripts in that
manner.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>since EDB does not support scripts in that
>manner.


Hissss Boooo

Roy Lambert

Tim,

> Sure, but keep in mind that the output from the reverse-engineering is not
> in executable form anyways since EDB does not support scripts in that
> manner.

Shouldn't that be: <.quote>, yet.


Regards, Harry

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:8BBEB372-3392-4CE2-82D6-FEA95AACE184@news.elevatesoft.com...
> Richard,
>
> << The SQL file produced from performing the Reverse Engineer Function in
> the ElevateDB Manager does not have any separators between the SQL
> statements.
>
>  Can this go on the wish list? >>
>
> Sure, but keep in mind that the output from the reverse-engineering is not
> in executable form anyways since EDB does not support scripts in that
> manner.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Harry,

<< Shouldn't that be: <.quote>, yet. >>

Yes, but I'm still not sure if the script implementation will be more like
a) DBISAM's or more like the b) EDB stored procedures.  I'm leaning towards
b) because it means more code-sharing (less bugs) and easier movement of
scripts to stored procedures and/or vice-versa.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< Yes, but I'm still not sure if the script implementation will be more
like a) DBISAM's or more like the b) EDB stored procedures. >>

Since stored procedures in EDB are relying on dynamic SQL, I'd prefer option
a) for SQL scripts, i.e. a series of regular SQL statements separated by a
semicolon.

Ole Willy Tuv

Tim

My vote will be to a) like DBISAM. It is a powerfull toll we have and easy
to implement (I thought).

Eduardo

Tim,

<< Yes, but I'm still not sure if the script implementation will be more like
 a) DBISAM's or more like the b) EDB stored procedures. >>

I think that I would join the other votes so far and go for a).

Regards,
Dan

Sorry for "toll", it should be "tool".
When I said easy to implement, I´ve never used parameters then for me it is
something like below:

script = "sql1;sql2;sql3"

execute sql1 then execute sql2 then execute sql3

Or am I missing something ?

Eduardo

Tim,

If it means less coding (and so less bugs) and even more possible
functionality for us I understand that you lean towards (b).  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?
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.

Regards, Harry

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:AD71C3E4-E380-47BE-9F0C-B8B40180E191@news.elevatesoft.com...
> Harry,
>
> << Shouldn't that be: <.quote>, yet. >>
>
> Yes, but I'm still not sure if the script implementation will be more like
> a) DBISAM's or more like the b) EDB stored procedures.  I'm leaning
towards
> b) because it means more code-sharing (less bugs) and easier movement of
> scripts to stored procedures and/or vice-versa.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>