Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 21 total |
How to delete a table using TEDBTable? |
Thu, Aug 20 2009 12:42 PM | Permanent Link |
Brent | I was a little surprised this morning to discover TEDBTable.DeleteTable missing as well as
TableExists. I can easily replace TableExists with a routine that attempts to open the table, but how do I replace DeleteTable? I am using only tables and do not want to use SQL. TIA Brent |
Thu, Aug 20 2009 1:07 PM | Permanent Link |
"Terry Swiers" | Brent,
>I was a little surprised this morning to discover TEDBTable.DeleteTable >missing as well as > TableExists. I can easily replace TableExists with a routine that attempts > to open the > table, but how do I replace DeleteTable? I am using only tables and do not > want to use SQL. The function simply no longer exists, so you will have to use SQL. To make things easy on yourself, you can create function wrapper such as this in a global unit to allow you to pass a TEDBTable to drop the table from the database and your code changes will be minimal. function DeleteTable(aTable : TEDBTable) : Boolean; begin Result := False; with TEDBQuery.Create(nil) do begin DatabaseName := aTable.DatabaseName; SessionName := aTable.SessionName; SQL.Text := 'drop table ' + QuotedString(aTable.TableName,'"'); try ExecSQL; Result := True; except end; Free; end; end; -- --------------------------------------- Terry Swiers Millennium Software, Inc. http://www.1000years.com http://www.atrex.com Atrex Inventory Control/POS - Big business features without spending big business bucks! Atrex Electronic Support Options: Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp Email: mailto:support@atrex.com Newsgroup: news://news.1000years.com/millennium.atrex Fax: 1-925-829-1851 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific) --------------------------------------- |
Thu, Aug 20 2009 2:50 PM | Permanent Link |
Brent | Terry,
Thanks for the solution. Unfortunately the TEDBTable.CreateTable is also missing so it looks like I'm forced to use SQL after all. Sigh. Brent |
Fri, Aug 21 2009 3:51 AM | Permanent Link |
"Iztok Lajovic" | Brent,
I had the same problem and therefore I made a program that in some way overrides this problem. Please look in the ..elevatdb.extensions newsgroup where you can find item Reverse-Engineer to Pascal code. Maybe you can find there some ideas for solution of your problem. Regards Iztok Lajovic "Brent" <bdgridly@mailbolt.com> je napisal v sporočilo news:96174D45-FED8-4D5F-B6EE-0A6A867ADD96@news.elevatesoft.com ... > Terry, > Thanks for the solution. Unfortunately the TEDBTable.CreateTable is > also missing so it > looks like I'm forced to use SQL after all. Sigh. > > Brent > |
Fri, Aug 21 2009 3:54 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Brent
You'll find all of the management routines are "missing" from TEDBTable eg optimise, repair, validate (gone totally), create, alter, delete. Your choices are 1) learn SQL or 2) learn SQL, subclass the table component, and forget SQL You'll also find a few other differences as well such as null <>'' and fields are no longer TRIMed before storage. I subclassed TEDBTable to do what I want and the result is in the extensions ng Roy Lambert |
Fri, Aug 21 2009 11:06 AM | Permanent Link |
Brent | Roy & Iztok Lajovic,
Well, actually I know a bit about SQL because that's all I use in another one of my projects using a different db product. It's just that I thought it would be more straightforward to use a table. SQL always has its variations that is a pain to sort out when moving from one product to another. I figured TEDBTable was TTable compatible, but unfortunately I was wrong. I took a quick look at EDB's SQL yesterday and was somewhat dismayed they don't have "IF EXISTS" clause like other SQL dialects do. How do you get around this if you want to code just in SQL? I know I can jump down to Delphi code and do the check there and then jump back to SQL, but it won't be fluid SQL code. I'm used to writing anywhere from 10 to 50 lines of SQL statements and submitting them in a batch. The SQL will know if tables or indexes are missing and will rebuild them automatically using conditional SQL code. But with EDB it looks like the "IF EXISTS" is now has to rely on alternate code stored someplace else. I suppose I could create a stored procedure but that too seems to be a bit or work just to see if a table already exists. Any suggestions? Tim has all of the database structure stored in tables which is a great idea, so I can't see why he can't extend his SQL to implement the "IF EXISTS" phrase for SQL and make it easier to people to import their SQL from other databases. Just some random thoughts. Brent |
Fri, Aug 21 2009 11:26 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Brent,
<< I took a quick look at EDB's SQL yesterday and was somewhat dismayed they don't have "IF EXISTS" clause like other SQL dialects do. How do you get around this if you want to code just in SQL? >> You can use scripts in EDB to do so, which support branching, looping, variables, etc. If you do a search on IF EXISTS in this newsgroup, you will find out the information that you need. Here's one of the threads on this: http://www.elevatesoft.com/newsgrp?action=openmsg&group=16&msg=8882&page=1#msg8882 -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Aug 21 2009 11:37 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Brent
Its one of the things I miss as well. Roy Lambert |
Fri, Aug 21 2009 11:53 AM | Permanent Link |
Brent | "Tim Young [Elevate Software]" wrote:
Here's one of the threads on this: http://www.elevatesoft.com/newsgrp?action=openmsg&group=16&msg=8882&page=1#msg8882 Tim, Thanks for the link. Scripts do appear to be quite powerful. But don't you think it would be easier for developers to move from other databases to EDB if EDB had implemented "IF EXISTS" directly into the SQL code? It would be less work for the developer rather than tearing apart their existing SQL code and replacing them with scripts? It would also make the SQL a lot easier to read, IMHO. Brent |
Mon, Aug 24 2009 12:38 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Brent,
<< Thanks for the link. Scripts do appear to be quite powerful. But don't you think it would be easier for developers to move from other databases to EDB if EDB had implemented "IF EXISTS" directly into the SQL code? It would be less work for the developer rather than tearing apart their existing SQL code and replacing them with scripts? It would also make the SQL a lot easier to read, IMHO. >> IF EXISTS only makes sense if you're talking about singleton SQL statements, or scripts that are simply a series of SQL statements separated by semicolons (ala DBISAM). Since you can do conditional execution of statements in both Delphi code and EDB SQL scripts, IF EXISTS becomes redundant. -- Tim Young Elevate Software www.elevatesoft.com |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |