I'm trying to work out how to use SQL server management studio properly with multi-byte unicode characters. even something as simple as:
select N'动漫'
just returns square boxes in the result pane. I know the underlying database is set up correctly to handle unicode and other apps on the PC work fine with chinese characters
any clues very much appreciated
Changing the font to Arial Unicode MS did the trick for me.
I don't understand why Text Results displays fine with Fonts where Grid Results does NOT, and why other Unicode Fonts don't work but oh well.
After many frustrating hours with this problem, I just discovered a solution (if not an explanation).
Changing the Query Results font had no effect on my system (Win 7 Enterprise, 64-bit).
After much Googling I discovered this: My Chinese Word Suddenly Appear As Square Box
In short: create a new Windows user account, then log in as that user - you should find that your Chinese characters display correctly. Now log in to your original account, and you should find this also now displays Chinese characters correctly.
So creating the new account has the effect of fixing the behaviour for both (possibly all?) accounts. Now - anyone have an explanation?
Related
I import a csv to SQL server in SSIS. Here's what my settings look like:
The system firstly suggests 6501 and then in preview all letters look properly. However, when I proceed, it throws an error saying that it cannot proceed as it's really a 1252.
I change to 1252 and it all works now. However, I suddenly loose my regional letters. Here's what it looks like
Here's what I've tried:
Changing to 1250, 65001 etc
Ticking Unicode
changing Locale to Polish, polish(Poland), English
googling
searching stack
I'd appreciate if someone could point me toward a direction as nothing comes to my mind.
I have a problem with a WordPress site (it's in Swedish). For some reason I can't use all characters when I'm writing posts - the characters å, ä and ö become Ã¥ ä ö. The site is a webshop and I have the Woocommerce plugin installed. The same problem with åäö occurs in the long product descriptions of Woocommerce.
Anyone know what I can do to solve this? The character encoding in WordPress admin panel is set to UTF-8 and so is the database charset in wp-config.
In the database in phpmyadmin the collation of the wp-posts tables are set to "utf8_general_ci". Is that the problem?
This thing has never happened to me before, even though I have built a lot of WP sites in the past. Therefore I don't know what to do. Maybe the solution is simple but I want to know what I'm doing before doing anything so I don't risk messing up the site.
Would really appreciate some help with this, thanks.
When "national special characters", ie. non-ASCII characters, are displayed wrong, you probably have an error related to charset. The easiest way to fix this is usually to make sure that you are using UTF-8 everywhere.
(For Swedish in particular, you can use ISO-8859-1 (worst), ISO-8859-15 (better) or UTF-8 (best).)
You need to use the same charset everywhere, from the database to the HTML declaration.
In your theme's header.php file, please make sure that the declared charset is
UTF-8.
In your text editor or on your server, please make sure your theme files are being saved as UTF-8.
In MySQL, please make sure that the table schema is set to use utf-8.
In MySQL, please make sure that connections default to use UTf-8: mysql --default-character-set=utf8
In PHP, try setting the connection to utf-8 with mysqli_set_charset
In order to fix the Character Encoding Mismatch Problem in WordPress,
Open the ‘wp-config.php’ file in a text editor(the wp-config.php file can be found on the directory where you installed WordPress).
Find the following two lines and comment them out:
define(‘DB_CHARSET’, ‘utf8′);
define(‘DB_COLLATE’, ”);
They should look like the following after you comment them out:
//define(‘DB_CHARSET’, ‘utf8′);
//define(‘DB_COLLATE’, ”);
Now upload the updated ‘wp-config.php’ file to your webhost.
This character encoding problem can happen after a database upgrade too so it doesn’t hurt to keep this trick in your mind just in case.
In another case, if you are using PHP Dom (loadHTML) somewhere, there is a need to load HTML as UTF-8. I have fixed it by:
Replacing
#$dom->loadHTML($html);
to
#$dom->loadHTML('<?xml encoding="UTF-8">' . $html);
im using CR version 13. With VS2010 and CR SP1 for VS2010.
I have a report with lots of subreports. They use XML schemas for data at design time and then uses runtime populated datasets. It works great on my development machine. But on other development machines or in deployment the report pops up a databaselogon promt asking for username etc.
Ive seen alot of people having similar problems, nobody have an answear. Let me make it clear, i dont use a database in any way shape or form.
Other reports works ok, only my new report do this.
I had some subreports i wanted to supress. I did this by simply not setting any datasource on them. For some reason CR on my development machine didnt pop up a dialog for datasource, so i assumed it worked.
What i do instead now, wich is proberbly also the better way. is to give the report a parameter value wich is used in the supress formulas of the sub reports.
I'm working on a report in SSRS 2005 that is a questionnaire with yes/no answers. Trying to get a checkbox on the report. Have tried using windings for the font and an iif statement to set the character, but that doesn't come out correctly when exporting to PDF. I'm using local reports, not from a report server.
The easiest/simplest solution is just to use an embedded image with a expression which sets the source of the image to the checked or not checked version. This will work across export types (except text/csv).
I am assuming however you want this to be non-interactive.
I'm about to venture down this path, as well (clients that require printed forms look exactly as they always have, basically). Did you try this suggestion?
Keith, aside from the image solution, what are the options?
Am I the only person annoyed by this? I don't even know what proc I'm clicking on if the file names have the same prefix, or are longer than the context window width.
I find the tab dropdown, as well as the tab names themselves, annoying. You can't widen either of them.
It helps to save each script to a file, even if only temporarily. I work in an environment where I need to save each script I write. I can see the file names if I hover over each tab. Not perfect, but it helps.
If you're running SSMS 2008 (or even just SSMS Express 2008), you can change certain property settings so that only certain things are shown in each tab: the current server, the current database, the filename, etc. If you only work in a single database, for instance, you could switch off everything except the filename.
But unless any of these suggestions help, there's really no way around those stupid tabs.
connect is garbage, they dont do anything
There isn't a way to make it any bigger.
I find this greatly annoying as well. There are a couple of connect items open about this.