Rita,

<< 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. >>

Well, it was either hanging out in the computer room or joining the Aryan
brotherhood, and that was out of the question.

--
Tim Young
Elevate Software
www.elevatesoft.com

Jan,

<< 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? >>

No, it means that if you use the migration unit for the migration, then it
will want to (at least for now) link in version 4 to handle reading, and
possibly upgrading, the DBISAM tables to ElevateDB.  As I told Roy, I could
probably IFDEF the portions of code necessary to have it work with prior
versions.  It's a trivial piece of code, around 200 lines.

<< 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? >>

If you're asking for ElevateDB to natively read in prior versions like the
DBISAM upgrades did, then the answer is no.  It's a huge undertaking to
replicate all of the format reading, etc. for all 4 versions when a simple
compilation will do the trick and allow the migration unit to maintain its
adherence to using the TDataSet architecture, opening up the ability to
migrate from other database engines.  DBISAM 4.x and prior versions had all
sorts of bugs in the upgrade code that came from trying to reinvent the
wheel like that.  The ElevateDB manager is about 800k larger than DBSYS with
both ElevateDB and DBISAM V4 linked in, so the difference is negligible to
the resulting .EXE.

<< 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) >>

As I indicated above, it should be possible to add in support for migrating
versions 1, 2, and 3 in the migration unit.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ralf,

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

Well, if you would like to skip the TDataSet stuff and go directly to the
engine, you can do so very easily with ElevateDB and have a very fast and
lean, 100% OO DB.   It's really pretty cool, and the coding is very simple.

--
Tim Young
Elevate Software
www.elevatesoft.com

Changes in ElevateDB from DBISAM v4

Besides common tasks to migration like:
- Upgrade the database
- Change code to fit the new file extentions (.EBDAT, .EBIDX, .EBBLB)
- Some fits to new parameters at some table/query methods
- another little stuffs

Is there another thing with impact ?

Eduardo

Tim Young [Elevate Software] wrote:
> Well, if you would like to skip the TDataSet stuff and go directly to
> the engine, you can do so very easily with ElevateDB and have a very
> fast and lean, 100% OO DB.   It's really pretty cool, and the coding
> is very simple.

Interesting. Does it look LINQish?

Tim Young [Elevate Software] wrote:
> Rita,
>
> << 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. >>
>
> Well, it was either hanging out in the computer room or joining the Aryan
> brotherhood, and that was out of the question.
>
Tim;
 might as well get my name published. HiYa. Can't wait for v5
yeepeeeeeeee!!!

sitting next to Lake Ainslie, CB (near Inverness, the one in Canada )

Allan B

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in =
bericht =
news:414AC4FA-6636-45E4-8418-3EBAFC05E5BC@news.elevatesoft.com...
> Mark,
>=20
> << Wow! Big change. I wasn't expecting something this fundamental >>
>=20
> It's essentially a different product line, so it tends to be quite =
different=20
> in some areas.  ElevateDB is our product for the next 7 years, while =
DBISAM=20
> was our product for the last 7 years.
>=20

Tim,

 So the DBISAM product line wil be no further developed when ElevateDB =
is ready?
 Wil there be a feature matrix between DBISAM and ElevateDB, so we can =
easely see the differences?

Henri Maas

Dom,

<< Interesting. Does it look LINQish? >>

No, nothing like that.  Just a bunch of objects representing the engine,
sessions, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Eduardo,

<< Besides common tasks to migration like:
- Upgrade the database
- Change code to fit the new file extentions (.EBDAT, .EBIDX, .EBBLB)
- Some fits to new parameters at some table/query methods
- another little stuffs

Is there another thing with impact ? >>

You shouldn't need to do anything with respect to file extensions with
ElevateDB.  The table/catalog files are virtually invisible as far as your
application is concerned - you never deal with them directly in any way.
You simply reference database and table identifiers that are in the catalog.

As for your question - besides what I've already mentioned in terms or
CreateTable, AlterTable, etc. being gone, the other biggest change would be
the SQL-based triggers, stored procedures, functions, and jobs (scheduled
events).  These were all done in DBISAM in code, and will need to be ported
to SQL code to work with ElevateDB.

--
Tim Young
Elevate Software
www.elevatesoft.com

Allan,

<< might as well get my name published. HiYa. Can't wait for v5
yeepeeeeeeee!!!

sitting next to Lake Ainslie, CB (near Inverness, the one in Canada ) >>

Have a beer for me !!!

--
Tim Young
Elevate Software
www.elevatesoft.com