Assertion failure: MyClasses.pas, line 2651

upscene · Post by **upscene** » Tue 28 Mar 2006 06:50

Hi,

During a data transfer process, a customer reported the following.

Everything was working fine, then this started happening:

Error: Access violation at address 034267AB in module 'dbwc_mysql.dll'. Write of address 00000004

(in my code)

Next:
Opening source query [select * from IndexedSearch_default_words]
Error: Assertion failure (E:\Developing\Components\CrMyDAC\Source\MyClasses.pas, line 2651)

?

Opening source query [select * from IndexedSearch_docInfo]
Error: Assertion failure (E:\Developing\Components\CrMyDAC\Source\MyClasses.pas, line 2651)

And this continued for every table...

Any idea what suddenly could cause this assertion error?

--
Martijn Tonies
Upscene Productions

swierzbicki · Post by **swierzbicki** » Tue 28 Mar 2006 07:47

I had similar issues when adding new fields to my table while my exe was running... This may helps you ?

Ikar · Post by **Ikar** » Tue 28 Mar 2006 08:39

It seems like as lost link to TMySQLConnection object. But we can't provide any idea on how to get this error without changing MyDAC sources.

upscene · Post by **upscene** » Tue 28 Mar 2006 09:06

So the connection was lost?

Happening from the server side?

--
Martijn Tonies
Upscene Productions

Ikar · Post by **Ikar** » Tue 28 Mar 2006 10:41

This is not TCP connection lost, it seems like link to Delphi object lost.

upscene · Post by **upscene** » Tue 28 Mar 2006 16:19

Hmm, and what could cause that then?

No doubt, this is a bit hard to reproduce...

--
Martijn Tonies
Upscene Productions

GEswin · Post by **GEswin** » Tue 28 Mar 2006 21:47

I found this when modifiyng also tables and some client was connected... Imagine a query "Select * from table", and you modify table and add or delete a field, then when you refresh data of your query a new un-notified field is added or deleted, and fields are shifted. I would say only solution for this is before any operation recheck fields, but this would make mydac slow.

upscene · Post by **upscene** » Wed 29 Mar 2006 09:07

Could it be related to the ConnectionTimeout property? Or is that only used when attempting to connect?

--
Martijn Tonies
Database Developer Tools
Upscene Productions
http://www.upscene.com

Ikar · Post by **Ikar** » Thu 30 Mar 2006 08:32

It's hard to say.

The necessary conditions for this Assert are:
- This is single SELECT statement.
- FetchAll property is False.
Problem must appear only on closing underfetched datasets.

Do you use Connection.Pooling?

Try to reproduce this problem on small sample and send it to us.

upscene · Post by **upscene** » Thu 30 Mar 2006 14:27

No, I don't use pooling.

I do not modify the FetchAll property (as far as I can see).

And I have no idea what this means:

Problem must appear only on closing underfetched datasets.

--
Martijn Tonies
Upscene Productions

Ikar · Post by **Ikar** » Fri 31 Mar 2006 15:41

> I do not modify the FetchAll property (as far as I can see).

This error can appear only in FetchAll=False mode.

>> Problem must appear only on closing underfetched datasets.

In other words, if you set FetchAll to False, open large dataset and try to close it before reach for Eof.

As we can see, we can do nothing without example.

Guest · Post by **Guest** » Mon 10 Apr 2006 09:27

In other words, if you set FetchAll to False, open large dataset and try to close it before reach for Eof.

As we can see, we can do nothing without example.

This happens while transferring data from one MySQL db to another with a simple:

Code: Select all

while not qrySource.EOF 
do begin
  set parameter values ... 
  execute target INSERT statement, do error handling and so on
  qrySource.Next ... 
end;
qrySource.Close;

So I have no idea why the source dataset should get closed while it's not EOF yet.

Could there be something happening at the server side that could cause the source dataset to return True for EOF? For example, if the dataset is "open" for too long?

--
Martijn Tonies
Upscene Productions

upscene · Post by **upscene** » Mon 10 Apr 2006 09:34

Here, in the mids of a full data-transfer progress:

Opening source query [select * from DataForm_entryData]
Starting destination transaction...
Preparing destination query [insert into dataform_entrydata (DataForm_entryId, DataForm_fieldId, wobjectId, value) values (:p0, :p1, :p2, :p3)]
Transferring data...
Committing... [1000]
Committing... [2000]
Committing... [3000]
Error: Access violation at address 03F167AB in module 'dbwc_mysql.dll'. Write of address 00000004
Opening source query [select * from DataForm_field]
Error: Assertion failure (E:\Developing\Components\CrMyDAC\Source\MyClasses.pas, line 2651)

You see? It's happily transferring rows and all of the sudden, it get's an AV. The transfer process then proceeds to the next table, but the components raise an Assertion Failure op opening a source query.

It's MyDAC version 4.30.0.10
--
Martijn Tonies
Upscene Productions

Ikar · Post by **Ikar** » Wed 12 Apr 2006 08:42

> Could there be something happening at the server side that
> could cause the source dataset to return True for EOF? For
> example, if the dataset is "open" for too long?

It isn't likely.

Send us (mydac*crlab*com) please complete small sample to reproduce the problem

upscene · Post by **upscene** » Tue 25 Apr 2006 15:47

Done!

--
Martijn Tonies
Upscene Productions