Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 10 of 12 total |
DBISam to ElevateDB |
Wed, May 21 2008 3:22 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Optionally I hope.
/Matthew Jones/ | |
Wed, May 21 2008 9:51 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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? Cheers Adam |
Wed, May 21 2008 8:44 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< Out of curiosity did you have any thoughts about introducing some DBISam functions (such as select into's) into EDBQueries? >> 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Fernando Dias 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 : ---------------------- 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |