Update: SA12 possible bug with 1254TRK encoding

[Former Member]

Most probably it's something I'm doing wrong, but even if it's like that, I cannot find what it is. Please have a look at the issue, it's simple. I described it differently when I first posted this question, but rather than posting a new one I chose to update it since they are related.

Description: I create a database with encoding 1254TRK (the script is below) and I try to connect to it from VS2010 via Server Explorer, however I get the error in the screenshot at the bottom.

CREATE DATABASE 'D:\\pts\\database\\db1254.db' 
LOG ON 'db1254.log' 
COLLATION '1254TRK' NCHAR COLLATION 'UCA' JCONNECT OFF;

If I create it with encoding 1252LATIN1 (with the script below), I can connect to it smoothly.

CREATE DATABASE 'D:\\pts\\database\\db1252.db' 
LOG ON 'db1252.log' 
CASE RESPECT COLLATION '1252LATIN1' NCHAR COLLATION 'UCA' JCONNECT OFF;

Is there anything I'm doing wrong? Or any ideas how to workaround that?

You can ignore the rest of the question except the screenshot, unless you'd like to look into details.

I'm trying to create a data connection to use with Entity Framework, however after I fill in the required parameters and click OK, I get a "Column '@@VERSION' not found" error.

I followed the instructions here and tested it with the Sql Anywhere 12 Demo db but no luck still. I even tried uninstalling and reinstalling the VS package.

A screenshot is available below. (Using VS2010 Premium and Sql Anywhere v12.0.1.3537 - Developer edition).

Any ideas?

Update: Maybe the steps I followed could help:

• Ran C:Program FilesSQL Anywhere 12Assembly\\v2SetupVSPackage.exe /i
• Result: After selecting SQL Anywhere 12 and click "Host Name", etc. "Add Connection" window in Visual Studio disappears without any message.
• Uninstalled (with /u switch) and reinstalled C:Program FilesSQL Anywhere 12Assemblyv2SetupVSPackage.exe /i with the same result.
• Ran C:Program FilesSQL Anywhere 12Assembly\\v4SetupVSPackage.exe /i (while v2 was installed)
• "Column '@@VERSION' not found" message is displayed as explained in the original question.

Also, there was an error in Event Viewer saying one of the policy assemblies could not be registered in GAC, possibly occured while installing v4 after v2.

.

[johnsmirnios]

As Volker suggests, it is the "I-no-dot is not equal to I-dot" problem. The engine defines the variable as @@version which, in a 1254TRK, is not equal to @@VERSION even in a case-insensitive way. The driver needs to select @@version instead.

[Former Member]

Thank you for the comment. My opinion is it should have converted @@version to uppercase using invariant culture.

[johnsmirnios]

Since @@version is an identifier (not a SQL keyword), it is compared using the catalog collation. The catalog collation is always equivalent to the CHAR collation but case insensitive (and, for UCA, it is also accent insensitive and punctuation-primary).

Ideally, the engine should have used @@VERSION from the beginning as we tried to do with other identifiers; however, changing it to upper case at this point will break any existing clients of Turkish databases that use "@@version".

[Former Member]

I understand, thanks for the insight. I guess connecting via ado.net failed with the same message for the same reason. Would there be some way we can work around that and use 1254TRK encoding?

[VolkerBarth]

Possibly you could create a connection-specific variable in a login procedure named "@@VERSION" (with the correct Turkish letter, obviously) and set that to the value of the real system variable, e.g.

CREATE PROCEDURE DBA.MyLogin( )
BEGIN
    CREATE VARIABLE @@VERSION VARCHAR(128) = @@version;
    CALL sp_login_environment;
END
go
GRANT EXECUTE ON DBA.MyLogin TO PUBLIC
go
SET OPTION PUBLIC.login_procedure='DBA.MyLogin'
go

IMHO, using this in a login procedure should have the desired effect that every connection has set this variable before anything else is done...

[VolkerBarth]

@henginy: In case that you'll try this possible workaround - I would be glad to get to know if that suggestion works or not:)

[Former Member]

Sorry, I still haven't had a chance to, but I will soon and let you know the result! Thanks very much for the suggestion!

[VolkerBarth]

What happens when you use the collation 1254TRKALT instead?

Could this be due to the "I-no-dot is not equal to I-dot" problem - as "@@VERSION" contains one of both of them?

Note: I don't speak Turkish at all so I'm very wild guessing:)

[Former Member]

Wild but a good one:) Actually 1254TRKALT is the encoding we used in our previous applications (as ODBC connection), but for this project we need the accuracy, i.e I-no-dot should NOT equal to I-dot. I'm writing this response from home now, but I'll post a follow-up when I try it.

[Former Member]

Yes, no problem with 1254TRKALT.

[MCMartin]

I can only say, that it is not a general problem of SQLA, because for me it works like a charm.