Page 1 of 3
Assertion failure: MyClasses.pas, line 2651
Posted: Tue 28 Mar 2006 06:50
by upscene
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
Posted: Tue 28 Mar 2006 07:47
by swierzbicki
I had similar issues when adding new fields to my table while my exe was running... This may helps you ?
Posted: Tue 28 Mar 2006 08:39
by Ikar
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.
Posted: Tue 28 Mar 2006 09:06
by upscene
So the connection was lost?
Happening from the server side?
--
Martijn Tonies
Upscene Productions
Posted: Tue 28 Mar 2006 10:41
by Ikar
This is not TCP connection lost, it seems like link to Delphi object lost.
Posted: Tue 28 Mar 2006 16:19
by upscene
Hmm, and what could cause that then?
No doubt, this is a bit hard to reproduce...
--
Martijn Tonies
Upscene Productions
Posted: Tue 28 Mar 2006 21:47
by GEswin
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.
Posted: Wed 29 Mar 2006 09:07
by upscene
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
Posted: Thu 30 Mar 2006 08:32
by Ikar
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.
Posted: Thu 30 Mar 2006 14:27
by upscene
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
Posted: Fri 31 Mar 2006 15:41
by Ikar
> 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.
Posted: Mon 10 Apr 2006 09:27
by Guest
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
Posted: Mon 10 Apr 2006 09:34
by upscene
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
Posted: Wed 12 Apr 2006 08:42
by Ikar
> 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
Posted: Tue 25 Apr 2006 15:47
by upscene
Done!
--
Martijn Tonies
Upscene Productions