on 2013 Mar 25 8:56 AM
Hi,
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 (12.0.1.3867).
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.
Request clarification before answering.
Update 3: This issue is now resolved in CR #741704, 12.0.1.3923, 16.0.0.1581.
Update 2: I have now been able to reproduce this issue 12.0.1.3895 with the .NET 4.5 Provider, with an 11.0.1.2222 database, running on a 12.0.1.3895 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 12.0.1.3876 and 16.0.0.1491
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 12.0.1.3856.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Many thanks for the reply.
The database version is also 12.0.1.3867. 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.
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.
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.
This issue appears to have returned in 12.0.1.3895 - Does anyone else see this issue again?
Please be more specific about the versions you are currently using as I had requested in the original comments:
SYS.SYSHISTORY
tableFrom what I have currently tested, both a non-upgraded 10.0.1 database running on a 12.0.1.3895 server, and an upgraded (ALTER DATABASE UPGRADE
) 10.0.1 database on a 12.0.1.3895 server, with the 12.0.1.3895 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.
More specifically, I am using the iAnywhere.Data.SQLAnywhere.v4.5.dll provider version 12.0.1.38954, and I am running SQL Anywhere Personal Server Version 12.0.1.3895. Here are the pertinent lines from my SYSHISTORY:
INIT,0,,11.0.1.2222,WXP #2600 SP 3 X86,6/1/2009 15:07:41,6/1/2009 15:07:41, LAST_START,0,,12.0.1.3895,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,,12.0.1.3895,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.
The entry "INIT" with version "11.0.1.2222" 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 12.0.1.3895 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?
Yes, see my last update - from CR #741704, 16.0.0.1581 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 16.0.0.1644 ('SP5') here.
User | Count |
---|---|
60 | |
10 | |
8 | |
8 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.