![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 13 total |
![]() |
Fri, Oct 3 2008 5:51 AM | Permanent Link |
Leslie | 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 |
Fri, Oct 3 2008 8:52 AM | Permanent Link |
Leslie | Sorry for the spelling mistakes ( officies --> offices) Do not ever remember my spelling
this word like this. Definitely need more sleep ... ![]() |
Fri, Oct 3 2008 9:29 AM | Permanent Link |
Leslie | 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 |
Fri, Oct 3 2008 9:38 AM | Permanent Link |
Leslie | Tim,
Is it possible to query/manipulate an other DB from a trigger/stored procedure? Regards, Leslie |
Fri, Oct 3 2008 1:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Fri, Oct 3 2008 1:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Leslie,
<< Is it possible to query/manipulate an other DB from a trigger/stored procedure? >> Unfortunately, no. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Oct 3 2008 1:44 PM | Permanent Link |
Leslie | >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 |
Fri, Oct 3 2008 2:15 PM | Permanent Link |
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 |
Fri, Oct 3 2008 2:41 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Fri, Oct 3 2008 2:45 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |