Documents for QlikView related information.
This application gives a short example of how translations and regional formats can be applied in a QlikView application.
If the date seetings are available DD/MM/YYYY, MM/DD/YYYY and YYYY/MM/DD do you need to three date fields in every fact table? one for each format!!!
and three more for DD-MM-YYYY, MM-DD-YYYY and YYYY-MM-DD
and three more for DD.MM.YYYY, MM.DD.YYYY and YYYY.MM.DD
Hi Toni Kautto:
If you have 10 different currencies, do you need 10 amount fields for each currency at you fact table?
If you have ###.###,00 and ###,###.00 as money format do you need 20 fields (10 amount currency for each money format)?
Yes, by this principle those are correct assumptions. Creating additional fields general does not lead to any problems, besides creating a longer list of fields.
If you want to hide the fields you could consider adding a HidePrefix or HideSuffix so that the currency and language fields are not visible in all object properties.
Optionally a way to make the visualization easier could be to tie each user to a specific locale through Section Access, and thereby reduce the document to one locale only being visible for each user. Or perhaps the base locale and one more, to enable viewing values in local format as well as corporate format.
Well, i was thinking in an Users table with this fields
UserID, UserDateFormat, UserCurrency, UserDecimalSep, UserThousandSep
Too much fields multiplied by too much records will affect performance.
But if we do a reduction for each locale combination we will lose the "International Collaboration Session" functionallity.