Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 21 total
Thread How to delete a table using TEDBTable?
Thu, Aug 20 2009 12:42 PMPermanent 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 PMPermanent 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 PMPermanent 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. Surprised

Brent
Fri, Aug 21 2009 3:51 AMPermanent 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. Surprised
>
> Brent
>
Fri, Aug 21 2009 3:54 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 Smiley

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 AMPermanent 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. Smile

Brent
Fri, Aug 21 2009 11:26 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Brent


Its one of the things I miss as well.

Roy Lambert
Fri, Aug 21 2009 11:53 AMPermanent 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. Smile

Brent
Mon, Aug 24 2009 12:38 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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. Smile>>

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 3Next Page »
Jump to Page:  1 2 3
Image