Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 10 of 19 total |
Separator in SQL file |
Sun, May 13 2007 7:40 PM | Permanent Link |
Richard Harding | 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 |
Mon, May 14 2007 5:41 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, May 15 2007 3:44 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>since EDB does not support scripts in that >manner. Hissss Boooo Roy Lambert |
Tue, May 15 2007 4:08 AM | Permanent Link |
"Harry de Boer" | 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 > > |
Tue, May 15 2007 5:33 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, May 15 2007 5:40 PM | Permanent Link |
"Ole Willy Tuv" | 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 |
Wed, May 16 2007 6:14 AM | Permanent Link |
"Jose Eduardo Helminsky" | Tim
My vote will be to a) like DBISAM. It is a powerfull toll we have and easy to implement (I thought). Eduardo |
Wed, May 16 2007 9:27 AM | Permanent Link |
Dan Rootham | 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 |
Wed, May 16 2007 9:41 AM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Wed, May 16 2007 10:01 AM | Permanent Link |
"Harry de Boer" | 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 > > |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |