Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.


I'm using the Sql Anywhere ADO.NET Data Provider and the Entity Framework 4.4 (latest version for .NET 4.0) in an application, that I'm developing.

I just installed the currently latest EBF (

When I run my application now, I get the following exception when the connection to the database is opened at the start of the application:

Invalid option 'timestamp_with_time_zone_format' -- no PUBLIC setting exists

So I checked the database for that option and the 'timestamp_with_time_zone_format' option indeed is not set. And the reason for that is, that it was not needed (and still isn't).

My guess would be, that this behavior (i.e. trying to set this option) was added (as default) along with a bugfix (Build #3856 - Engineering Case #731461 in the changelog of the EBF).

My question is: how can I disable it? I don't need it (or do I?).

Thanks in advance for any help.

asked 25 Mar '13, 08:56

Andre%20Hentschel's gravatar image

Andre Hentschel
accept rate: 0%

edited 25 Mar '13, 09:04


I just did some testing to verify this problem. I created a database using SQL Anywhere 10. Then I tried to set the 'timestamp_with_time_zone_format' option. But it failed because it's not supported by 10. After I upgraded the database to 12, I tried again. It didn't fail.

Are you sure that you have upgraded your database to 12?

(25 Mar '13, 14:57) Minghai Chang
Replies hidden

Hi, yes I'm sure my database is upgraded to 12 (SYSHISTORY says so). And I also was able to set the option for my database. But that's not the problem.

The problem is that the current data provider throws an exception on connecting to the database, if the option is not set in the database.

(26 Mar '13, 04:39) Andre Hentschel

Update 3: This issue is now resolved in CR #741704,,

Update 2: I have now been able to reproduce this issue with the .NET 4.5 Provider, with an database, running on a server.

Either upgrading/rebuilding the 11.0.1 database file to version 12, or running the 11.0.1 database on the original 11.0.1 server is a possible workaround. I have opened this investigation as CR #741704.

Update: This issue has now been fixed in CR #735654, in and

Which version of the database server are you using? Which version of the SQL Anywhere software was your database initialized with? ( SELECT * FROM SYS.SYSHISTORY ?) Was it ever upgraded?

Yes, you are correct - this is a regression due to the CR #731461 bug fix. Thank you for reporting this issue - I have opened this new investigation as CR #735654. I will update this thread when we have additional information.

Currently, the workaround is to downgrade the ADO.NET provider to a build earlier than

permanent link

answered 25 Mar '13, 09:08

Jeff%20Albion's gravatar image

Jeff Albion
accept rate: 25%

edited 19 Jun '13, 09:15


Many thanks for the reply.

The database version is also And the database was initialized with version 10.0.1 and later it was upgraded to 12.0.1.

My current workaround is to insert the option for my development system (productive system use older data provider versions anyway).

Apropos downgrade: what is the best way to do this (without installing the whole sql-anywhere server package again)? Just changing the version number in machine.config to a previous installed data provider version is ignored (the latest version is used always). And using GAC util to remove provider version or copy older dlls to the GAC folder of newer version doesn't seem a very clean solution.

(25 Mar '13, 09:25) Andre Hentschel
Replies hidden

Regarding the ADO.NET Provider downgrade in the GAC, the gacutil is the recommended solution from Microsoft - it should be the 'clean' way to do this:

gacutil -u iAnywhere.Data.SQLAnywhere
gacutil -u iAnywhere.Data.SQLAnywhere.v3.5
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\gacutil.exe" -u iAnywhere.Data.SQLAnywhere.v4.0
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\gacutil.exe" -u iAnywhere.Data.SQLAnywhere.v4.5

You can also use SetupVSPackage /u from the SQL Anywhere \assembly\v2 and \assembly\v4.5 directories to uninstall all of the components (including the Visual Studio integration).

Then, you'll need to use gacutil or SetupVSPackage to reinstall the older copies of the assemblies.

Otherwise, uninstalling and reinstalling the ADO.NET SQL Anywhere components with an older EBF version is the solution to 'downgrade'.

(the latest version is used always).

This is likely due to the associated policy.* assemblies installed into the GAC, which have a binding redirect to the current SQL Anywhere version (which is the same version as the policy). You will need to remove the policy files from the GAC for this version binding in machine.config to work.

(25 Mar '13, 10:42) Jeff Albion


We have made some changes to fix this issue. The next EBF should have the fix.

(26 Mar '13, 13:49) Minghai Chang


I'm having the same issue in The problem began with I came across this page while researching the issue and I've been patiently waiting for the update to fix it. I really don't want to downgrade to fix the problem.

Any idea when this will be fixed?

(17 Apr '13, 16:51) ic3b3rg
Replies hidden

The EBF has been requested, but is still proceeding through QA currently.

If you would like to be advised when this EBF is released or would like to express to us a business case that you require this software prior to its release, you should open a technical support case with us so that we can work with you on those requirements and propose an arrangement for you to possibly test the software prior to its general release to ensure that it does indeed solve your issue.

(17 Apr '13, 17:13) Jeff Albion

I read through this page again. I missed the part about upgrading the database. So I executed File -> Upgrade Database and it fixed the problem.

(25 Apr '13, 09:02) ic3b3rg

This issue appears to have returned in - Does anyone else see this issue again?

(13 Jun '13, 13:50) PillowMetal
Replies hidden

I have the same issue with version

But I cannot say if the problem was really solved with version (as stated in Jeffs answer), since I upgraded from 3867 to 3895.

I haven't realized this yet, because my solution was to just add the corresponding database option.

(14 Jun '13, 04:34) Andre Hentschel

Please be more specific about the versions you are currently using as I had requested in the original comments:

  1. The version of the ADO.NET provider you are using
  2. The version of the SQL Anywhere database you are using
  3. The contents of your SYS.SYSHISTORY table

From what I have currently tested, both a non-upgraded 10.0.1 database running on a server, and an upgraded (ALTER DATABASE UPGRADE) 10.0.1 database on a server, with the ADO.NET provider, does not display an exception.

If there are different versions you are using, or are upgrading the database in a different way from an earlier version (or upgraded on a different version), please mention the exact steps you are using.

(14 Jun '13, 10:11) Jeff Albion

More specifically, I am using the iAnywhere.Data.SQLAnywhere.v4.5.dll provider version, and I am running SQL Anywhere Personal Server Version Here are the pertinent lines from my SYSHISTORY:

INIT,0,,,WXP #2600 SP 3 X86,6/1/2009 15:07:41,6/1/2009 15:07:41, LAST_START,0,,,W7 #7601 SP 1 X86_64,6/13/2013 11:38:32,6/13/2013 11:38:32,AT=0x20;DB=SAS;DM=VMware__Virtual_disk1.0; START,0,,,W7 #7601 SP 1 X86_64,6/13/2013 11:38:32,6/13/2013 11:38:32,AT=0x20;DB=SAS;DM=VMware__Virtual_disk1.0;

This database opened fine without exception for the last few years, until a few SQL Anywhere versions ago when this error started being reported here in the forum. Since then, my problem had never been resolved.

(14 Jun '13, 13:39) PillowMetal

The entry "INIT" with version "" and the lack of an "UPGRADE" entry shows that the database version is much older than the database server version, i.e. it is a v11 database running on a server. - Note, I'm not saying that this is a problematic configuration (and according to my understanding of Jeff's comment, it would be expected to be non-problematic), it's just a short conclusion of the SYSHISTORY contents.

Would it be possible to attempt to use ALTER DATABASE UPGRADE and then test whether the problem does still occur?

(15 Jun '13, 11:14) Volker Barth

For the record: Update: According to Jeff's updated answer, this is considered a problematic configuration:(

(17 Jun '13, 10:57) Volker Barth

In response to Jeff's Update 2:

the issue also occurs using the .NET 4.0 data provider.

Database server and data provider version:,

database was initialized with ver. 10.0.1 and upgraded to 12.0.1.

(18 Jun '13, 11:14) Andre Hentschel

This seems to have returned in v16.0.0.1535. Any client I update to that latest version exhibits the error. Is this a known issue?

(26 Sep '13, 13:03) JWilliston
Replies hidden

Yes, see my last update - from CR #741704, and up is required to resolve this issue.

Notably, new 16.0 Windows builds are not currently where you would expect to find them on the Sybase EBF download site - they are now just called 'Windows' instead of 'Windows x86/x64'

You can find ('SP5') here.

(26 Sep '13, 18:21) Jeff Albion
showing 5 of 15 show all flat view
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: 25 Mar '13, 08:56

question was seen: 5,151 times

last updated: 26 Sep '13, 18:21