Please be aware that the SAP SQL Anywhere Forum will be shut down on August 29th, 2024 when all it's content will be migrated to the SAP Community.

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' 

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' 

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.


asked 24 Feb '12, 01:57

henginy's gravatar image

accept rate: 0%

edited 05 Mar '12, 02:58

Volker%20Barth's gravatar image

Volker Barth

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.

permanent link

answered 03 Mar '12, 15:16

John%20Smirnios's gravatar image

John Smirnios
accept rate: 37%

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 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

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.

    CALL sp_login_environment;
SET OPTION PUBLIC.login_procedure='DBA.MyLogin'

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
showing 3 of 6 show all flat view

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:)

permanent link

answered 02 Mar '12, 13:01

Volker%20Barth's gravatar image

Volker Barth
accept rate: 34%

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.

permanent link

answered 02 Mar '12, 05:31

Martin's gravatar image

accept rate: 14%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 24 Feb '12, 01:57

question was seen: 3,605 times

last updated: 12 Mar '12, 03:41