Tim,

I am taking a second look at ElevateDB,  but could not find some answers by rereading the
online documentation (though it is really well organized).

The scenario is this:

There are officies in different countries.  (--> Unicode)
The default collation is different for each country.
All data from the country officies is uploaded to international central officies.
Users in a central officie  should be able to chose the collation of the country when the
data is the viewed country by country.
But sometimes all data needs to be displayed in the collation picked by the user.  

I cannot see any efficient way to do this. My best shot is to create all  indexes for all
the collations for the central officies and parse the SQLs before execution and replace
collation names.  Views need to be created and maintained for every collation as well.
Plus the name of the view replaced the same way.  

Could this work? Or with your knowledge of ElevateDB you may have a better idea.

I can see how long your todo list is and I think I already have the workaround, but maybe
sometimes .... I guess it would make the programing part easier if the collation name
could be defined as a parameter.  

Regards,
Leslie

Sorry for the spelling mistakes ( officies --> offices) Do not ever remember my spelling
this word  like this. Definitely need more sleep ...

I have an "ElevateDB like" idea.

Maybe the best thing would be to have a database for each country in the center office.
As ElevateDB allows to work with them if they were  one database. Except there are no
crossdatabase indexes.  

Regards,
Leslie

Tim,

Is it possible to query/manipulate an other DB from a trigger/stored procedure?


Regards,
Leslie

Leslie,

<< There are officies in different countries.  (--> Unicode)
The default collation is different for each country.
All data from the country officies is uploaded to international central
officies.
Users in a central officie  should be able to chose the collation of the
country when the data is the viewed country by country.
But sometimes all data needs to be displayed in the collation picked by the
user. >>

Well, the first question I have is, are you talking about the sort
order/selection of the data ?  The only two things that collations affect in
EDB is the sort order and the matching of VARCHAR/CHAR/CLOB values in
expressions.  Why not just use a single collation at the central office that
corresponds to the most comfortable collation for those working in the
central office ?  Trying to maintain multiple versions of databases with
different collations will be a nightmare.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< Is it possible to query/manipulate an other DB from a trigger/stored
procedure?  >>

Unfortunately, no.

--
Tim Young
Elevate Software
www.elevatesoft.com

>Is it possible to query/manipulate an other DB from a trigger/stored procedure?

If not, maybe extensions could be used for this?


Regards,
Leslie

Tim,

<<Well, the first question I have is, are you talking about the sort
order/selection of the data ?  The only two things that collations affect in
EDB is the sort order and the matching of VARCHAR/CHAR/CLOB values in
expressions.  Why not just use a single collation at the central office that
corresponds to the most comfortable collation for those working in the
central office ? >>


People in the center office are speaking different languagges. For some of them the
languagge of the examined country is comfortable, while for others this is out of
question. For them only the collation of their mothertounge  or maybe English is
comfortable. I guess the closest thing to what you have suggested is to have a collation
where all national characters are grouped by the English ABC, and all characters are
sorted according to the English char in the group they belong to.

<<Trying to maintain multiple versions of databases with
different collations will be a nightmare.>>

This is something I  cannot avoid.  The local offices must have their database localized,
and the central office must have all the data from the different countries.


Regards
Leslie

Leslie,

<< If not, maybe extensions could be used for this? >>

Yes, that would be one way of working around this limitation.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< People in the center office are speaking different languagges. For some
of them the languagge of the examined country is comfortable, while for
others this is out of question. For them only the collation of their
mothertounge  or maybe English is comfortable. I guess the closest thing to
what you have suggested is to have a collation where all national characters
are grouped by the English ABC, and all characters are sorted according to
the English char in the group they belong to.  >>

Yes, but is the issue whether the main office needs to see the data in a
specific sort order or use a specific collation for comparisons.  This is a
separate issue from what the display of the data looks like or whether they
can read it.  The collation only affects the sort order and comparisons.  If
that isn't an issue, then using the UNI collation will work fine for the
main office.

<< This is something I  cannot avoid.  The local offices must have their
database localized, and the central office must have all the data from the
different countries.  >>

That's not what I was referring to.  What I was referring to was trying to
have multiple versions of the database for each collation at the central
office.

--
Tim Young
Elevate Software
www.elevatesoft.com