Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 7 of 7 total |
Why only SQL for everything? |
Thu, Apr 24 2008 4:11 AM | Permanent Link |
Rob Fletcher | 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. |
Thu, Apr 24 2008 6:38 AM | Permanent Link |
QuickAndDirty | 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. |
Thu, Apr 24 2008 12:30 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Thu, Apr 24 2008 1:49 PM | Permanent Link |
Rob Fletcher | 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 |
Thu, Apr 24 2008 2:25 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Fri, Apr 25 2008 7:35 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Apr 25 2008 9:27 PM | Permanent Link |
Rob Fletcher | 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. |
This web page was last updated on Friday, May 3, 2024 at 08:07 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |