DA bug found yester

Data Abstract
1

I had a compiled DA server service in place that worked via ADO.NET with a Pervasive.SQL database. This service integrates with several client apps so the functionality is very important. As of yesterday, it was compiled using DA for .NET version 9.2.0.1309, a pre-9.2 beta release.

Yesterday I had to add support for a handful of new fields in a given table. I modified the servers schema, and ran into issues with the VS integration, so I figured it was a good time to update to the official 9.2 release, and did just that. Upgrading to the official 9.2 release solved the VS integration issue, and then I did a full rebuild, plus updated my client class lib DLL and rebuilt that also.

after doing this, later in the day I got many emails stating that the client application(s) were not working properly and generating errors for everyone. Inserts were not working, and it appears as if the data in the table record I sent to the da server for an insert - the corresponding INSERT SQL was not filling in the parameters for the insert. Unfortunately in my rush to get this fixed yesterday, I did not save an exception log.

I proceeded to upgrade the server to the latest 9.3 beta and unfortunately found the same exceptions occurring.

All I could do is revert back to the beta 9.2 release I had initially installed. Rebuilding the server under this release allowed things to working properly once again.

Has anything like this been reported for either 9.2 or 9.3?

2

Hello

Perhaps it would be better to send a mail to support@ so we could work on pinpointing the issue together.
The parameters mapping code has been reworked, so it is quite possible that some changes unintentionally affect the Prevasive SQL too.

While sending the mail to support@ please attach the custom .daConfig file if you use one and the connection string you use (be sure to replace user id and password with some placeholders for security reasons)

Thanks in advance

3

Hello again

A similar issue could happen if a stored procedure’s parameter has its type set to Xml while the client app passes its value as a plain string.
The workaround is to correct the parameter’s type to string. Or you can wait for the next Beta build that will handle such cases internally so no changes will be needed.

Sorry for the inconvenience.