ADO.NET Data Provider: AccessViolationException on calling stored proc via EF

[Former Member]

Update 3

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 (12.0.1.3910). On the server I tested first with 12.0.1.3152 and then also with the current version.

Results:

1. old version on server: no exception
2. new version on server: exception

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

---

Update 2

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.

---

Update 1

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 12.0.1.3152... 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 (12.0.1.3910).

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 12.0.1.3797 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 12.0.1.3851. 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:

• Is there a way to get more information about this error, and why it only happens for a specific data record?
• Should I care about this, since creating new data and calling the same stored procedure via EF doesn't throw this exception, and even other older test data works quite well in the same situation?

Thanks in advance.

[VolkerBarth]

You don't have any clue what makes that old test data record different from others?

[Former Member]

Not really. The stored procedure that is called and causes the exception, queries a list of data records (entityA) that belong to a list of other records (entityB). The records of entityB are related via parent-child relation, i.e. they form a tree structure (this is the reason, why I use a stored proc, since recursive queries are not supported by LinqToEntities).

The procedure uses common table expressions internally to get a list of primary key values of entityB that are then joined with the corresponding rows of entityA.

The query should return some rows for the test data record, that causes the exception.

So the test data record I was speaking of, is of type entityB, and the result of the stored proc call should be a list of entityA objects. So the cause of the exception may also be one of the records of type entityA in the resultset.

As I said, for other data structures of the same form, the procedure call succeeds.

(I hope this explanation didn't make things more complicated than they already were :D)

Could there be some hints in the server log files?

[VolkerBarth]

if the database is running as a service (dbsrv12). If I run it in a personal server (or something like that it is called) (dbeng12)

FWIW, I guess these are the common terms:

• dbsrvX is called the network database server
• dbengX is the personal database server
• both are database engines
• "Running as a service" means the database engine (either network or personal) is running as a OS process outside the current interactive user's session and will remain running when the user logs off (and can be started before any user logs in).

Based on your description, my understanding is that the query only fails when running against the network database server, not with the personal server. If so, is the database client/app running on the same box as the network database server, and is it using ShMem or TCP/IP?

[Former Member]

Thanks for clarification.

If the query is issued by the application, it fails with both the network and the personal server.

If I run the query in ISql (started from Sybase Central), the query fails with the network server (Sybase Central and ISql crashing), but it succeeds with the personal server.

Both servers run on the same machine on which the application/ISql is run.

The network service uses tcpip (started with "-x tcpip"), the personal server is started automatically via ODBC entry and seems to use ShMem (as stated in the log that is shown when clicking on the system tray icon).

My only guess, why it succeeds with the personal server using ISql, is that the blob data (varbinary column) is truncated, and only the first few bytes are read to be displayed in the result view.

[VolkerBarth]

FWIW, you can check with sa_conn_info()'s result column "CommLink" whether a particular connection is using TCP/IP or shared memory.

You might try whether DBISQL running against the personal engine will also crash if you output the result set to a file, as this should fetch the whole result set without truncation...

But in general, I hope the Sybase support staff can help tp provide more insight...

[Former Member]

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.

[VolkerBarth]

That's interesting: The fact that casting a too long binary value to a shorter type goes unnoticed seems to be due to option string_rtruncation set to 'Off';

At least the following third test query does behave differently when that according option is set or not:

-- build a 64.000 long binary string and try to truncate it
select byte_length(repeat('x', 64000));
select byte_length(cast(repeat('x', 64000) as long binary));
-- the following will return an error if the option is set
-- and will return 32.767 (the max length of type varbinary) otherwise
-- set temporary option string_rtruncation = 'On';
select byte_length(cast(cast(repeat('x', 64000) as long binary) as varbinary));

[VolkerBarth]

...So my real question is: Do you several databases (or DBISQL clients?) use different values for this option?

[Former Member]

This option is set to 'Off' for all our databases.

I just tested the described testcase again with string_rtruncate set to 'On' (using current server / ado.net client version), and no exception is raised at all. I would have expected a database-error raised by the cast from long binary to varbinary.

The binary data that is read (into a byte array) has the full length of the data in the database, but the data (an image) is corrupted (cannot be displayed again when written to file). I checked the byte array in debug mode expecting to see a lot of zero-bytes after 64kB, but this isn't the case, so nothing was truncated, but the data is also not the same as in the database.

I'm quite confused... this couldn't be the way the string_rtruncate option should work!?

[VolkerBarth]

Does it raise an exception when fetched from DBISQL (or dbisqlc, which I have used in my simple test)?

[Former Member]

When I call the stored procedure in dbisql with string_rtruncate temporary option = 'On', dbisql crashes without any error message (same as described in Update 2 of the original post).

But, again I also tested this without setting the temp. option (and database option set ot 'Off'), and this time dbisql did not crash, but shows me a message box that says "[Sybase][ODBC Driver]Data truncated". This contradicts the observation I made before, which I described in Update 2.