I have an existing application and existing database written in Delphi
2006 using EDB 2.x (non-unicode) and is in active use by a client.

I have just acquired Delphi 2009 and am considering upgrading all
applications to the latest, but realize there will be some changes and
considerations when moving from ANSI strings/database to Unicode.

Aside from the Delphi code changes that are necessary, is it
possible/easy to upgrade an ANSI EDB database to Unicode EDB?  Can I
just backup the ANSI and restore from Unicode manager?  Or will I need
to extract all the data to SQL INSERT statements (reverse engineer) and
recreate it with the Unicode version?

It's still purely Win32, right?  No .NET involved?

Any recommendations for or against this?


Thanks,

--
David Cornelius
CorneliusConcepts.com

David,

It's Win32, no .net involved - the problem is you can't have both ANSI
and Unicode versions installed at the same time so as far as I know the
best way is indeed to use reverse engineering.

--
Fernando Dias
[Team Elevate]

> It's Win32, no .net involved - the problem is you can't have both
> ANSI and Unicode versions installed at the same time so as far as I
> know the best way is indeed to use reverse engineering.

No .NET--that's good to know.  Thanks.

Can't have both installed simulatenously?  Why not?  EDB Mgr is just an
..EXE and as long as they point to two different
configuration/catalog/database sets, one wouldn't know about the
other--I would think.

It might get a little trickier running two database servers from
services, but as long as you configured them from separate folders to
point to different databases, that should work as well.

I haven't tried this yet--so am thinking out loud here...

--
David Cornelius
CorneliusConcepts.com

David,

> Can't have both installed simulatenously?  Why not?  EDB Mgr is just an
> .EXE and as long as they point to two different
> configuration/catalog/database sets, one wouldn't know about the
> other--I would think.

I mean simultaneously installed in Delphi so that you can migrate
databases from your own application. I was thinking in therms of a
single application capable of reading the ANSI database and
creating/writing the new Unicode Database - that doesn't seem to be doable.

> It might get a little trickier running two database servers from
> services, but as long as you configured them from separate folders to
> point to different databases, that should work as well.
>
> I haven't tried this yet--so am thinking out loud here...

I haven't tried that also, but what about the client application? How
will you build the application - using the ANSI or the Unicode version?

The only way I can imagine at the moment is to add a feature to the
current ANSI version of your application to export databases using
reverse engineering (or build an export utility using ANSI) and then
include an "import" function in the new Unicode application.

--
Fernando Dias
[Team Elevate]

David

>Aside from the Delphi code changes that are necessary, is it
>possible/easy to upgrade an ANSI EDB database to Unicode EDB? Can I
>just backup the ANSI and restore from Unicode manager? Or will I need
>to extract all the data to SQL INSERT statements (reverse engineer) and
>recreate it with the Unicode version?

From other posts I believe its the latter.

I'll be interested to hear your experiences.

Roy Lambert

> > Can't have both installed simulatenously?  Why not?  EDB Mgr is
> > just an .EXE and as long as they point to two different
> > configuration/catalog/database sets, one wouldn't know about the
> > other--I would think.
>
> I mean simultaneously installed in Delphi so that you can migrate
> databases from your own application. I was thinking in therms of a
> single application capable of reading the ANSI database and
> creating/writing the new Unicode Database - that doesn't seem to be
> doable.

Oh, ok.  No, I have the ANSI version of the components installed for
Delphi 2006 and the Unicode version of the components installed for
Delphi 2009.


> > It might get a little trickier running two database servers from
> > services, but as long as you configured them from separate folders
> > to point to different databases, that should work as well.
> >
> > I haven't tried this yet--so am thinking out loud here...
>
> I haven't tried that also, but what about the client application? How
> will you build the application - using the ANSI or the Unicode
> version?
>
> The only way I can imagine at the moment is to add a feature to the
> current ANSI version of your application to export databases using
> reverse engineering (or build an export utility using ANSI) and then
> include an "import" function in the new Unicode application.

There won't be an application that utilizes both.  I'll migrate the
application code to Delphi 2009 in a new folder, test against a new
database until I'm satisfied it will work, then convert the database
over on a weekend and give the client a new unicode version of the
application that will work against the new database.  It will be a
complete overnight switch, not a dual-access.

--
David Cornelius
CorneliusConcepts.com

David


Its the same reason you can't have two different versions of DBISAM  (save V3 & V4) installed simultaneously - the component names are the same. Like yourself I can see no problems with having two EDBManagers installed simultaneously, they should even share the same ini file (at least I can't see anything in there - non unicode - which looks as though its specific (I'm sure Tim will post to prove me wrong . However, opening non-unicode tables in the unicode version is probably not to be recommended.

Roy Lambert

David,

<< Aside from the Delphi code changes that are necessary, is it
possible/easy to upgrade an ANSI EDB database to Unicode EDB? >>

It's possible, but not entirely easy to do.  The best solution is this:

1) Reverse-engineer the existing database to a script (no data).
2) Change all instances of UNI as a collation reference in the
reverse-engineered script to ANSI.
3) Export the data from each table to a CSV file using the EXPORT TABLE
statement.
4) Run the script above on the new database.
5) Import the data for each table from the files created in step 3.

<< It's still purely Win32, right?  No .NET involved? >>

Yes.

--
Tim Young
Elevate Software
www.elevatesoft.com

> 1) Reverse-engineer the existing database to a script (no data).
> 2) Change all instances of UNI as a collation reference in the
> reverse-engineered script to ANSI.  
> 3) Export the data from each table to a CSV file using the
> EXPORT TABLE statement.  
> 4) Run the script above on the new database.  
> 5) Import the data for each table from the files created in step 3.

Thanks.  I assume the collation references in 2) were switched around.
The reverse engineer of my existing ANSI database would generate ANSI
collations, so I'd want to change those to UNI, not the other way
around.

I think I can script this whole process.

--
David Cornelius
CorneliusConcepts.com

David,

<< Thanks.  I assume the collation references in 2) were switched around.
The reverse engineer of my existing ANSI database would generate ANSI
collations, so I'd want to change those to UNI, not the other way around. >>

Yes, sorry about that.

--
Tim Young
Elevate Software
www.elevatesoft.com