Tim

I'm getting wierdo's again

Just open and close my app (involves login & display of the emails form) and I get

FastMM has detected an attempt to call a virtual method on a freed object. An access violation will now be raised in order to abort the current operation.
Freed object class: TEDBColumn
Virtual method: Destroy
Virtual method address: 578AC8
The allocation number was: 306394

In this case it explodes

Recount.UnPrepare; <<<<<<<<<< here
Recount.Close;


Try to display an email and I get

FastMM has detected an attempt to call a virtual method on a freed object. An access violation will now be raised in order to abort the current operation.
Freed object class: TEDBIndexedLocalCursor
Virtual method: Destroy
Virtual method address: 5DBFF8
The allocation number was: 350679

It has something to do with this

Recount.Close;
Recount.ParamByName('USERID').AsString := HHCommons.UserID;
Recount.ExecScript; <<<<<<<<< WAM
Recount.Close;

I run this in the forms OnCreate to switch to the active disk database

Recount.SQL.Text := StringReplace(Recount.SQL.Text, '$Disk', dm.DB.Database, [rfReplaceAll]);

To save you asking. The script runs fine in EDBManager if I alter $Disk to NLH-Live and it was running fine yesterday. The only change I've made so far today is to drop a TAdvStatusBar onto the form. I opened it to see if I liked the position and WAM. I've since removed the TAdvStatusBar but things are still bad.

What can I do?

Roy Lambert


 object Recount: TEDBScript
   DatabaseName = 'Memory'
   SessionName = 'TfRSession'
   SQL.Strings = (
     'SCRIPT(IN USERID VARCHAR)'
     'BEGIN'
     ''
     ' DECLARE SQLStatement VARCHAR;'
     ' DECLARE InfoCursor SENSITIVE CURSOR FOR InfoStmt;'

       ' DECLARE ResultCursor SENSITIVE CURSOR WITH RETURN FOR ResultStm' +
       't;'
     ''

       ' PREPARE InfoStmt FROM '#39'SELECT * FROM Information.Tables WHERE N' +
       'ame = '#39#39'emCounts'#39#39#39';'
     ' OPEN InfoCursor;'
     ''
     ' IF (ROWCOUNT(InfoCursor) > 0) THEN'
     '  EXECUTE IMMEDIATE '#39'DROP TABLE emCounts'#39';'
     ' END IF;'
     ''
     ' CLOSE InfoCursor;'
     ''
     ' SET SQLStatement = '#39'CREATE TABLE emCounts AS'
     ' SELECT _BoxNo ,'
     ' _BoxName,'

       ' (SELECT COUNT(_fkMailBoxes) from "$Disk".EMails WHERE _fkMailBo' +
       'xes = MailBoxes._Boxno'
     ' AND'

       ' (EMails._Private = FALSE OR EMails._fkUsers = '#39#39#39'+USERID+ '#39#39#39'))' +
       ' AS _OnFile ,'
    
       ' (SELECT COUNT(_fkMailBoxes) from "$Disk".emReadStatus WHERE _fk' +
       'Users = '#39#39#39'+USERID+ '#39#39#39' AND _fkMailboxes = MailBoxes._Boxno) AS ' +
       '_Read,'
     ' 0 AS _Unread'
     ' FROM "$Disk".MailBoxes'
     ' WHERE _Monitored = TRUE'
     ' WITH DATA'#39';'
     ''
     ' PREPARE ResultStmt FROM SQLStatement;'
     ''
     ' EXECUTE ResultStmt USING USERID, USERID;'
     ''

       ' EXECUTE IMMEDIATE '#39'UPDATE emCounts SET _Unread = _OnFile - _Rea' +
       'd'#39';'
     ' EXECUTE IMMEDIATE '#39'CREATE INDEX PK ON emCounts (_BoxNo)'#39';'
     ''
     'END')
   Params = <>
   Left = 536
   Top = 248
 end

Tim


I've tried deinstalling and reinstalling ElevaeDB no joy.

I've attached the leak report from FastMM in case it helps track things down, and if you can suggest anything I can do to try and spot the problem please let me know. I'm bollixed until this is sorted.

Roy Lambert

Roy,

<< Just open and close my app (involves login & display of the emails form)
and I get >>

Does this happen every time ?  If so, can you send me the application source
?  It's something environmental, because I couldn't reproduce it here using
the script that you posted earlier.

And you are using B2 now, correct ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Yup, b2. I can send the app source but it uses TMS components plus a few other 3rd Party components, do you still want it?

I've just reinstalled b1 and the apps fine so its something different between b1 and b2

Maybe whatever you changed was altered back in b3

Roy Lambert

Roy,

<< Yup, b2. I can send the app source but it uses TMS components plus a few
other 3rd Party components, do you still want it?

I've just reinstalled b1 and the apps fine so its something different
between b1 and b2

Maybe whatever you changed was altered back in b3 >>

It's possible.  Maybe the best bet is to try B3 when it is released, and
proceed from there.  Right now we are probably comparing apples to oranges,
and I know that I've made some changes in B3 with respect to direct database
references.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


> Maybe whatever you changed was altered back in b3 >>
>
>It's possible. Maybe the best bet is to try B3 when it is released, and
>proceed from there. Right now we are probably comparing apples to oranges,
>and I know that I've made some changes in B3 with respect to direct database
>references.

Sounds the best approach. I'd still like to know what the hell can cause this sort of effect. I've never seen it before, and hope to never again. If you have any ideas what can cause it please let me know.

Roy Lambert

Tim


Problem still exists in 2.01b1. I'm trying to track it down beyond the ExecScript and failing dismaly

Roy Lambert

Tim

Found the reason. I altered the script

from
DECLARE ResultCursor SENSITIVE CURSOR WITH RETURN FOR ResultStmt;

to
DECLARE ResultCursor SENSITIVE CURSOR FOR ResultStmt;

This is prepared from SET SQLStatement = 'CREATE TABLE emCounts AS.......

and I access emCounts outside of the script after I've closed it.

emCounts.Close;
Recount.Close;
Recount.ParamByName('USERID').AsString := HHCommons.UserID;
Recount.ExecScript;
Recount.Close;
emCounts.IndexName := 'PK';
emCounts.Open;


It explains why I couldn't get it to blow up in EDBManager. I still don't know what's happening, but I don't think it should.


Roy Lambert

--  The script --------------------------------------------------------------------------------------------------------------------------------------
SCRIPT(IN USERID VARCHAR)
BEGIN

DECLARE SQLStatement VARCHAR;
DECLARE InfoCursor SENSITIVE CURSOR FOR InfoStmt;
DECLARE ResultCursor SENSITIVE CURSOR FOR ResultStmt;

PREPARE InfoStmt FROM 'SELECT * FROM Information.Tables WHERE Name = ''emCounts''';
OPEN InfoCursor;

IF (ROWCOUNT(InfoCursor) > 0) THEN
 EXECUTE IMMEDIATE 'DROP TABLE emCounts';
END IF;

CLOSE InfoCursor;

SET SQLStatement = 'CREATE TABLE emCounts AS
SELECT _BoxNo ,
_BoxName,
(SELECT COUNT(_fkMailBoxes) from "$Disk".EMails WHERE _fkMailBoxes = MailBoxes._Boxno
AND
(EMails._Private = FALSE OR EMails._fkUsers = '''+USERID+ ''')) AS _OnFile ,
(SELECT COUNT(_fkMailBoxes) from "$Disk".emReadStatus WHERE _fkUsers = '''+USERID+ ''' AND _fkMailboxes = MailBoxes._Boxno) AS _Read,
0 AS _Unread
FROM "$Disk".MailBoxes
WHERE _Monitored = TRUE
WITH DATA';

PREPARE ResultStmt FROM SQLStatement;

EXECUTE ResultStmt USING USERID, USERID;

EXECUTE IMMEDIATE 'UPDATE emCounts SET _Unread = _OnFile - _Read';
EXECUTE IMMEDIATE 'CREATE INDEX PK ON emCounts (_BoxNo)';

END

Roy,

<< Found the reason. I altered the script

from
DECLARE ResultCursor SENSITIVE CURSOR WITH RETURN FOR ResultStmt;

to
DECLARE ResultCursor SENSITIVE CURSOR FOR ResultStmt;

This is prepared from SET SQLStatement = 'CREATE TABLE emCounts AS.......

and I access emCounts outside of the script after I've closed it. >>

That would do it - a CREATE TABLE does not return a cursor, so expecting
there to be one when the script is done is incorrect.  It would be nil.
I'll see if I can somehow put a catch in there for this and display an error
instead.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


> and I access emCounts outside of the script after I've closed it. >>
>
>That would do it - a CREATE TABLE does not return a cursor, so expecting
>there to be one when the script is done is incorrect. It would be nil.
>I'll see if I can somehow put a catch in there for this and display an error
>instead.

Just to make sure you're not heading down the wrong road things exploded when I went to run the script not outside of it, and it seemed to be only after another running the mark as read procedure. This is what took me so long to track the little beastie down. I could run the procedure calling the script several times one after the other and nothing went wrong. As soon as it ran as part of the mark as read procedure kerpow.

I still don't really know what's triggering the problem.

Roy Lambert

ps

This will teach me to cut'n'paste from an example where I don't understand it - guess who's example I was following <vbg>