VB6 app returns C++ error R6025 pure virtual function call

[Glasgow]

I have a VB6 application that returns this error (R6025 pure virtual function call) in a window entitled Microsoft Visual C++ Runtime Library.

I don't know where to start debugging this.

Any ideas?

Thanks in advance.

 

[AEtherson]

you have a provblem with a refrence to a c dll. A virtual function is a pointer to function in a class

 

[Glasgow]

Thanks. It seems to be related to an ADO recordset open - it crashes as it executes the statement under certain circumstances.

 

[AEtherson]

try upgrading mdac

also check your refs and mack sure that one does not say missing

 

[Glasgow]

I'm already on MDAC 2.8.

 

[AEtherson]

what circumstances does it crash??

 

[Glasgow]

Hmmm. Good question.

1. User navigates records using datagrid bound to recordset using client-side cursor.
2. User creates new record and attempts to move to new one.
3. WillMove event traps this & prompts user 'save changes?'.
4. User specifies 'yes' & changes are saved.
5. The record the user selected becomes current record.
6. User immediately returns to the record just created above.
7. As soon as user attempts change, code attempts lookup on database to check no-one has changed the underlying data since the client-side recordset was retrieved/ refreshed.
7. Crash!

 

[AEtherson]

try downgrading mdac to 2.5

and making sure u do not have a circular refrence

IE you make a change then the bound control does a change and so on

Failing that you will have to post your code so we can look at it for you

 

[Glasgow]

It still crashes under MDAC 2.5.

To be honest,I think there IS an underlying problem of a recursive nature where the WillMove event is effectively triggering itself. Although the recursion should have 'resolved itself' by the time of the crash, I think it could be indirectly responsible for some 'confusion'.

I wish the code were simple enough to post but there are reams of the stuff!

 

[Glasgow]

I have now eliminated the recursion (WillMove indirectly triggering another WillMove) and the problem has been resolved.

Thanks again for the input.