> then having to port ALL my applications at one time is daunting. It would be
> nice to be able to install EDB with DBISAM, play with it a while and then
> port as necessary and when time permits.

If you're using BDS2005/2006 check out the possibility of differen
configuration registry roots. If you're using D3 to D7 then you can take a
look at my simple Delphi starter at www.nexusdb.com/downloads/jasps.zip. It's
in no way fancy or a professional tool but does it's job here since years.

--

Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm

Jan,

<< Will I be able to easily convert DBISAM 2 tables to ElevateDB? While I
own licenses for all DBISAM versions I still have a large amount of tables
in DBISAM 2 format and I would really like to upgrade to ElevateDB. >>

Yes, but they require an upgrade to 4.x first (the ElevateDB migration uses
4.x only).  There's an option in the migration component, and in the
ElevateDB manager, to do the upgrade, if necessary, before the migration.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mark,

<< Wow! Big change. I wasn't expecting something this fundamental >>

It's essentially a different product line, so it tends to be quite different
in some areas.  ElevateDB is our product for the next 7 years, while DBISAM
was our product for the last 7 years.

<< My datamodules perform creation/verification on all my tables during
FormCreate. I've built them for years this way, beginning with 1.21. I did
it this way because the help showed this as an example and it was elegant. I
know how to do it using SQL, but building a SQL command string is so
in-elegant (and much more work) compared to
"wrkTable.FieldDefs.Add('wrkField',ftString,20,false)",
"wrkTable.VerifyTable",  "wrkTable.OptimizeTable",
"wrkTable.RepairTable", "wrkTable.AlterTable",
"wrkTable.IndexDefs.Add('','wrkField',[ixPrimary])" etc. >>

Not really, considering that you don't need to create/make available a
TDBISAMTable component to use the SQL versions of most of them.  Just use
something like this instead:

MyEDBDatabase.Execute('REPAIR TABLE MyTable....');

The CREATE TABLE statement requires a bit more work than that, but it's the
same as using FieldDefs.Add(), instead you'll use SQL.Add() to add a new
line to the SQL statement.

<< I like SQL as much as the next guy for querying and updating my data, but
for table maintenance (in my opinion) its a PITA. Is there a reason for
doing away with these methods? >>

Because they required us to try and bend the base TDataSet architecture
farther than it was able to go, thus leading to compatibility issues with
other 3rd-party products such as InfoPower.  There's just no good way to
allow for the code-based versions, complete with column and table
constraints, etc. given the TDataSet architecture.  In addition, it was
twice as much work in terms of the documentation and support of the product.
Having only one way of doing things makes the product simpler to use and
more standardized.

<<  I know its late in the game and I've probably missed your telling the
group about this change before, but is there any way to get you to change
your mind and put code methods back in? Pretty please? >>

I hadn't publicly indicated it before, so you didn't miss it.  As for
changing my mind, no, I'm sorry.  A code-based CREATE TABLE or ALTER TABLE,
complete with constraints, would be a nightmare to contemplate.  And we
haven't even discussed trigger/function/procedure creation, which would be
another nightmare.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< I expect much more "surpizes" than he's currently telling to us. >>

You're a wise man.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ralf,

<< I see no problem to write some functions that can emulate these calls.
I'll try to write some and put them on .binaries as soon as ElevateDB is
out. >>

Indeed, it is very easy to write your own object wrappers around the SQL
text generation.  We even do it in the ElevateDB manager.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mark,

<< Actually, after I wrote my email, I thought about the same thing.
However, until we see the final product, it isn't much more than
thoughtware. >>

If you adhere to the SQL standard for CREATE TABLE, ALTER TABLE, etc. for
doing the wrapper code, you could start today and it would work with the
ElevateDB SQL perfectly when it is available.

<< Also Tim, since EDB is changing so much, can DBISAM and EDB be installed
simultaneously? >>

Absolutely.  It is a different set of components, units, etc. and can be
installed right along with DBISAM.

<< The thought of having to uninstall DBISAM, install EDB and then having to
port ALL my applications at one time is daunting. It would be nice to be
able to install EDB with DBISAM, play with it a while and then port as
necessary and when time permits. >>

Yes, I've done this very thing through 3 DBISAM upgrades (switch back and
forth), and wasn't about to do it for a whole year with ElevateDB.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:0BF578F0-F1C8-4E5A-AF3C-C85A4F5C4650@news.elevatesoft.com...
>
> Finally, I can't give a date yet for the actual release, but I will do so
> as soon as I can say it with 100% confidence in its accuracy.
>

Is that what the Warden told you Tim, I had no idea you was in the joint.
I think its great what they teach you guys in there all that code stuff.
Good luck with your release.
Rita

tnks.

"Jason Lee" <computerguy@wavecable.com> ha scritto nel messaggio
news:4BF54788-2E19-4360-80FE-627A5FA6532F@news.elevatesoft.com...
> Davide,
>
> There hasn't even been a beta test yet (at least publicly available), so 1
> week or even 1 month are probably a little soon.
>
> Regards,
>
> Jason Lee
>
> Davide wrote:
>> ok for VCL/Win32 first.. but when approx ?? 1 week, 1 month, 6 month ??
>> thanks
>> Davide.
>>

Tim Young [Elevate Software] wrote:

> << Will I be able to easily convert DBISAM 2 tables to ElevateDB?
> While I own licenses for all DBISAM versions I still have a large
> amount of tables in DBISAM 2 format and I would really like to
> upgrade to ElevateDB. >>

> Yes, but they require an upgrade to 4.x first (the ElevateDB
> migration uses 4.x only).  There's an option in the migration
> component, and in the ElevateDB manager, to do the upgrade, if
> necessary, before the migration.

One of my applications using DBISAM 2 tables is widely spread. A new
version must upgrade DBISAM 2 tables automatically to EvelateDB tables.
Does that mean I have use DBISAM 4 to upgrade to DBISAM 4 and then use
ElevateDB to upgrade from DBISAM 4 to Elevatesoft?

Keeping my application as lean as possible, I rather not link in DBISAM
4 only to upgrade the data structure. Buying ElevateDB would be way
more enticing to me if it would handle data upgrades from DBISAM 2. Any
chance you would add such a module?

Plus DBISAM 2 or 3 users wanting to upgrade to ElevateDB seem to be
left in the cold as there is no way for them to upgrade their tables to
ElevateDB. Or am I mistaken here? (I sure hope I am)

Jan Derk

Tim Young [Elevate Software] wrote:
> Michael,
>
> << I expect much more "surpizes" than he's currently telling to us.
> >>
>
> You're a wise man.

Do we get a 100% OO DB? I hope not

Ralf