Data Abstract server bug?

Data Abstract
1

First off - my current setup:

Elements 8.1.82.1695, using Oxygene for code.
DA/ROSDK 8.1.85.1143
Developing in VS 2013, on Windows 7

I have compiled a very “stock” DA service that runs on a remote server. Absolutely no custom code, everything is stock.

I’ve also compiled a class lib that I include w/ any client apps I write for this service.

Up until now, I’ve not ran into any server exceptions at all. The client app I’m writing now does automated data processing. its has a WinForms front end for monitoring the system, but could as well just be a service itself.

When a record is found that needs processing, it spawns a task, and in the task creates a datamodule that connects to my service. It does a simple DALINQ query to retrieve a single record from the database. The actually data processing can take anywhere beween a minute and a few hours depending on how fast the 3rd party system is we use for data processing. When complete, I simply call UpdateRow(myRecord); and ApplyChanges;

At this point the task terminates and waits for more records to process.

The problem I’m encountering is updating the database. When I hit ‘ApplyChanges’, I get the following error:

    RemObjects.DataAbstract.DAUpdatesFailedException occurred
  HResult=-2146233088
  Message=One or more updates failed to apply on the server.

R1050014, 2015: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

  Source=RemObjects.DataAbstract
  FromServer=false
  StackTrace:
       at RemObjects.DataAbstract.Linq.LinqDataAdapter.ThrowFailures(List`1 changes, String failureMessage)
  InnerException:

Could this be related in anyway to calling DA from a thread? I would assume that is perfectly acceptable. I’m completely confused by this behavior.

Any ideas? Suggestions?

Alan

2

Hello

First one, calling DA from a thread doesn’t affect everything. After all the exception happens on the server side, that is in no way affected by the threads on the client side.

Second one is that the AccessViolationException is not raised by managed code. It usually means that something is terribly wrong with some code that uses P/Invoke calls. See this thread for more details:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/4f48c152-68cd-45ec-a11e-baa7de7f79c3/attempted-to-read-or-write-protected-memory?forum=csharpgeneral

The worst thing is that not necessarily this exception is raised on the code line that caused it.

Still could you tell which database driver you use and provide us the stacktrace of this exception?

Thanks in advance

3

My DA server is working with Pervasive.SQL version 9.x via an ODBC driver. I have several apps using DA and this server, and this si the first time I’ve ever run into any exception.

Here is the exception details/stack trace:

RemObjects.DataAbstract.DAUpdatesFailedException occurred
HResult=-2146233088
Message=One or more updates failed to apply on the server.

R1050014, 2015: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Source=RemObjects.DataAbstract
FromServer=false
StackTrace:
at RemObjects.DataAbstract.Linq.LinqDataAdapter.ThrowFailures(List`1 changes, String failureMessage)
InnerException:

4

One other thing that confuses me more…

I make a simple test app where I pulled out the DALINQ code that retrieves the ad and updates the ad out of the thread and made two simple methods in the main thread of this app.

All the code runs fine without any exceptions. Same exact code.

I really don’t see how this can be related to any pInvoke/non-managed code problems.

5

Unrelated to this issue - the worst thing in the AccessViolationException that potentially it happens not on the code line that actually caused it (like OutOfMemory exception happens not on the code line that actually caused a memory leak).

Still could you attach debugger to the serer app and check where the execution fails? This stacktrace is not sent to the client.

6

I actually figured out the cause of this bug. It turns out the 3rd party who is processing our data was returning a field where we expected 10 characters, but was sending back 13 characters. Pervasive, at a low level, doesn’t do field-level checking for size, so what I believe was happening is that this was overwriting the adjacent field, which was causing some unexpected issues when trying to update the actual record in the database.

This was definitely a Pervasive specific issue but not caused by DA itself.

Thanks for your help.