Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
Bug in EDBStoredProc? |
Mon, Feb 18 2013 5:13 AM | Permanent Link |
Joe Mainusch | Hello,
I have spent now 4 days on a problem with "Invalid pointer operation" or "Access violation at address ....". The situation: There is a standard Delphi form (no MDI) with several database bound fields. One of the fields is a TDBLookupCombobox, whose ListSource is a TDataSource that is bound to a TEDBStoredProc component. During the OnShow() event of the form the TEDBStoredProc is "populated". Everything is working fine. The combobox offers all correct data delivered by the SP. The problem: The form can be opened several times (several instances), showing different customer records (customer A in one window, customer B in the 2nd window, etc...). If the form is opened only once and being closed, everything is fine. If more than 1 customer form has been opened and is being closed again (no action needs to be taken at the record!), the program puts out an error message "Invalid pointer operation" or "Access violation at address ....". In other words: Form open (record A) - Form close (record A) - OK. Form open (record A) - Form open (record B) - Form close (record B) - Form close (record A) - ERROR! Form open (record A) - Form open (record B) - Form open (record C) - Form close (record C) - Form close (record B) - ERROR! Sometimes after closing all forms and the error occured, when trying to open the form again I get the message "...form already opened...". It seems as if "something" cannot be freed and cleared during the form's closing/destroying. This "something" is the TEDBStoredProc component! How do I come to this conclusion: I deleted the TEDBStoredProc component from the form and created it in code instead -> exactly the same problem! I replaced the TEDBStoredProc component with a TEDBQuery component -> no problem - everything fine! Without any TEDBStoredProc component (neither on the form, nor as an object in code) -> no problem - everything fine! Does TEDBStoredProc have a bug when a form is being closed? What can I do? Does anyone else has also stumbled in? Replacing the TEDBStoredProc with a TEDBQuery is no option, since all SP's already exist in the database and no SQL statements shall be stored in program code. Additionally, the mentioned combobox and TEDBStoredProc component is not the only one, but there are several others. During my searching I reduced it to at last only one, and with this the problem can be reproduced at any time. Any help would be great Joe Some technical information (might be important?): During startup of the application the form is registered: Classes.RegisterClass(TfrmKunBearb); The form is created/opened with: theFormClass := TFormClass(FindClass('T' + frmName)); theForm := theFormClass.Create(Application); theForm.FormStyle := fsNormal; theForm.Show; The form is closed with: Action := caFree; In the OnShow() Event of the form the TEDBStoredProc component is filled with data: with Self.EDBSPBriefAnrede do begin DatabaseName := gActDB.DatabaseName; SessionName := gActDB.SessionName; StoredProcName := DBOWNER + 'KunBriefAnrede2Select'; ReadOnly := True; Prepare; Open; end; |
Mon, Feb 18 2013 6:00 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Joe
I'm not sure its anything to do with the SP. You create the form using theForm := theFormClass.Create(Application); and then use Show rather than ShowModal so its possible that you have multiple instances of the form "sharing" the same variable. This could explain the various errors. It would also explain why it happens only when two instances of the form are opened. It doesn't explain why it doesn't happen if you use a query rather than an SP. Can you produce a demo app that exhibits the same problem? Roy Lambert [Team Elevate] |
Mon, Feb 18 2013 6:25 AM | Permanent Link |
Joe Mainusch | Hello Roy,
thank you for your response. OK - I will make a demo app and send it to you / support... Joe |
Mon, Feb 18 2013 12:50 PM | Permanent Link |
Raul Team Elevate | Joe,
> I have spent now 4 days on a problem with "Invalid pointer operation" or "Access violation at address ....". Can you see the exact line where this AV is triggered ? Is it inside your own code or component's ? Without seeing actual code and where this happens exactly it is hard to advise more. > Sometimes after closing all forms and the error occured, when trying to open the form again I get the message "...form already opened...". It seems as if "something" cannot be freed and cleared during the form's closing/destroying. This "something" is the TEDBStoredProc component! Based on the code you have showed all form instances are independent of each other. "...form already opened..." is hence not expected - do you have any additional code dependencies you did not show below? Even if we assume EDB is keeping form from being destroyed (assumption i'm not saying is true) it should still not affect your ability to create more forms. Again tracing down the error in debugger is a good start. > > Does TEDBStoredProc have a bug when a form is being closed? What can I do? Does anyone else has also stumbled in? Have not seen it myself or heard in forums but that's not conclusive. Same about replacing it with query - it might change the interaction so again hard to be 100% sure one way or another. Debugging this to actual lines of AVs and errors is only way to be sure. I have had various weird problems with data-bound controls (and order of things closing/destroying) so one question i have is whether error is reproducible when you disconnect the data-bound controls and then open and multiple forms that normally results in AV (i know you won't see data but you already know data display is OK ). Raul |
Tue, Feb 19 2013 2:31 AM | Permanent Link |
Joe Mainusch | Raul,
of course I worked with the debugger. The AV occurs anywhere, but not in my code. At that moment I can see only assembler code. Anyway, thank you for your interest and advice. In the meantime I had sent a demo app to support (Tim Young) and Tim already answered the following (by email): "... >>It's a bug that has to do with executing the same stored procedure twice when the stored procedure is set to return a cursor, and I'll have a fix available in the next build/release. Hopefully, I'll have it out soon.<< ..." So I am glad that I am not completely mad. Now we have to wait for the bugfix. Joe |
Tue, Feb 19 2013 3:22 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Raul
>Based on the code you have showed all form instances are independent of >each other. I'm far from sure of that. > >I have had various weird problems with data-bound controls (and order of >things closing/destroying) Ditto but not of an AV or Invalid Pointer nature or at least so my memory tells me. It also tells me they were nightmares to track down. It was my first thought but the multiple errors made me discard it. Roy Lambert [Team Elevate] |
Tue, Feb 19 2013 9:02 AM | Permanent Link |
Raul Team Elevate | Joe,
> So I am glad that I am not completely mad. Now we have to wait for the bugfix. Glad to hear you got a response and a bug identified - the NG is only peer supported so limited in things to try. However Tim is very good with responses and fixes when emailing support direct. Raul |
Tue, Feb 19 2013 9:06 AM | Permanent Link |
Raul Team Elevate | Roy,
On 2/19/2013 3:22 AM, Roy Lambert wrote: >> Based on the code you have showed all form instances are independent of >> each other. > > I'm far from sure of that. Agreed - i meant we did not have enough code to make a better guess. Code shown looked independent enough for form instances. Always good when it boils down to a reproducible bug - i've done my share of test apps to show a bug only to find out it works fine proving it was my main code instead Raul |
Tue, Feb 19 2013 9:36 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Raul
>Always good when it boils down to a reproducible bug - i've done my >share of test apps to show a bug only to find out it works fine proving >it was my main code instead Strange you should say that <VBCG> My favourite on trying to track bugs down is the "remove components one at a time" type; and then we have the "intermittent" bug. I still have nightmares about creating a demo for Tim that consistently produced an error in DBISAM. Roy Lambert |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |