Using JvEdit with JvDataSource raises Access Violation

Question

I'm trying to use JvEdit and JvDataSource instead of DBEdit and DataSource. But at design time, whenever I open a form with a JvEdit on it, I get this error:

Access violation at address xxxxxxxx in module 'dbrtl160.bpl. Read of address 00000000. Ignore the error and continue? NOTE: Ignoring this error may cause components to be deleted or property values to be lost.

And no component or property value is lost... Just an annoying message.

Has anyone ever had the same problem with JvEdit? I have tried to reinstall JCL and JVCL using the installer, and by manually rebuilding packages, to no avail.

Here's a stack trace of my application after raising the same access violation at runtime:

00724ecb +08f LIMS.exe     Data.DB          12439   +9 TDataSet.Resync
007d1cf4 +034 LIMS.exe     Data.Win.ADODB    4421   +3 RefreshBuffers
007d1d39 +039 LIMS.exe     Data.Win.ADODB    4425   +1 TCustomADODataSet.GetFieldData
00713cd1 +08d LIMS.exe     Data.DB           4538   +8 TField.GetData
00716476 +012 LIMS.exe     Data.DB           5650   +2 TIntegerField.GetValue
007162f1 +00d LIMS.exe     Data.DB           5595   +1 TIntegerField.GetAsString
007fdae4 +00c LIMS.exe     JvDataSource                TJvDataSource.GetFieldString
00728ae4 +010 LIMS.exe     JvDataSourceIntf            TJvDataConnectorField.GetAsString
0073a83d +03d LIMS.exe     JvEdit                      TJvCustomEditDataConnector.RecordChanged
00728412 +02e LIMS.exe     JvDataSourceIntf            TJvDataConnector.DcRecordChanged
00728301 +00d LIMS.exe     JvDataSourceIntf            TJvDataConnector.Notify
0072825b +007 LIMS.exe     JvDataSourceIntf            TJvDataConnector.ActiveChanged
00728848 +00c LIMS.exe     JvDataSourceIntf            TJvFieldDataConnector.ActiveChanged
00728395 +011 LIMS.exe     JvDataSourceIntf            TJvDataConnector.DcActiveChanged
00728301 +00d LIMS.exe     JvDataSourceIntf            TJvDataConnector.Notify
0072835b +00f LIMS.exe     JvDataSourceIntf            TJvDataConnector.DataSourceConnected
007288ec +00c LIMS.exe     JvDataSourceIntf            TJvFieldDataConnector.DataSourceConnected
00728747 +0d3 LIMS.exe     JvDataSourceIntf            TJvDataConnector.SetDataSource
0046be07 +06b LIMS.exe     System.TypInfo    1909   +8 {System.TypInfo}TPropSet<System.IInterface>.SetProc
0046b112 +00a LIMS.exe     System.TypInfo    3033   +0 SetInterfaceProp
00481a58 +05c LIMS.exe     System.Classes    7266   +5 TPropIntfFixup.ResolveReference
00481d21 +0d5 LIMS.exe     System.Classes    7347  +24 GlobalFixupReferences
00484009 +279 LIMS.exe     System.Classes    8514  +53 TReader.ReadRootComponent
00480456 +032 LIMS.exe     System.Classes    6601   +3 TStream.ReadComponent
0047b1df +057 LIMS.exe     System.Classes    3455   +7 InternalReadComponentRes
0047b34f +05f LIMS.exe     System.Classes    3512   +4 InitComponent
0047b3dd +061 LIMS.exe     System.Classes    3524   +6 InitInheritedComponent
005f93b2 +0c6 LIMS.exe     Vcl.Forms         3554  +17 TCustomForm.Create
009567a9 +015 LIMS.exe     uMainForm          147   +1 TfrmMainForm.acInsurancesExecute
0048bd2f +00f LIMS.exe     System.Classes   13372   +3 TBasicAction.Execute
004f60d5 +031 LIMS.exe     Vcl.ActnList       448   +8 TContainedAction.Execute
004f6ec0 +050 LIMS.exe     Vcl.ActnList      1094   +7 TCustomAction.Execute
0048bbf3 +013 LIMS.exe     System.Classes   13301   +2 TBasicActionLink.Execute
005e9734 +090 LIMS.exe     Vcl.Menus         2520  +17 TMenuItem.Click
005ead4f +013 LIMS.exe     Vcl.Menus         3435   +5 TMenu.DispatchCommand
0060af75 +121 LIMS.exe     Vcl.Forms        14151  +26 TFormStyleHook.TMainMenuBarStyleHook.TrackMenuFromItem
006087fa +022 LIMS.exe     Vcl.Forms        12959   +7 TFormStyleHook.TMainMenuBarStyleHook.ProcessMenuLoop
006086a0 +02c LIMS.exe     Vcl.Forms        12897   +6 TFormStyleHook.TMainMenuBarStyleHook.MenuEnter
0060aa88 +024 LIMS.exe     Vcl.Forms        14009   +4 TFormStyleHook.TMainMenuBarStyleHook.MouseDown
0060db08 +0cc LIMS.exe     Vcl.Forms        15529  +35 TFormStyleHook.WMNCLButtonDown
005c913b +07b LIMS.exe     Vcl.Themes        6709  +13 TStyleHook.WndProc
005c9318 +000 LIMS.exe     Vcl.Themes        6810   +0 TMouseTrackControlStyleHook.WndProc
0060d91c +000 LIMS.exe     Vcl.Forms        15436   +0 TFormStyleHook.WndProc
005c8b02 +05a LIMS.exe     Vcl.Themes        6485  +17 TStyleHook.HandleMessage
0098c05a +116 LIMS.exe     Vcl.Styles        3387  +26 TStyleEngine.HandleMessage
005c6078 +054 LIMS.exe     Vcl.Themes        5145  +11 TStyleManager.HandleMessage
0051594b +00f LIMS.exe     Vcl.Controls      8936   +0 TWinControl.DoHandleStyleMessage
00516f7d +049 LIMS.exe     Vcl.Controls      9825   +1 TWinControl.WndProc
005faafd +60d LIMS.exe     Vcl.Forms         4344 +201 TCustomForm.WndProc
00516b3c +02c LIMS.exe     Vcl.Controls      9689   +3 TWinControl.MainWndProc
0048ca24 +014 LIMS.exe     System.Classes   13878   +8 StdWndProc
75f5cc6b +00a USER32.dll                               DispatchMessageW
00603cef +0f3 LIMS.exe     Vcl.Forms        10164  +23 TApplication.ProcessMessage
00603d32 +00a LIMS.exe     Vcl.Forms        10194   +1 TApplication.HandleMessage
00604071 +0c9 LIMS.exe     Vcl.Forms        10332  +26 TApplication.Run
009af892 +0de LIMS.exe     LIMS                61  +15 initialization
76dced6a +010 kernel32.dll                             BaseThreadInitThunk

I was able to produce it just by removing this line:

qInsurances.Active := True;

It seems like JvDataSource doesn't check the associated DataSet to see if it's open or not.

Checked and confirmed. DataConnector link doesn't check to see if the DataSet is open. If my DataSet is open at design time, no exception is raised.

These are the first few lines of the procedure in which the exception is raised. Now, I'm not an expert when it comes to examining VCL source code. So, could anyone please guide me in the right direction?

procedure TDataSet.Resync(Mode: TResyncMode);
var
  Count: Integer;
begin
  if not IsUniDirectional then
  begin
    if rmExact in Mode then
    begin
      CursorPosChanged;
      if GetRecord(FBuffers[FRecordCount], gmCurrent, True) <> grOK then
        DatabaseError(SRecordNotFound, Self);
    end else
      if (GetRecord(FBuffers[FRecordCount], gmCurrent, False) <> grOK) and // <<-- Exception is raised here!
        (GetRecord(FBuffers[FRecordCount], gmNext, False) <> grOK) and
        (GetRecord(FBuffers[FRecordCount], gmPrior, False) <> grOK) then

Install MadExcept, please and post the DESIGNTIME access violation stack trace, and perhaps we can find it and fix the problem in JEDI Components. — Warren P, Sep 04 '12 at 11:41
@WarrenP I already have MadExcept. At designtime, the exception is handled by the IDE. But, I guess I found a stack trace which can be helpful. See the edit above — iMan Biglari, Sep 04 '12 at 11:44
Jedi CodeLibrary has Exception Dialog wit hstack tracing. And Delphi Project Options have Use Debug DCUs option. So you can have the exact place of AV and try to see which variable is NULL. For beginning i am quite surprised by coupling non-DB-aware control like TEdit/TJvEdit with TDataSource — Arioch 'The, Sep 04 '12 at 12:04
On the 2nd look, the 2nd example seems to have nothing about Accecc Violations. But one should carefully check all the events. I'd intercept TDataLink.DataEvent and look what it is calling. It seems to call something like DataSet.First ot DataSet.Next or such. And to understand where and why it does it, would be crucial to ind the problem — Arioch 'The, Sep 04 '12 at 12:08
@Arioch'The `Access Violation` is raised on this line: `Data.DB` - 12439 +9 `TDataSet.Resync` — iMan Biglari, Sep 04 '12 at 12:17
In a quick glance, Nowhere in `JvDataSourceIntf.pas`, `DataSet`'s `Active` is checked. I'm not sure where to put such a check. — iMan Biglari, Sep 04 '12 at 12:38
if you replace JvDataSource with stock tDataSource - would it check for TDataSet.Active ? If no, then that is VCL design and JvDataSource just follows it — Arioch 'The, Sep 04 '12 at 13:15
@Arioch'The Unfortunately `DataConnector` of `JvEdit` does not accept `TDataSource`. Its `DataSource` member is of `IJvDataSource` type. — iMan Biglari, Sep 04 '12 at 13:20
Then let's hope that Warren would maybe fix it. Or you may register the issue at http://issuetracker.delphi-jedi.org — Arioch 'The, Sep 04 '12 at 13:25
This a memory access violation due to whatever underlying DATASET (not datasource) you are using. Notice that you told us about your data aware control (Edit) and datasource, but not what dataset type you are using (TADODataSet, TJvCsvDataSet, TTable, or something else). — Warren P, Sep 05 '12 at 15:54
My best guess is you have some memory corruption, and the ADOQuery's internal recordset data is corrupted, because your crash is in a routine that is supposed to be getting data from a record buffer, which appears to be an invalid buffer pointer. This stuff is managed automatically by TDataSet, and all TDataSet descendents including TAdoQuery usually work great, unless you have some other random corruption or issues. — Warren P, Sep 10 '12 at 20:27
Other question; Are you doing anything funny with the FieldDefs of the dataset anywhere? (Clearing them or something?) — Warren P, Sep 10 '12 at 20:28
@WarrenP No. Not really. I haven't even opened the dataset yet when I get the exception. As a quick fix, I changed `TJvDataSource.GetFieldString` to this: `function TJvDataSource.GetFieldString(Field: TObject): string; begin try Result := TField(Field).AsString; except Result := ''; end; end;` — iMan Biglari, Sep 11 '12 at 09:25
@WarrenP And, this occurs only when the dataset is not active. I mighe be wrong, but shouldn't `JvDataConnector` or `JvDataSource` first check to see if the dataset is actually open before trying to retrieve data from it? — iMan Biglari, Sep 11 '12 at 09:27
Hmm. That sounds like a sane precondition check. Maybe I need to log a bug in the Jedi bug tracker (mantis). — Warren P, Sep 11 '12 at 15:53

Using JvEdit with JvDataSource raises Access Violation

0 Answers0