Sorry, this is a little OT, but ..
Using D2006 and DBISAM 4 (latest)

I use the ANSI decimal 189 character '1/2' quite a lot in my main app.  
This is fine for most English speaking and Western European users, but that
character does not exist in the East European character set, etc.

I can get round this in many places by specifying ANSI_CHARSET - works
fine for component like TDBText and Grids, but a TDBEdit and some other
components get it all wrong as I am sure many of you know.

Is it possible to write a unicode app with D2006 and DBISAM .. and if so,
is it worth the effort (before D2009)?  For now, I can use other solutions .. but the
<half> char is the ideal for my needs.... if only!

Malcolm

--

Malcolm,

<< I use the ANSI decimal 189 character '1/2' quite a lot in my main app.  
Is it possible to write a unicode app with D2006 and DBISAM .. and if so,
is it worth the effort (before D2009)?  >>

To be honest, your best solution is to bite the bullet and upgrade to ElevateDB.
I was perfectly happy with DBISAM, but when it became clear that Tim could
only implement Unicode with a completely new database engine, I took the
EDB upgrade path. There is no alternative to full Unicode in these scenarios:
-  you want to display different character sets simultaneously
-  you want to use characters outside the code page in use

And one more caveat: EDB Unicode will only work with D2007 upwards.
So why not hang on and wait for D2009? It's "just around the corner"
- at least that's the impression I get.

Regards,
Dan Rootham [Team Elevate]

Hi Dan

I noticed Tim saying he planned to update DBISAM for D2009 so
I was hoping that might include unicode given the D2009 native support.

I think a switch to EDB would be a major operation for this hobby developer
of freeware applications.  

At present my only 'problem' is with the ½ so I may simply use alternative
displays such as decimal (only one extra character) or " 1/2" (3 extra chars)
per instance.  However there is a space limitation on electronic scoreboards
and in my reports, so ½ is preferred.

I think I may just wait for D2009 and discuss with my east european users what
is best for them in the meantime.

Not sure if I want the challenge of far eastern users!

Malcolm  

Malcolm,

<< I noticed Tim saying he planned to update DBISAM for D2009 so I was
hoping that might include unicode given the D2009 native support. >>

No, absolutely not.  EDB is the route for Unicode.  DBISAM will be updated
for D2009 so that it is basically just like it is, except usable with D2009
also.

<< I think a switch to EDB would be a major operation for this hobby
developer of freeware applications.   >>

It really depends upon a lot of different factors - amount of SQL that
you're using, whether you're using the DDL methods in DBISAM, etc.  Overall,
however, it's usually not a trivial move.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for that Tim.

Using a lot of SQL but no DDL.
Looks like I need to set aside a fair chunk of time over the next 6 months

Another thing that may be a pain is that I allow users to restore old backups
from earlier database versions which I silently update.  I fear that this
may be more of a challege under EDB.   Ah, well...

Malcolm,

<< Another thing that may be a pain is that I allow users to restore old
backups from earlier database versions which I silently update.  I fear that
this may be more of a challege under EDB.   Ah, well... >>

As long as you restore the catalog with the tables in their entirety, then
the process won't be any different than that which you use with DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>
> As long as you restore the catalog with the tables in their entirety, then the process won't be any different than that which you use with DBISAM.

... ah, but you don't know how I do it at present
I will have to do it 'properly' under EDB .. but I am not whingeing, just getting a crick in my neck looking at steep slope.

Malcolm
--

Malcolm,

<< .. ah, but you don't know how I do it at present >>

Okay, now you've got my curiosity piqued.  How are you doing it now ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Malcolm,
>
> << .. ah, but you don't know how I do it at present >>
>
> Okay, now you've got my curiosity piqued.  How are you doing it now ?

Er, do you remember Peter Mora and his TDBISAMDesignTable component?
Well, with it I can restore any backup from as old as Dbisam 3 then
convert and restructure it by running each table through:

with ATable do
begin
 if Exists then
 begin
   UpgradeTable;   // DBISAM v 3 to 4
   if not CompareStructure then
       UpdateTable; // add, drop, rename, redefine columns
 end
 else
   MakeTable;     // new table
end;

// OK, some tables need default data, etc added to new fields so I do have
some UPDATE scripts for that..

This will not translate directly.

Why do I need to let users dredge up old backups?  The app is for sports
events and users (including myself) commonly restore the backup of the previous
year's event as a starting point for setting up the current year's one.  

So a 'ConfigDiff' component like Peter's, capable of generating the code to
convert from an old (within reason!) to the current structure would be just
the ticket for me, but until then I would have to maintain incremental 'scripts'
and apply them as needed.

Malcolm

--

Malcolm,

<< So a 'ConfigDiff' component like Peter's, capable of generating the code
to convert from an old (within reason!) to the current structure would be
just the ticket for me, but until then I would have to maintain incremental
'scripts'  and apply them as needed. >>

You might want to wait - as part of the reverse-engineering changes coming
up in 2.02 or 2.03, I'll be adding diff functionality for databases, also.

--
Tim Young
Elevate Software
www.elevatesoft.com