Access violation when using TQuery??

Hi,

I am getting an access violation (faulted with message 'access violation at 0x4da2ef6d: read of address 0xeeaed7e8') when exiting my Delphi 7 application. This only happens when a particular TQuery component (used to query a SQL Server db and populate a tabsheet) is opened *after* a TStoredProc object's ExecProc method has been called. No access violation occurs when exiting the application if:
- ExecProc was not called (doesn't matter how many times the query was opened)
or
- That specific query was not opened after ExecProc was called

Weird thing is, the problem only occurs with a particular TQuery, but seems to happen after *any* TStoredProc's ExecProc method has been called. I am explicity closing the query before opening it, setting the TStoredProc to inactive after calling, and closing all database connections. I have also removed references to components such as the Crystal VCL, but the problem persists. I trace into the code and it gets to the 'end.' line of the project code (source) and then I get the access violation(!)

Any ideas why this might be happening? I have tried everything I can think of but haven't found a solution, short of avoiding the triggering sequence of events altogether. Please help! Thanks in advance.

Comments

  • dont know how you writen it but usually access violation popsup if client is accessing the server and client cant connect to server for lots of reasons, maybe too many connections in one client -> server and exceeded the total amount of connection allocated, sharing error, you have no proper access rights from server point of view, you have a bad connection, LAN card cannot acomodate all traffic (in/out), etc... but all means you cannot connect to server
  • : Hi,
    :
    : I am getting an access violation (faulted with message 'access violation at 0x4da2ef6d: read of address 0xeeaed7e8') when exiting my Delphi 7 application. This only happens when a particular TQuery component (used to query a SQL Server db and populate a tabsheet) is opened *after* a TStoredProc object's ExecProc method has been called. No access violation occurs when exiting the application if:
    : - ExecProc was not called (doesn't matter how many times the query was opened)
    : or
    : - That specific query was not opened after ExecProc was called
    :
    : Weird thing is, the problem only occurs with a particular TQuery, but seems to happen after *any* TStoredProc's ExecProc method has been called. I am explicity closing the query before opening it, setting the TStoredProc to inactive after calling, and closing all database connections. I have also removed references to components such as the Crystal VCL, but the problem persists. I trace into the code and it gets to the 'end.' line of the project code (source) and then I get the access violation(!)
    :
    : Any ideas why this might be happening? I have tried everything I can think of but haven't found a solution, short of avoiding the triggering sequence of events altogether. Please help! Thanks in advance.
    :
    This is nasty, but have you already used the: menu option?
    This might give you the right insight. You have to put the $4da2ef6d adress in there. The error might be caused by some buggy component. I one had some same kind of a problem, and I solved it by destroying the datamodule (if you have one) after the Application.Run myself. There is also a Delphi 7 update, which might solve this problem.


  • : : Hi,
    : :
    : : I am getting an access violation (faulted with message 'access violation at 0x4da2ef6d: read of address 0xeeaed7e8') when exiting my Delphi 7 application. This only happens when a particular TQuery component (used to query a SQL Server db and populate a tabsheet) is opened *after* a TStoredProc object's ExecProc method has been called. No access violation occurs when exiting the application if:
    : : - ExecProc was not called (doesn't matter how many times the query was opened)
    : : or
    : : - That specific query was not opened after ExecProc was called
    : :
    : : Weird thing is, the problem only occurs with a particular TQuery, but seems to happen after *any* TStoredProc's ExecProc method has been called. I am explicity closing the query before opening it, setting the TStoredProc to inactive after calling, and closing all database connections. I have also removed references to components such as the Crystal VCL, but the problem persists. I trace into the code and it gets to the 'end.' line of the project code (source) and then I get the access violation(!)
    : :
    : : Any ideas why this might be happening? I have tried everything I can think of but haven't found a solution, short of avoiding the triggering sequence of events altogether. Please help! Thanks in advance.
    : :
    : This is nasty, but have you already used the: menu option?
    : This might give you the right insight. You have to put the $4da2ef6d adress in there. The error might be caused by some buggy component. I one had some same kind of a problem, and I solved it by destroying the datamodule (if you have one) after the Application.Run myself. There is also a Delphi 7 update, which might solve this problem.
    :
    :
    :
    Thank you for the suggestions! I actually did end up pinpointing the line of code that was causing this (really the lack of a line of code; once I added a line to specifically free the stored procedure object, it seemed to work fine.)

    I did compile with {$D+}, but Search--Find Error kept taking me to the same line on the CPU screen which I don't know how to interpret. Do you know of any good sites where I can get help understanding this info?

    Destroying the datamodule after Run is a good idea; I'll keep it in mind if I come across this again.

    I also was not aware of the 7.1 update, so I appreciate you mentioning it.

    Thanks again for your help!
  • : dont know how you writen it but usually access violation popsup if client is accessing the server and client cant connect to server for lots of reasons, maybe too many connections in one client -> server and exceeded the total amount of connection allocated, sharing error, you have no proper access rights from server point of view, you have a bad connection, LAN card cannot acomodate all traffic (in/out), etc... but all means you cannot connect to server
    :
    Thank you for the ideas...I will remember to check this if I encounter similar errors in the future.
  • : : : Hi,
    : : :
    : : : I am getting an access violation (faulted with message 'access violation at 0x4da2ef6d: read of address 0xeeaed7e8') when exiting my Delphi 7 application. This only happens when a particular TQuery component (used to query a SQL Server db and populate a tabsheet) is opened *after* a TStoredProc object's ExecProc method has been called. No access violation occurs when exiting the application if:
    : : : - ExecProc was not called (doesn't matter how many times the query was opened)
    : : : or
    : : : - That specific query was not opened after ExecProc was called
    : : :
    : : : Weird thing is, the problem only occurs with a particular TQuery, but seems to happen after *any* TStoredProc's ExecProc method has been called. I am explicity closing the query before opening it, setting the TStoredProc to inactive after calling, and closing all database connections. I have also removed references to components such as the Crystal VCL, but the problem persists. I trace into the code and it gets to the 'end.' line of the project code (source) and then I get the access violation(!)
    : : :
    : : : Any ideas why this might be happening? I have tried everything I can think of but haven't found a solution, short of avoiding the triggering sequence of events altogether. Please help! Thanks in advance.
    : : :
    : : This is nasty, but have you already used the: menu option?
    : : This might give you the right insight. You have to put the $4da2ef6d adress in there. The error might be caused by some buggy component. I one had some same kind of a problem, and I solved it by destroying the datamodule (if you have one) after the Application.Run myself. There is also a Delphi 7 update, which might solve this problem.
    : :
    : :
    : :
    : Thank you for the suggestions! I actually did end up pinpointing the line of code that was causing this (really the lack of a line of code; once I added a line to specifically free the stored procedure object, it seemed to work fine.)
    :
    : I did compile with {$D+}, but Search--Find Error kept taking me to the same line on the CPU screen which I don't know how to interpret. Do you know of any good sites where I can get help understanding this info?
    :
    : Destroying the datamodule after Run is a good idea; I'll keep it in mind if I come across this again.
    :
    : I also was not aware of the 7.1 update, so I appreciate you mentioning it.
    :
    : Thanks again for your help!
    :
    I think if you compile your app with debug dcu's on, you will get an insight in the vcl's delphi code, besides the assembler of the cpu window. Interpreting assembly-code for debugging purposes, is almost never usefull, because it is hard to decypher what is going on. So I wouldn't bother about that.

    B.t.w. also you can set a breakpoint at the error location. Then after counting how many passes of this breakpoint are needed to give the error. You start the app one more time, then before the error happens and the break point fires, you take a look at the calling stack. This gives you a clear look in what context the error happens. (And is quite a bit faster then stepping into the error your self)


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories