I have the following problem:
I changed the regional settings to Dutch. This means that number should have the following format: ###.###,## ,and currencies should have the following:
€###.###,##
unfortunately this doesn't seem to work (see picture/table in the background) when I do the DAX formatting it doesn't change it to the European format but to the American format.
can anyone help me understand why this doesn't effect my report? I am running the latest version but couldn't find the solution to my problem online. I've tried almost every solution given by Microsoft but non work!
The Locale for import settings only affect imports from untyped data sources e.g. text files.
The locale used for display is set when the PBIX file is created, based on the windows settings of the machine. It can't be changed through the UI, but there is this workaround you could try:
https://www.sqlbi.com/articles/changing-the-culture-of-a-power-bi-desktop-file/
Related
I am using C++ & CLR to create a GUI in Visual studio. The whole app is like a calculator for the price of transport and the costs associated with it for my work. At work, we are using Helios and we are able to export certain data to Excel. Specifically, the prices of transport, packaging materials, etc. And what I need is for my program to be able to read certain cells in Excel where prices and other variables are recorded and calculate with it so that I don't have to rewrite all the values manually in the source code.
I spent a lot of time looking for a solution but couldn't find anything that referred to my problem. Is it even possible to build such a program? I don't want anyone to solve it for me. Maybe I just missed some banality and just need some direction. And as far as I understand, the CSV format is irrelevant for me, because I need to work with a few specific cells that Helios pre-fills for me in the Excel sheet.
I am about to use Weka for processing a dataset that contains numeric and nominal values. As Persian and Arabic are the secondary languages I am using in my Windows 7 operating system, I assumed that this might be the reason that when I am trying to save a loaded CSV data file in Weka as an ARFF file format, the numbers are all saved as question (?) marks! However, even by removing these languages from the Control Panel setting, nothing changed.
Moreover, I have upgraded my Java version from 8 to 9 recently. I am not sure if this could be the reason for this.
I searched for a probable reason on the internet, though could not find any solution. Thanks, everybody in advance.
I found the solution, and it was easy!
In the Control Panel, I selected the Region and Language option. Then in the Formats tab, I changed the Format option from Persian to English (United States), and everything turned out to be working alright in Weka!
Moreover, in the Administrative tab, for the Language for non-Unicode programs option, it is better to set the language in use as English (United States).
Cheers ...
I am facing this weird problem where I need to fetch PST timezone information (e.g. MUI_Std, Std, TZI etc.) from Japanese Windows OS machine but unable to find a reliable way to do it.
I have tried RegLoadMUIStringW API. But it returns me name of PST timezone in localized format. I have PST timezone name in English with me. So using output of this API I am not able to compare and tell whether the value being read from registry is for PST timezone.
One possible solution is to have MUI_Std value of PST timezone in code (the value is #tzres.dll,-212) and compare this value with the values read from registry. This way I will come to know if the timezone I am reading is PST or not. But I am not sure if this is a reliable way to detect PST timezone.
Let me know if anyone has any inputs on this.
Time zones are identified by their ID (aka "Key Name"), not their localized names. The IDs are not localized.
Thus, regardless of language of the OS, you'll find the Pacific time zone information at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Pacific Standard Time
Of the values within, only the Std, Dlt, and Display values are localized, and the MUI values point to where those strings are located in the resource files. The resource files are installed with the Windows language packs. Note, you shouldn't hardcoded a value (eg, -212) because a future update might provide a new string that could change it.
Also, if you just need to retrieve the time zone information for a given ID, you don't actually need to access the registry at all. Just use the EnumDynamicTimeZoneInformation function to iterate over the time zones looking for the one that matches the desired TimeZoneKeyName (which again is not localized).
If however, you're looking for the localizations of these in languages other than the current OS language, you could try taking a look at the TimeZoneWindowsResourceExtractor project.
I wrote a recent SQL Shack article that shows how to extract time zone / time zone adjustment information directly from a Windows PC registry. The technique shows C# and VB.net desktop apps that build text files with time zone and time zone adjustment information. I placed the code at my GitHub resource, and you can modify it if it does not specifically cover the exact data you need. Mr. Johnson-Pint's earlier content here at SO, and at his blog, really helped me build out my ideas.
HTH!
There is a in depth tutorial that leads you through building a dashboard. I can't get started because the first thing is to connect to a cloud resource that doesn't(?) exist.
Any help would be great.
You can find the files here.
Two notes about these files:
1) These are from June and might be outdated if you are looking at newer instructions.
2) To get around GitHub's size cap, I had to break a couple of .csv files up:
AU Sales.csv, which should have no effect on following along with the instructions.
bi_salesFact.csv, which will cause you to treat the US Sales data like the international data by importing it using the folder option instead of the file option
I am recently trying to change our company's old program. One of the huge rocks in my way is that the old program was made with Borland C++, and it had its own way of connecting to the SQL Server 2000 database.
After 8 years, I'm trying to retire this program. But when I looked at the database, I got freaked out!
The whole database was in a vague language that was supposed to be Persian.
I'll give you a portion of the database converted to SQL Server 2005, so you can see it for yourself. I've spent many days trying to figure out how to decode this data. But so far no results has come out of it.
Link to the sample Database File
So please if you can tell me how to use them in Microsoft C#.net it will be much appreciated.
These are the datatypes used for them:
And this is how it looks:
Thanks a lot.
1) Analyse existing program and original database
Try to figure out how the C++ program stored Persian text in the database. What are the collations defined on the original server, database, and on column level.
Does the C++ program convert the data to be stored and retrieved from the database? If so, find out how.
It may well be that the program displays data in Persian, but does not store it in a compatible way. Or it uses a custom font that supports custom encoding. All this needs to be analyzed.
2) The screen shots looks as if everything Persian is encoded as ASCII characters higher than CHAR(128).
If this a standardized encoding or custom created?
3) To migrate the database, you most likely will need to convert the data mapping original characters to Unicode characters.
First recreate the tables using Unicode-enabled columns (NVARCHAR, NVARCHAR(MAX)) rather than CHAR and VARCHAR, which only support Latin or Extended Latin.
4) Even if you successfully migrated your data, SSMS may not correctly display the stored data due to font settings or OS support.
I summarized the difficulties of displaying Unicode in SSMS on my blog.
But first, you need to investigate the original database and application.