Hi,

when do you think you'll have a Delphi 2009 version of DBISAM?

Will this version be unicode ready?

Regards
Mathias

Mathias,

<< when do you think you'll have a Delphi 2009 version of DBISAM? >>

After ElevateDB 2.02 is released, so at least until the end of September.

<< Will this version be unicode ready? >>

No.  Only ElevateDB supports Unicode, and DBISAM will always be ANSI-only.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

It sounds like a great opportunity for DBISAM 5.x.

I have both ElevateDB, and DBISAM.... and sometimes, DBISAM is a quick and
easy product fit..... and if I could upgrade some stuff to DBISAM with
unicode it would be a nice thing to do... (This is hard to say before seeing
what 'really' is involved with moving a project to D2009.

Please consider DBISAM 5.

BTW... I was at the Toronto, D2009 event and I am sorry I didn't know you
were there... I would have introduced myself....

Walter Matte


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:2FFBF2FE-3F6B-4016-B6AD-298A37B6F60C@news.elevatesoft.com...
> Mathias,
>
> << when do you think you'll have a Delphi 2009 version of DBISAM? >>
>
> After ElevateDB 2.02 is released, so at least until the end of September.
>
> << Will this version be unicode ready? >>
>
> No.  Only ElevateDB supports Unicode, and DBISAM will always be ANSI-only.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Walter,

<< It sounds like a great opportunity for DBISAM 5.x.

I have both ElevateDB, and DBISAM.... and sometimes, DBISAM is a quick and
easy product fit..... and if I could upgrade some stuff to DBISAM with
unicode it would be a nice thing to do... (This is hard to say before seeing
what 'really' is involved with moving a project to D2009.

Please consider DBISAM 5. >>

We've had this discussion before here on the newsgroups, and the main
problems with such a beast are that it ends up just recreating most of what
is already present in ElevateDB.  Given our resource constraints here, we
cannot afford to spend several months recreating the work that went into
ElevateDB in DBISAM also.  Making DBISAM Unicode-capable would mean
effectively rewriting a large portion of it.

<< BTW... I was at the Toronto, D2009 event and I am sorry I didn't know you
were there... I would have introduced myself.... >>

Same here - I'm sorry that we didn't get a chance to meet.  I believe that
TDUG wants me to do a presentation sometime in the fall, however, so we can
certainly arrange to meet at that time.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote
> Please consider DBISAM 5. >>
Hi Tim,
I'm still on Dbisam4 and was thinking "heck, it's probably a good time to
move to ElevateDB". I want Unicode - that's why I'm eager for D2009.
But is migrating to ElevateDB a big deal?  I'm wondering if it is, otherwise
why the talk of DBISAM 5?
Fortunately, I've encapsulated all of my database calls into one unit, with
an oop layer that retrieves/stores my objects for me, and the re-write will
likely be confined to that layer.
But is it going to make a big difference to my footprint or deployment?
BTW, the app in question is ClipMate, a popular clipboard extender that runs
on desktops and flash drives.
--
Chris

Chris,

<< I'm still on Dbisam4 and was thinking "heck, it's probably a good time to
move to ElevateDB". I want Unicode - that's why I'm eager for D2009. But is
migrating to ElevateDB a big deal?  I'm wondering if it is, otherwise why
the talk of DBISAM 5? >>

It is not a simple task, no.  However, it also depends upon how much you
used the code-based DDL in DBISAM (TDBISAMTable CreateTable, AlterTable,
etc. methods) vs. SQL.  If you used the code-based DDL, then it is a bit of
a switch due to the fact that EDB uses SQL for all of that.  However, you
can migrate your DBISAM database over to EDB very quickly and then do a
reverse-engineer to generate all of the SQL code that you need.

Apart from that, the other big thing to get used to is the new file
organizations, especially the configuration and catalog files, which are new
for local applications (DBISAM C/S already used a configuration file).
However, on the flip side you can now move a local app to C/S and back with
virtually zero changes to the code.

<< Fortunately, I've encapsulated all of my database calls into one unit,
with an oop layer that retrieves/stores my objects for me, and the re-write
will likely be confined to that layer. >>

It is going to be a lot easier for you due to that design.

<< But is it going to make a big difference to my footprint or deployment?
>>

The footprint may be slightly larger, but not by much.  EDB is still very
trim.  The EDB Server is around 1.9 megs in size.

<< BTW, the app in question is ClipMate, a popular clipboard extender that
runs on desktops and flash drives. >>

You might be interested in checking out the upcoming Free Pascal support for
EDB that will target Windows/Windows CE/Mobile.  You could do a native
ClipMate for Windows CE/Mobile, which would be neat.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:A6459CEE-C4B6-4082-8A70-
> It is not a simple task, no.  However, it also depends upon how much you
> used the code-based DDL in DBISAM (TDBISAMTable CreateTable, AlterTable,
> etc. methods) vs. SQL.
It's not too bad - I use the reverse-engineered stuff to create my tables.
Aside from that, prior to logon I have some AlterTable statements to do some
tweaks to older versions of the tables.
ex:  if mytable.version < 2.2 then
          alter mytable add new column, make another column wider, etc..
change version to 2.2
Just the normal kind of crud that takes place over time.
So my strategy may be to have a migration utility to move the data over to
the EDB.  I've got an import/export XML feature, and I could leverage that
(export everything to XML using the old table structure, then just suck it
into the new EDB-based version.   I've got something like this now for
moving from my really old flat-file database (pre-DBISAM). It just converts
the old crud to XML, then I can import into the current version.

> If you used the code-based DDL, then it is a bit of a switch due to the
> fact that EDB uses SQL for all of that.  However, you can migrate your
> DBISAM database over to EDB very quickly and then do a reverse-engineer to
> generate all of the SQL code that you need.

Sounds good. Sounds like I'd be basically starting fresh, with no DDL needed
aside from the reverse-engineered portion.

> << BTW, the app in question is ClipMate, a popular clipboard extender that
> runs on desktops and flash drives. >>
>
> You might be interested in checking out the upcoming Free Pascal support
> for EDB that will target Windows/Windows CE/Mobile.  You could do a native
> ClipMate for Windows CE/Mobile, which would be neat.

Hmmm. Nice.
--
Chris

Chris,

<< It's not too bad - I use the reverse-engineered stuff to create my
tables.
Aside from that, prior to logon I have some AlterTable statements to do
some tweaks to older versions of the tables.
ex:  if mytable.version < 2.2 then
          alter mytable add new column, make another column wider, etc..
change version to 2.2
Just the normal kind of crud that takes place over time. >>

Okay, you can still keep this kind of logic, but you'll have to replace the
method calls with calls to query the system information tables instead:

http://www.elevatesoft.com/manual?action=mantopic&id=edb2&product=d&version=7&category=4&topic=14
http://www.elevatesoft.com/manual?action=mantopic&id=edb2&product=d&version=7&category=4&topic=10

<< So my strategy may be to have a migration utility to move the data over
to the EDB.  I've got an import/export XML feature, and I could leverage
that (export everything to XML using the old table structure, then just suck
it
into the new EDB-based version.   I've got something like this now for
moving from my really old flat-file database (pre-DBISAM). It just converts
the old crud to XML, then I can import into the current version. >>

Sure, that will work.  Our migration facilities will do the same thing for
you, however, without requiring you to do anything other than setting up the
migrator:

http://www.elevatesoft.com/manual?action=mantopic&id=edb2sql&category=0&topic=14

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tom,

Is it possible to make a version of DBISAM which works under D2009 but
without the Unicode abilities. i.e. we will be able to use it as long as we
don't go beyond Ansi character set.

Farshad,

<< Is it possible to make a version of DBISAM which works under D2009 but
without the Unicode abilities. i.e. we will be able to use it as long as we
don't go beyond Ansi character set.  >>

Yes, we will be doing a version of DBISAM for Delphi 2009.

--
Tim Young
Elevate Software
www.elevatesoft.com