I admire your SQL enhancements in EDB and see them as very useful for some functions.
However I really miss the procedural equivalents.  Particularly the DDL and Administrative
statements.  They have so many enhancements and/or incompatibilities with standard SQL
that I don't see the advantage to using them.  Please consider providing procedural
equivalents for things like Alter and Exists.  Restructuretable was so much easier in
dbisam.  It's now very difficult to release an updated program with different table
structures.  I have to construct a very complex SQL Alter on the fly based on the old
structure.  Also very much miss the server procedures that we could compile into the
server.  If I have to learn a whole new language (EDB SQL Scripts) then it makes moving to
a more mainstream DB like sql express or firebird a big temptation. A big reason I still
use Delphi is its a native code compiler.  EDB is turning a big part of my programs into
interpreted scripts.

Rob Fletcher <robatpowerclock.com> wrote:

I admire your SQL enhancements in EDB and see them as very useful for some functions.
However I really miss the procedural equivalents.  Particularly the DDL and Administrative
statements.  They have so many enhancements and/or incompatibilities with standard SQL
that I don't see the advantage to using them.  Please consider providing procedural
equivalents for things like Alter and Exists.  Restructuretable was so much easier in
dbisam.  It's now very difficult to release an updated program with different table
structures.  I have to construct a very complex SQL Alter on the fly based on the old
structure.  Also very much miss the server procedures that we could compile into the
server.  If I have to learn a whole new language (EDB SQL Scripts) then it makes moving to
a more mainstream DB like sql express or firebird a big temptation. A big reason I still
use Delphi is its a native code compiler.  EDB is turning a big part of my programs into
interpreted scripts.


Hi Rob,
I felt like you. I wrote replacements. Others did that to and wrote replacements by
descanding TEDBTABLE

something like this

Function GetExistsTBL:Boolean;
var q:TEdbQuery;
Begin
   q := TEdbQuery.Create(nil);
   q.SessionName := MySession.SessionName;
   q.DatabaseName := TEDBTable(aDataset).Databasename;
   q.SQL.Add('Select Name From Information.Tables WHERE Name = ' +
Quotedstr(TEDBTable(aDataset).Tablename));
   q.Open;
   result := q.RecordCount > 0;
   q.close;
   q.Free;
end;

I also coded a big Method for Tablecreate, etc.
Yet nothing of this is testet.

Rob,

<< I admire your SQL enhancements in EDB and see them as very useful for
some functions. However I really miss the procedural equivalents.
Particularly the DDL and Administrative statements.  They have so many
enhancements and/or incompatibilities with standard SQL that I don't see the
advantage to using them.  Please consider providing procedural equivalents
for things like Alter and Exists. >>

I'm sorry, but we won't be doing so.  The support and documentation costs
alone are excessive with dual-mode options for every single function.
Furthermore, they don't work with ODBC drivers or ADO.NET data providers,
which was a *big* issue with DBISAM, and it would have been next to
impossible to implement functionality for constraints, triggers, etc.
without a large amount of changes from the way that you did it in DBISAM,
anyways.

<< Restructuretable was so much easier in dbisam.  It's now very difficult
to release an updated program with different table structures.  I have to
construct a very complex SQL Alter on the fly based on the old structure. >>

How is an ALTER TABLE any more complex than what you were doing in code ?  I
would say that it is much, much easier to understand and is documented
everywhere in SQL books, on the web, etc.  We're leveraging a huge existing
body of documentation by using SQL for things like altering a table.

<< Also very much miss the server procedures that we could compile into the
server. If I have to learn a whole new language (EDB SQL Scripts) then it
makes moving to a more mainstream DB like sql express or firebird a big
temptation. A big reason I still use Delphi is its a native code compiler.
EDB is turning a big part of my programs into interpreted scripts. >>

How much of your application is metadata management and administrative
functionality ?  My guess is that it isn't as large as you think.  And why
do you care if you use:

Session.Execute('REMOVE SERVER SESSION 100');

vs.

Session.RemoveServerSession(100);

?  The difference in execution time is so small as to be completely
irrelevant.

Also, you can code stored procedures and functions as native external
modules in EDB, with the only difference being that they're in a DLL:

http://www.elevatesoft.com/manual?action=mantopic&id=edb1sql&category=0&topic=13

In Delphi, just go into the object repository (File..New..Other in Delphi 7)
and you'll see a template project for this under the ElevateDB category
called "ElevateDB External Module".

And with all due respect, threatening to move to another database engine
does not help your argument in the least.  If you can't see the benefits of
EDB, which combines the best of DBISAM's navigational model with the best of
the SQL support, then you're really going to have a hard time with any other
database engine.  They're all SQL-based, with very little support for
navigational access at all.  You certainly can't use FindKey, SetRange,
filters, and other nice features in a native fashion.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for the explanation.  You're making it a lot easier for a non-Delphi user to use
EDB.  That makes perfect sense (and cents).  However, it seems like it would be easy for
you to expose the internal procedures that you use for 'alter table' and 'exists' for
example for us using Delphi.  There must be hundreds of questions on here about how to do
'exists' and 'alter table'.  

Just wondering, do you plan to require us to convert all TTable methods into SQL?  Does
EDB now convert things like First, Next into mini-sql calls?

Rob

Rob


If you look at my posts you'll see I've also ranted about various things. In my case it was  (mainly) the null <> emptystring problem and removal of IF EXISTS from DDL. The first is being addressed in V2 but the second will still be with us. The good news is there are ways round it.

I switched to using sql for table creation/alteration ages ago because it was so much simpler than the restructuretable method. Its a bit more complex now, but once you get your head round the concept that you now have 3 programming languages to play with (Pascal aka Delphi, SQL & SQL/PSM) and that they all do different jobs things start to fall into place.

>Just wondering, do you plan to require us to convert all TTable methods into SQL?

I think you'll find its pretty much DDL that's vanished from TEDBTable

> Does EDB now convert things like First, Next into mini-sql calls?

Interesting question. I'll be fascinated to learn, but at the end of it who cares?

Roy Lambert

Rob,

<< Thanks for the explanation.  You're making it a lot easier for a
non-Delphi user to use EDB.  That makes perfect sense (and cents). >>

Thank you for understanding - that is exactly what we've tried to do.  For
those that used DBISAM, most customers *loved* the code-based approach.  The
problem, however, was that it also turned off a lot of potential customers
because they didn't understand why they couldn't use more "standardized"
approaches in some cases.   This was especially the case with the ODBC
driver and those using non-Delphi environments.

<< However, it seems like it would be easy for you to expose the internal
procedures that you use for 'alter table' and 'exists' for example for us
using Delphi.  There must be hundreds of questions on here about how to do
'exists' and 'alter table'. >>

Well, if you have the EDB source code, you can look at how we do it natively
and do the same in your application.  Basically, each TEDB* component has a
native Handle property that gives you access to the internal object that we
use.

However, I will warn you in advance that the table alteration is fairly
tricky, especially with respect to constraints due to the amount of linkages
that are required in the database catalog.  Also, you can't use the native
methods with remote sessions, only with local sessions.  Remote sessions
only send over SQL for metadata manipulation.  This is another reason why we
switched to using SQL for this type of thing - we needed a remote method for
every single alter, drop, etc. operation in DBISAM.

<< Just wondering, do you plan to require us to convert all TTable methods
into SQL? >>

Absolutely not.

<< Does EDB now convert things like First, Next into mini-sql calls? >>

No.  EDB only goes the one way - SQL -> native.  It never does a native ->
SQL -> native cycle for any of the code.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for the explanation.  You've convinced me.   I just wish there was a more elegant
way to construct SQL statements inside Delphi.  Format(... will come in handy.  Your error
exception messages are quite clear so that helps.