on 2012 Feb 24 1:57 AM - last edited on 2012 Feb 24 2:57 AM by G_S
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.
.
Request clarification before answering.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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".
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?
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...
@henginy: In case that you'll try this possible workaround - I would be glad to get to know if that suggestion works or not:)
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:)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I can only say, that it is not a general problem of SQLA, because for me it works like a charm.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
46 | |
6 | |
6 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.