I tested different combinations of data provider/network service configurations, where the server runs on another machine than the client. On the client I used the current version (18.104.22.16810). On the server I tested first with 22.214.171.12452 and then also with the current version.
I also tested the stored procedure call using ISql, which results in the same behavior as described in Update 2 (Sybase Central and ISql crashing without any error message). This was tested with the new version on the server only.
So this could be an issue with the database engine itself, at least when using the current version server and client (old server/new client and new server/old client doesn't cause the exception).
I tried to call the stored procedure via isql with the same parameters my application uses, and this also causes an error. But in a more dramatic way: ISQL and SQL Central both just crash (they vanish without any error message).
But this happens only, if the database is running as a network service (dbsrv12). If I run it in a personal server (dbeng12), the query result window of ISQL shows the proper result with the message, that the binary data is truncated.
So this seems to be a problem that is not caused by the ADO.NET data provider after all.
I recently encountered the described exception when the stored procedure is called on other test data objects, which I think prooves the assumption, that this is a data-specific error, wrong.
The exception is always thrown, when the rows in the result set contain any binary data. The existence of that binary data is optional, and in most cases there is none, which seems to be the reason that I didn't encounter this problem earlier and more often.
I'm using Entity Framework (4.4) with the data provider for SQL Anywhere in a project that I started about a year ago (the data provider version that I started with was 126.96.36.19952... I guess).
Over the time I upgraded the data provider version every now and then and also had a support case running for a specific bug in the data provider. At the moment I' using the current version (188.8.131.5210).
I also used the same development test database over the time, that contains a lot of test data that accumulated over time, and was inserted using the various data provider versions.
When testing the current data provider version, I came across an AccessViolationException, that is thrown only when a stored procedure call is made on a specific (quite old) test data record. This data record was created December last year and I think I was using 184.108.40.20697 at that time.
Here is the stacktrace of the exception:
System.AccessViolationException was unhandled Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Source=iAnywhere.Data.SQLAnywhere.v4.0 StackTrace: at iAnywhere.Data.SQLAnywhere.PInvokeMethods.AsaDataReader_FetchRows(Int32 idReader, Int32& rowsObtained, IntPtr& values) at iAnywhere.Data.SQLAnywhere.SADataReader.Read() at iAnywhere.Data.SQLAnywhere.SADataReader..ctor(SAConnection conn, CommandBehavior cmdBehavior, Int32 idReader, Int32 recordsAffected, SACommand cmd, Boolean isFake) at iAnywhere.Data.SQLAnywhere.SACommand._ExecuteReader(CommandBehavior commandBehavior, Boolean isExecuteScalar, Boolean isBeginExecuteReader) at iAnywhere.Data.SQLAnywhere.SACommand.ExecuteDbDataReader(CommandBehavior behavior) at System.Data.Common.DbCommand.ExecuteReader(CommandBehavior behavior) at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior) at System.Data.Objects.ObjectContext.CreateFunctionObjectResult\[TElement\](EntityCommand entityCommand, EntitySet entitySet, EdmType edmType, MergeOption mergeOption) at System.Data.Objects.ObjectContext.ExecuteFunction\[TElement\](String functionName, MergeOption mergeOption, ObjectParameter parameters) at System.Data.Objects.ObjectContext.ExecuteFunction\[TElement\](String functionName, ObjectParameter parameters) .....
I tested the same procedure call with different data provider versions and it occurs starting with 220.127.116.1151. With the previous version (3797) no exception is thrown (versions in between, if there are any, I have not tested). Later versions (up to the current) all throw the exception.
So my questions are:
Thanks in advance.
I found the cause of the AccessViolationException:
in the described stored procedure I defined the data type for the binary data column as varbinary, while the actual data type of the table that is queried is long binary. My test binary data was larger than the maximum data a varbinary can hold, which should be the cause for the exception.
I guess I got fooled around by the fact, that with older server/client versions all worked perfectly (even if the queried data was larger than varbinary(max)).
The fact that this worked with older versions leaves me still somewhat confused, but by adjusting the returned data type of the procedure I fixed the problem, and so I will mark this question as answered for now.
If someone has any further knowledge about this, feel free to post it here.
answered 08 Jul '13, 11:14