Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 1 to 10 of 30 total |
Can I propose DBISAM 5? |
Tue, Jan 29 2008 11:01 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jan 30 2008 4:03 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
Are you referring to me here Roy Lambert |
Wed, Jan 30 2008 6:24 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 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 . 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 PM | Permanent Link |
Thanks - I've printed that for reading.
/Matthew Jones/ | |
Wed, Jan 30 2008 2:21 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Are you referring to me here >> No, if it was just you I wouldn't bother. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jan 30 2008 2:25 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 . >> Yep, a debugger is definitely in the cards. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jan 31 2008 3:14 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 3 | Next Page » | |
Jump to Page: 1 2 3 |
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 |