Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 30 total
Thread Can I propose DBISAM 5?
Tue, Jan 29 2008 11:01 AMPermanent Link

Tim,

Can I propose DBISAM 5 please? Seriously. But not straight away.
I've been reading some of the blogs from Codegear on the Unicode Tiburon
coming down the tracks and it struck me that while I have ElevateDB, I
have a lot more experience with DBISAM (1, 3 & now 4). I'll be needing
DBISAM for the Unicode compatibility, and for the Win64 support when that
comes too. But it would be unreasonable to ask for this to be added to
DBISAM 4 since that is in a cooling period for you. What I'd like
therefore it to be able to pay for an upgrade to a version 5 of DBISAM,
the only new features of which would be to support whatever CodeGear give
us in the next year or two. It's only fair that you get financial reward
for the effort needed. Those who don't want it can stick on v4. Those who
want the full new features and a more advanced database will get it with
ElevateDB.

Thanks for thinking about it. (I'm sure others will add their thoughts
too!)

/Matthew Jones/
Tue, Jan 29 2008 3:44 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< Can I propose DBISAM 5 please? Seriously. But not straight away. I've
been reading some of the blogs from Codegear on the Unicode Tiburon coming
down the tracks and it struck me that while I have ElevateDB, I have a lot
more experience with DBISAM (1, 3 & now 4). I'll be needing DBISAM for the
Unicode compatibility, and for the Win64 support when that comes too. But it
would be unreasonable to ask for this to be added to DBISAM 4 since that is
in a cooling period for you. What I'd like therefore it to be able to pay
for an upgrade to a version 5 of DBISAM, the only new features of which
would be to support whatever CodeGear give us in the next year or two. It's
only fair that you get financial reward for the effort needed. Those who
don't want it can stick on v4. Those who want the full new features and a
more advanced database will get it with ElevateDB. >>

I've thought about it, mainly because some customers are having a heck of a
time getting their heads around EDB.  However, every time I start looking
into it further it starts to turn into EDB again very quickly.  Once you
start having to put in Unicode support and the other types of architecture
changes, you start getting into some serious amounts of work, most of which
has already been done with EDB.  The real issue is that I don't think that
replicating a large chunk of the work done for EDB in a DBISAM 5 is worth
the effort.  I could be wrong, though. Smiley

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Jan 30 2008 4:03 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


Are you referring to me here Smiley

Roy Lambert
Wed, Jan 30 2008 6:24 AMPermanent Link

I did wonder, after posting, what I'd actually want of it too. The main
thing would be that both a Delphi 7 app and a Delphi 2009 app should be
able to access the same database without caring. I'd be happy with the D7
app not being able to take advantage of all the field types, but also it
should not care about conversions needed (e.g. if a field is Unicode, it
would just use Field.AsString := 'Hello mum' as normal. Yes, it may trash
some code points.

But then again, maybe you are right - if EDB has all that is needed
already then it is perhaps time to move anyway. But DBISAM is a
comfortable and reliable pair of slippers in my work now, and those new
EDB ones look sharp and pointy with all that new SQL needed for that
catalog stuff. How is the documentation now? Is there a EDB for Dummies
yet?

/Matthew Jones/
Wed, Jan 30 2008 8:08 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Matthew


Documentation is pretty good. Its been beefed up on the differences with DBISAM which I think helps.

SQL for the catalog (and the catalog itself) isn't bad especially now Tim has built the history function in so you can capture the sql output of using his ui for table creation etc. I switched to using sql for creating tables indices etc some time back so that helps. Debugging scripts is fun though.

The biggest problems for me have been the "lost toys".

First let me emphasise that I'm not passing any judgements either way about these issues. The fact that I'd like to introduce a blunt object to the standard setters heads is totally immaterial Smiley

NULL = ''
With ElevateDB null is no longer the same as an empty string. I'm altering any instances of flield.AsString := '' to field.Clear also setting up a before post trigger to ensure any where users delete the contents of a varchar or char field it gets set to null. Finally checking all my sql for  = '' test and altering to = NULL. Its a lot of work and checking (not done yet) but with the exception of my query generator where I'll have to use both forms of test (= '' for string fields and IS NULL for all others) that's all it is.

There are implications for calculations (I think V4 does it "correctly") and joining fields in sql. I posted a reference to Firebirds 51 page manual if you want to do further research.

Truncating assignments to fit VARCHARs
Since I rarely use sql for data input update and Delphi still trims fields this isn't a significant problem, as long as CodeGear don't change their code. At some point I may add tests for length of data before its applied to a varchar field but the effort seems enormous.

Editable canned queries
I'm switching to in-memory tables. Temporary tables would be another alternative but they appeared after I started the conversion and an in-memory table has the benefit of guaranteed cleanup even in the event of a crash.

SELECT INTO
Replaced by CREATE TABLE AS. The two main issues are that you will have to deal with ensuring the table to be created doesn't already exist (select into zapped it for you) and that the ORDER BY clause isn't permitted in the select clause so you have to create any ordering you want. The final bit is the difference in the way DBISAM and ElevateDB treat in-memory tables. With DBISAM you set the query's database to the disk based tables and specified memory for the destination in-memory table. With ElevateDB its the other way round you set the query's database to the memory database and specify the database for the disk based tables.

TEXTSEARCH
Almost replaced by CONTAINS. The lacking bit is that CONTAINS only works on indexed fields. I have it planned to write my own TEXTSEARCH replacement for non-indexed columns.

Simple Scripts
I'll be converting these to a mixture of edbscripts, pascal plus sql and simple looping round a ; separated list throwing it at a query which is what DBISAM does

REDEFINE
Almost replaced by ALTER. I'm hoping (but doubtful) Tim will deliver the missing ability to rename a column.

IF EXISTS
This is lost, gone forever, and much lamented. There are ways round it using scripts but to me they all feel clumsier.

If I had to sum it up for me from my experience so far it would be DBISAM simple, well known and easy to use ElevateDB more powerful, faster (for me one of the drivers for changing is the speed improvement in full text indexing) but feels more clumsy and more work to achieve things. The latter will ease as ElevateDB becomes more familiar but my current belief is that for the things I'm used to using ElevateDB will in several cases take more typing than DBISAM. For others (and me in the future) the situation may be reversed.

Overall I still think I made the right decision (to convert) but I've lost count of the times I've thought about just switching back. My advice to anyone converting an app would be - look at your code, decide which of the DBISAM goodies you have used and how they should be handled in DBISAM then write little test apps for test in EDBManager (by then Tim might have the debugger written Smiley.

Finally before I started converting I wrote a little app with ElevateDB from scratch. After overcoming the "catalog, what is a catalog" problem and how to point at my tables (look at Tim's CD collector example) it was easy.

Sorry for the long rambling post and I know its no dummy's guide but I hope it helps.

Roy Lambert
Wed, Jan 30 2008 12:00 PMPermanent Link

Thanks - I've printed that for reading.

/Matthew Jones/
Wed, Jan 30 2008 2:21 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Are you referring to me here Smiley>>

No, if it was just you I wouldn't bother. Smiley

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Jan 30 2008 2:25 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< I'll be converting these to a mixture of edbscripts, pascal plus sql and
simple looping round a ; separated list throwing it at a query which is what
DBISAM does >>

Remember - there's a simple TEDBScript method that does the basic conversion
of a semi-colon delimited list of statements into an EDB script.

<< REDEFINE
Almost replaced by ALTER. I'm hoping (but doubtful) Tim will deliver the
missing ability to rename a column. >>

Yep.

<< Overall I still think I made the right decision (to convert) but I've
lost count of the times I've thought about just switching back. My advice to
anyone converting an app would be - look at your code, decide which of the
DBISAM goodies you have used and how they should be handled in DBISAM then
write little test apps for test in EDBManager (by then Tim might have the
debugger written Smiley. >>

Yep, a debugger is definitely in the cards.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Jan 31 2008 3:14 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>Remember - there's a simple TEDBScript method that does the basic conversion
>of a semi-colon delimited list of statements into an EDB script.

I thought about that, but I wanted to emulate the IF EXISTS for dropping tables so I did my own.

Roy Lambert
Thu, Jan 31 2008 5:30 AMPermanent Link

Thanks for that. It seems to have moved a little closer to the MS SQL
Server style of doing things - that is, more complicated. But the nice
thing is that there are lots of trailblazers who are getting the arrows in
their backs who can provide the answers when I come by this way. I hope
someone is building an FAQ somewhere for some of these things.

/Matthew Jones/
Page 1 of 3Next Page
Jump to Page:  1 2 3
Image