BIG CRASH on .next() with SQL Server [EDITED]

[Jeweller]

Hello,
I experience a big crash of my application (full crash, processus died); EOLEDBError with the following case. Im using UniDac 6.1.3 with SQL Server provider (mssql2014, Windows 7).
When call a TUniqQuery.next() I get the crash with the following :

Code: Select all

    UniConnection2.open;
    UniQuery7.Open; //SELECT ONE ROW
    while not UniQuery7.eof do
    begin
        UniConnection2.StartTransaction;
        UniQuery8.ExecSQL; //UPDATE THE ROW OPENED WITH QUERY7
        UniConnection2.Commit;
        UniQuery7.next; //HERE IS THE CRASH
    end;
    UniQuery7.close;

Does someone get the same behavior ? How to avoid this (I you remove starttransation its ok, but cant do that so easyly) ?
regards
I do not reproduce it with the Oracle provider.

[azyk]

Unfortunately, we couldn't reproduce the issue according to your recommendations. Please compose a complete sample project, on which the issue is reproduced, and send it to andreyz*devart*com, including the script for creating the test table.

[Jeweller]

Ok, I've sent to you the demo to reproduce the behavior. Hope this help.
regards

[Jeweller]

Hello,
Any advise about this problem? Im still migrating from ADO to UNiDac and this problem occurs in different situation for me, and Im worried about because if there is no bug I do not see how to avoid it ! Can you reproduce the behavoir ?
-I do not know how to get support for registered user-
Regards,
Michael

[azyk]

Unfortunately, I haven't received any emails from you. Please try to resend this sample to my e-mail andreyz*devart*com from another mailbox or using the contact form on our website: http://www.devart.com/company/contactform.html.

[Jeweller]

Done. Tell me if you have any problem to get the demo or make it work.
Best regards

[azyk]

We have received your test sample and reproduced the described error message. To avoid the error, in your sample, set the CursorType dataset property to ctStatic before opening the dataset, in which you are executing the SELECT query. For example:

Code: Select all

    UniConnection2.open;
    UniQuery7.SpecificOptions.Values['SQL Server.CursorType']:= 'ctStatic'; // insert code here
    UniQuery7.Open;
    ....

[Jeweller]

Yes, that works! Tanks a lot.
Does the crash of the app be a "normal" behavoir or can we expect some others in a next release of unidac?

But I do not understand extacly, do are the same between "CursorType" and "SQL Server.CursorType" ? (I mean so). Where can I find any advise about managing cursor type and location with UniDAC/SQLServer? I do not find any tips in your doc (https://www.devart.com/unidac/docs/?sqlprov_article.htm) ?
I thought ctDefaultResultSet choice (the default one?) was an equivalent of "ctOpenForwardOnly" we had previously with ADO. This is the one I would like to use. Does ctKeyset a better choise by default (like standard ADO component)? What are your advise about these parameters or where can I find any information that can help how to choose appropriates one (I do not use any visual component liked to my queries) ?
I some case I had to switch beetween client cursor and server cursor... Is it possible to do the same with unidac ?

Thanks for your help ?

[EDIT] I would like to set cursortype to static for every of my queries (I have 1000 of queries in 100 of datamodules!) because I cannot easyly see where I need to do this changes, but I really can't instead of having a lot of other bad behaviors... Any advise instead of read again all my source code (that would be almost impossible and means the migration from ADO to uniDAC will cost a lot more than expected for us!!)? Note we have our own TXXQuery descendant, so we have a way to adjust and translate params without rewriting all[/EDIT]

[azyk]

'SQL Server' in SpecificOptions 'SQL Server.CursorType' means the provider name, which the CursorType option belongs to. In UniDAC, not all the providers support this option, but only the SQL Server provider does.

See the detailed description of the cursor types in UniDAC for SQL Server in our online documentation at: https://www.devart.com/sdac/docs/?devar ... ortype.htm.

We are currently investigating the reason for the described behavior for the ctDefaultResultSet cursor type. If we are able to change this behavior, you will no more need to change the cursor type from ctDefaultResultSet to ctStatic in all the datasets of the migrating project, that you are talking about. We will notify you about the results as any are available.