Issue Details (XML | Word | Printable)

Key: DNET-846
Type: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Major Major
Assignee: Jiri Cincura
Reporter: Andreas Franz
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
.NET Data provider

Query´s to an older FB1.5-Server causes SQLDA-error

Created: 29/Aug/18 09:18 AM   Updated: 28/Oct/18 07:41 AM
Component/s: None
Affects Version/s: 6.2.0.0
Fix Version/s: None

Environment: Client: Windows 10 x64, Server: Windows Server 2016 with FB1.5.6.5026


 Description  « Hide
Sometimes (not reproducible) I get an non-specific "SQLDA"-error, if a simple query is send to an FB1.5 server. On server-side, there´s an error 10054 in logfile.
I can´t update to a newer Firebird-server version because of an older expensive special software with BDE-access.
Older providers (I guess <4.5) didn´t have this problem. I have updated provider to 6.2, because of an additional FB2.5-server I have to connect, too (in same application).
Is FB1.5 incompatible with newer providers? Are there any examples for detailled error-handling?


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Jiri Cincura added a comment - 29/Aug/18 09:25 AM
The communication is (or at least should be) backward compatible. But unless you can somewhat reliably reproduce it, I'm afraid I can't do much.

Andreas Franz added a comment - 29/Aug/18 10:00 AM
Thanks for your reply.

At the moment my "error-handling" is:
- closing the connection
- disposing the connection
- clear-all-pools
- opening a new connection
- fire the query again

It works - but it´s not really "clean". Any chance to get more specific error-message?

My query in real application looks like

   select * from kunden where kundennr in (select kundennr from anlagen where anlagennr in (select anlagennr from wartauft where erledigt='0')) order by kundennr

I´ve disabled pooling - error occurs less often, but it occurs.

I´ve tested to reproduce with a "dirty" stress-test code:

- open a connection
- fire a query with a random ID from an entry
- read result
- close the connection
- repeat this for 100000 times
- start this program multiple times on server-machine (to prevent any network problems)

Sometimes error occurs nearly at once - sometimes it takes hours and need multiple restarts.

regards, Andy

Jiri Cincura added a comment - 29/Aug/18 10:03 AM
Please share the complete exception (ex.ToString() is enough for start).

Andreas Franz added a comment - 29/Aug/18 10:23 AM
OK - I´ve modified my code from "ex.message" to "ex.tostring"

I´ll post the results.

Thanks a lot for your support!

Andreas Franz added a comment - 02/Sep/18 11:37 AM
Hallo Jiri,

after compiling my "Stresstest.exe" with your 6.2.0.0debug-Version I´ve found a bug in my code (because errors in firebird.log exists).
My code had closed "mydatareader" - indepent if my query has a result or not.
Closing a reader without result throws another exeption on FB1.5 server. I´ve fixed my bug - and even after 6000000 random queries with 6 parallel connections no error is occured.

I changed my code in productive tool, too - there´s no error since 3 days.

So I think my problem is gone - but if not, I´ll come back.

Thanks for your amazing work!

regards,

Andy

Andreas Franz added a comment - 03/Sep/18 05:02 AM
Hallo Jiri,,

now I´ve got an errormessage:

03.09.2018 04:44:43;FirebirdSql.Data.FirebirdClient.FbException (0x80004005): SQLDA error ---> SQLDA error
   bei FirebirdSql.Data.FirebirdClient.FbCommand.ExecuteReader(CommandBehavior behavior)
   bei Stresstest.Datenbank.query(String mySelectQuery) in C:\Users\andreas.franz.STFRANZ\Documents\SharpDevelop Projects\Stresstest\Stresstest\Datenbank.vb:Zeile 48.;Microsoft.VisualBasic.ErrObject;DB;Stresstest

Line 48 shows:

myreader=myCommand.ExecuteReader(CommandBehavior.CloseConnection)

I´ve removed CommandBehavior.CloseConnection now - another test is in progress ....

regards,

Andy

Jiri Cincura added a comment - 05/Oct/18 02:17 PM
No further communication so far. Will reopen if somebody provides a reproducible test case.

Andreas Franz added a comment - 28/Oct/18 07:41 AM
Hallo Jiri,

since 6.3.0.0 no single error occured. Seems my problem is gone.

Thanks a lot!

regards,

Andy