Assertion failure: MyClasses.pas, line 2651

Antaeus · Post by **Antaeus** » Thu 27 Apr 2006 08:54

Thank you for sample. We have reproduced this problem and fixed it. This fix will be included in the next MyDAC build.

upscene · Post by **upscene** » Thu 27 Apr 2006 09:37

Excellent. Luckily, the problem was easy to reproduce

Any estimated release date? Or is there anything I can do to re-compile the source and fix the problem?

--
Martijn Tonies
Upscene Productions

Antaeus · Post by **Antaeus** » Thu 27 Apr 2006 12:10

We have sent you the patch to fix this problem by e-mail.

upscene · Post by **upscene** » Thu 27 Apr 2006 12:26

Right, I've tried the patch and although it doesn't return an Access Violation, it now says "lost connection during query". So my data-transfer process is still aborted.

What could cause this?

--
Martijn Tonies
Upscene Productions

Antaeus · Post by **Antaeus** » Fri 28 Apr 2006 06:07

We have reproduced Access violation only after killing process on the server. This way we emulated lost connection to the server.
You can get "lost connection during query" error because of unstable connection to your MySQL server or any other reasons that are described in this section of MySQL Reference Manual.

upscene · Post by **upscene** » Fri 28 Apr 2006 08:28

You might want to read my e-mail on that...

Here's what I wrote:

I've done some monitoring at the server side.

If I start the test app, 1 connection is opened.

If I start the transfer, 1 additional connection is opened and
it executes the SELECT query.

Next, at some point in time, the SELECT finishes and the
connection for it is cleaned up (closed): it disappears from
the monitor.

From this point, it seems the application starts "processing".

After 3 minutes and 16-18 seconds, I get the error "lost
connection to server" when, apparently, reading/handling
the result. Which is weird, cause I can see the connection
was gone already.

From the monitor, I can still see 1 connection to the MySQL
server.

So, what is going on here? Is this error raised properly? Or
shouldn't it actually happen? Could it be that the .Next
triggers it?

Yes, the AV is fixed, but there's still something wrong here.
--
Martijn Tonies
Upscene Productions

Antaeus · Post by **Antaeus** » Fri 28 Apr 2006 13:00

> If I start the test app, 1 connection is opened.
This is main connection.

> If I start the transfer, 1 additional connection is opened
This connection is created in FetchAll=False mode. FetchAll is set automatically to False when UniDirectional is set True.

> it disappears from the monitor.
MyDAC doesn't close additional connection until all data is fetched. This means that the connection was closed by someone else. Most possibly this is MySQL server.

> Is this error raised properly?
We think that in the situation you have described error is raised properly. We don't get the error without any additional actions using your test application.

> Or shouldn't it actually happen?
When data is being fetched, MyQuery gets message from the network that the connection is closed. This raises error.

upscene · Post by **upscene** » Fri 28 Apr 2006 13:54

> it disappears from the monitor.
MyDAC doesn't close additional connection until all data is fetched. This means that the connection was closed by someone else. Most possibly this is MySQL server.

I see the connection disappear, but after that, the application continues fetching data. "FetchRows" = 25, but I've seen if fetch hundreds of rows!

The error seems to happen after 03:16 always.

The timeout on the server is the default number of seconds, which is much larger than that.

Really, how can this happen? How do you explain the monitor not showing the (additional) connection while it continues to fetch data?

--
Martijn Tonies
Upscene Productions

Antaeus · Post by **Antaeus** » Fri 28 Apr 2006 14:53

Before connection was closed, MySQL server had put to the network some data (it can be a huge number of records). MyDAC doesn't know when exactly connection was closed, it determines it on getting error code from the network after fetching all cached data from network buffer.

upscene · Post by **upscene** » Mon 01 May 2006 10:49

OK, understood.

But then what can cause the server to close the connection? As I said, the normal server side timeout was the default, which is much more than 3 minutes.

--
Martijn Tonies
Upscene Productions

Antaeus · Post by **Antaeus** » Wed 03 May 2006 09:21

Please send us system variables of your server. You can see them in Info sheet of TMyConnection Editor.

upscene · Post by **upscene** » Thu 04 May 2006 06:22

In the project I sent you, you have access to that server so that will get you the actual server variables.

--
Martijn Tonies
Upscene Productions

upscene · Post by **upscene** » Fri 19 May 2006 13:24

No results so far?
--
Martijn Tonies
Upscene Productions

Ikar · Post by **Ikar** » Thu 25 May 2006 12:33

We have dedicated lot of time to this issue and tested it thoroughly. This appears to be a server OS problem (MySQL server settings are OK). We have reproduced this problem using standard libmysql.dll (Direct = False) and using standard dbExpress driver, which works through the libmysql.dll as well.

We have determined in which case client loses connection to server. Losing connection happens only if client slowly reads more than 155 KB from server. If client reads data without calling Sleep(), losing connection doesn't happen. It seems like a server OS forcibly closes slow connections.

upscene · Post by **upscene** » Mon 29 May 2006 16:43

Hmm, that's odd...

In this particular case, as you can see, my application is transferring data from database A to database B, so a delay when reading records always happens.

So is this is a typical MySQL issue or a server OS issue. Weird.

So ... no chance I could fix this then?
--
Martijn Tonies
Upscene Productions