|
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:
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.
Comment Text Removed
|
.
|
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. Thank you for the comment. My opinion is it should have converted @@version to uppercase using invariant culture.
(04 Mar '12, 15:14)
henginy
Replies hidden
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".
(04 Mar '12, 20:46)
John Smirnios
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?
(07 Mar '12, 04:32)
henginy
Replies hidden
2
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...
(07 Mar '12, 05:09)
Volker Barth
@henginy: In case that you'll try this possible workaround - I would be glad to get to know if that suggestion works or not:)
(09 Mar '12, 04:23)
Volker Barth
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!
(12 Mar '12, 03:41)
henginy
|
|
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:) 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.
(04 Mar '12, 15:10)
henginy
Yes, no problem with 1254TRKALT.
(07 Mar '12, 04:33)
henginy
|
|
I can only say, that it is not a general problem of SQLA, because for me it works like a charm. |
