[13.0.56 Pro] - Issues with non-ascii names in SQL Server

[13.0.56 Pro] - Issues with non-ascii names in SQL Server

SA/SE has severe issues with the internal handling of the current database context for databases with names containing non-ASCII characters (e.g., Japanese and some Eastern European characters). Please, disregard the fact that using non-ASCII characters in database object names is an ancient Roman habit, and as such, it is not very wise. Inheriting just one such database proves their existence, and throws all the arguments out the window. After all, it miraculously works everywhere else except in SA/SE.

I cannot publish the original database, this is just a small example with arbitrary Japanese characters (katakana, I think). Below is a short test script and some descriptions in addition to this short video >>>here<<<.

Code:

USE [master]
GO

DROP DATABASE IF exists [ミシ];
GO

CREATE DATABASE [ミシ]
GO

CREATE TABLE [ミシ].[dbo].[ミシ] ([ミシ] nvarchar(20));
GO

INSERT INTO [ミシ].[dbo].[ミシ] ( [ミシ] ) VALUES (N'ミシ'), (N'áóéúíöőüű');
GO

SELECT * FROM [ミシ].[dbo].[ミシ];
GO

-- things work perfectly well until this point and even here they do not fail
-- however, there are some signs
-- notice how changing database context does to make its name bold
USE [ミシ];
GO

-- this executes too
SELECT * FROM [dbo].[ミシ];
GO

-- and now here comes trouble
-- triggering the SQL Assistance (SE IntelliSense) or refreshing the Explorer
-- immediately shows that SE is quite a bit confused regarding the database context
SELECT

Unfortunately unable to reproduce the behavior seen in the video so far. I'm not getting question marks, and not having issues with changing database selection. Yes the Japanese characters don't appear emboldened, but that seems to be font issue (no bold chars). The database dropdown on the toolbar changes correctly after executing USE [ミシ] and similar text. In the settings I tried changing Code Page from "Default" to "Unicode", to "Baltic", and several other, and all of them worked as expected. My connection is set to ADO.NET. If you use ODBC, Could it be a driver issue?

I've figured it out. It turned out it wasn't some internal issue, it's the result of the Context DB Query that is displayed (and used internally) in the Explorer, which is one of the many queries I've modified ages ago. The modified query declares a bunch of variables for object names, and for some unknown reason, they were declared as varchar instead of sysname. Now it works properly and even the name is emboldened.

I apologize for the false alarm.

UPDATE:

There are still some issues that changing/fixing the Context DB Query did not solve.

It seems that when reading the properties of such databases, the info for General and Options tabs are not properly retrieved. Eg. the grid for Database files is mostly empty, and the Options are either missing (Collation, Compatibility Level) or shown as set incorrectly. Trying to change and save them or simply clicking on the SQL tab throws an exception:

	Quote:
	Access violation at address 000000003079B912 in module 'saDbMgmt.dll'. Read of address FFFFFFFFFFFFFFFE

Thank you. Confirmed. I was able to reproduce the AV on saving the Properties dialog or just switching to the SQL tab. We will investigate and fix that.