Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 12 total
Thread DBISam to ElevateDB
Wed, May 21 2008 3:22 AMPermanent Link

"Adam H."
Hi Tim,

If I recall correctly, I thought I saw you post somewhere a little while ago
(after the survey) that you didn't realise just how difficult merging from
DBISam to ElevateDB was going to be for some of us, and that it may have
altered your direction slightly as to how you were going to attack things.
(Hence the introduction of support subscription, etc).

I was just wondering if these plans included making some extra changes to
ElevateDB (introducing some legacy functions, etc) to make it easier for
DBISam'ers to port over, and if so - do you have a list of some of these
functions you were considering?

I'm curious to know whether future development of EDB will be only towards
new features, or if your roadmap includes introducing features that existed
in DBISam?

Thanks mate

Adam.
Wed, May 21 2008 4:11 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Adam


One thing that will definitely be making an entrance into 2.0 (hopefully soon) will be a reversion to emptystring = null

Roy Lambert
Wed, May 21 2008 9:11 AMPermanent Link

Optionally I hope.

/Matthew Jones/
Wed, May 21 2008 9:51 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Matthew


I have no idea. If I was developing ElevateDB (heaven forbid unless you like bugs and slow code) I'd have some switches in the engine.

Roy Lambert
Wed, May 21 2008 2:31 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Adam,

<< I was just wondering if these plans included making some extra changes to
ElevateDB (introducing some legacy functions, etc) to make it easier for
DBISam'ers to port over, and if so - do you have a list of some of these
functions you were considering? >>

I don't have a complete list ready yet, but yes, there are some things that
I'm looking into adding for making things like the NULL strings issue easier
on DBISAM porters.

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, May 21 2008 6:58 PMPermanent Link

"Adam H."
Hi Tim,

> I don't have a complete list ready yet, but yes, there are some things
> that I'm looking into adding for making things like the NULL strings issue
> easier on DBISAM porters.

Out of curiosity did you have any thoughts about introducing some DBISam
functions (such as select into's) into EDBQueries? Smile

Cheers

Adam
Wed, May 21 2008 8:44 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Adam,

<< Out of curiosity did you have any thoughts about introducing some DBISam
functions (such as select into's) into EDBQueries? Smile>>

SQL differences probably won't be addressed nearly as much as other
differences that are harder to work around with code and/or SQL changes.
The INTO clause, for example, can be replaced with a standard CREATE TABLE
AS SELECT statement.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, May 22 2008 3:25 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>SQL differences probably won't be addressed nearly as much as other
>differences that are harder to work around with code and/or SQL changes.
>The INTO clause, for example, can be replaced with a standard CREATE TABLE
>AS SELECT statement.

I almost agree with you. The difference is that DBISAM SELECT INTO overwrites the destination table if it exists ElevateDB CREATE TABLE AS does not thus requiring a check and drop of the destination table if it exists.

Roy Lambert
Thu, May 22 2008 6:23 AMPermanent Link

Fernando Dias

Team Elevate Team Elevate

Roy,

> I almost agree with you. The difference is that DBISAM SELECT INTO overwrites the destination table if it exists ElevateDB CREATE TABLE AS does not thus requiring a check and drop of the destination table if it exists.

Yes, but now we have new ways to do old things Smiley:
----------------------
begin
  execute immediate 'drop table Tbl2';
exception
end ;
execute immediate 'create table Tbl2 as (select * from Tbl1) with data';
-----------------------

Not so easy to type as IF EXISTS, but much powerful.
However, I'd vote for the return of the 'IF EXISTS' extension, at least
in DROP.

--
Fernando Dias
[Team Elevate]
Thu, May 22 2008 7:22 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Fernando

This (slightly modified from source supplied by Tim) is what I use:

SCRIPT (IN SQLStatement VARCHAR, IN TableName VARCHAR, IN IdxSet VARCHAR)
BEGIN     
DECLARE InfoCursor SENSITIVE CURSOR FOR InfoStmt;
DECLARE ResultCursor SENSITIVE CURSOR WITH RETURN FOR ResultStmt;

PREPARE InfoStmt FROM 'SELECT * FROM Information.Tables WHERE Name=?';
OPEN InfoCursor USING TableName;

IF (ROWCOUNT(InfoCursor) > 0) THEN
 EXECUTE IMMEDIATE 'DROP TABLE "'+TableName+'"';
END IF;

CLOSE InfoCursor;

PREPARE ResultStmt FROM 'CREATE TABLE "'+TableName+'" AS '+SQLStatement+' WITH DATA';
EXECUTE ResultStmt;

IF IdxSet IS NOT NULL THEN
 PREPARE ResultStmt FROM 'CREATE INDEX Idx ON "'+TableName+'"('+IdxSet+')';
 EXECUTE  ResultStmt;
END IF;
END

As you see I prefer to check if the table's there rather than use an exception and because the ORDER BY clause, unlike in DBISAM, doesn't affect the ordering of the result set I also (optionally) create an index.

ElevateDB is much more powerful than DBISAM but it is "different"


Roy Lambert
Page 1 of 2Next Page »
Jump to Page:  1 2
Image