Problem with TVirtualTable

[tuasal]

There is a problem with TVirtualTable.
Often after a call "Fields Editor" and attempt to create a fields (add them to dataset) - exception "Access Violation..." is thrown. Sometimes instead of exception it is displayed message box with message "Field '' not found", sometimes with another messages. Often these error occur during attempt to save the file (unit) of the form in which changes were made.

The described problem is observed already for a long time. But it is could not define precisely under which conditions it occurs.

[Plash]

We have fixed similar problem in TVirtualTable. The fix will be included in the next build of ODAC.

[tuasal]

Problem still exist in ODAC 6.10.1.10 (usingC++Builder 6 build 10.166).

1) Call "Fields Editor", "Add fields...", select found fields. After pressing button "Ok" - exception raised "Access violation at address ... in module rtl60.bpl ...". But fields have been added.
2) At attempt to save the changed unit (edited form) - it is again thrown exception "Access violation at address ... in module rtl60.bpl ..." (exception addresses now others). And this exception is thrown at each attempt to save the unit. I.e. after addition of fields it becomes impossible to save the edited unit (form).
3) Ok... Attempt to delete added fields. Exception "Access violation..." raised again. But fields are deleted.
4) Attempt to save the unit... Yes, the unit saved successfully, without any errors!

hmmm, try again...
5) Call "Fields Editor", "Add fields...", select found fields. After pressing button "Ok" - again error occcured. Not exception, but MessageBox with the message "vtBoolean: Field '' not found". And fields again added "successfully". And any attempt to save the unit failed...

Thus, the problem has not disappeared anywhere.

[Plash]

We could not reproduce the problem. Please describe all steps that are needed to reproduce it. What FieldDefs we need to create and whether we need to fill the table with a data before adding fields using Fields Editor?

[tuasal]

For example.
The project contains several forms, in each of which there is one instance of TVirtualTable component. Each instance (in each form) has a name "vtBoolean" and contains the table with two columns (defined in "VirtualTable Editor", and also accessible through property "FieldDefs":
1) Name='PHYS_VALUE', DataType='ftInteger'
2) Name='LOGIC_VALUE', DataType='ftString'
and each virtual table contains two virtual records:
PHYS_VALUE LOGIC_VALUE
1) 0 No
2) 1 Yes

In two forms the specified TVirtualTable instances also contains definitions of fields added through "Fields Editor". In dfm file these instances are defined as:

Code: Select all

  object vtBoolean: TVirtualTable
    Active = True
    IndexFieldNames = 'LOGIC_VALUE'
    FieldDefs = 
    Left = 164
    Top = 232
    Data = {
      030002000A00504859535F56414C554503000000000000000B004C4F4749435F
      56414C554501000300000000000000020000000400000000000000020000004E
      6F040000000100000003000000596573}
    object vtBooleanPHYS_VALUE: TIntegerField
      FieldName = 'PHYS_VALUE'
    end
    object vtBooleanLOGIC_VALUE: TStringField
      FieldName = 'LOGIC_VALUE'
      Size = 3
    end
  end

In other forms the definitions of fields are not made (i.e. the list "Fields Editor" is empty). In dfm file these instances are defined as:

Code: Select all

  object vtBoolean: TVirtualTable
    Active = True
    IndexFieldNames = 'LOGIC_VALUE'
    FieldDefs = 
    Left = 164
    Top = 232
    Data = {
      030002000A00504859535F56414C554503000000000000000B004C4F4749435F
      56414C554501000300000000000000020000000400000000000000020000004E
      6F040000000100000003000000596573}
  end

- at attempt to add (to these instances) the fields definitions through "Fields Editor" the exceptions occured. And corresponding unit cannot be saved to the disk until the list of fields not cleared in "Fields Editor". All, as it has been described by me in the previous messages.

BTW. If after addition of fields (and "in error state") to call the "VirtualTable Editor" - then message "vtBoolean: Field " not found " shown and after pressing button "Ok" of this message the window "VirtualTable Editor" displayed - but this window is absolutely empty (there are not present any columns and data, which was specified earlier). If to remove all the added fields in "Fields Editor" - then "VirtualTable Editor" displayed without error messages, and specified earlier columns and data are again "restored" (I think, that "in error state" columns and data do not deleted anywhere - simply "VirtualTable Editor" is not initialized normally).

Meanwhile I have added definitions of fields in form files (corresponding dfm and c++ header) "manually", by direct editing of the file - the project and corresponding forms have opened successfully, definitions of fields show in "Fields Editor", the project is successfully compiled.
Though at attempt to remove all fields from the list of "Fields Editor" - fields deleted, but shown the message "vtBoolean shows: Field " not found". After removal of fields through "Fields Editor" - attempt of addition again comes to an end with exceptions, unit can be saved on disk only after clearing the list of fields in "Fields Editor", etc...

[tuasal]

The described error does not occur wth any other datasets except TVirtualTable. And I could not reproduce this error in other (test) project yet. Probably, the error occurs at enough quantity of TVirtualTable instances in one project.

[tuasal]

Also there is one more observation:
very often, if during work with the project actions with any instance of component TVirtualTable were made, for example "Fields Editor" or "VirtualTable Editor" were called (and even it is not necessarily that any exceptions or erros occured) - then at closing IDE (C++Builder) too is thrown exception ("Access violation at address ... in module 'rtl60.bpl'. Read of address ...").

[Plash]

Try to make a small test project from your big project by removing all units, components and code that is not required to reproduce the problem. Please send this test project to odac*crlab*com.

[tuasal]

We have discovered, that problem occurs when TDBGridEh is used. More details here:
Let the form have the grid of type TDBGridEh. That grid "linked" (through DataSource property) to some dataset (not TVirtualTable), TOraQuery for example. In that dataset (TOraQuery) there are some lookup fields defined, and that lookup fields are used in the grid (grid has corresponding columns). And one (or more) of this lookup fields also "linked" to some TVirtualTable object (through LookupDataSet property). Error occured in this situation.

If corresponding columns (in the grid) for such a lookup fields deleted - then problem not occured. Or if to "unlink" the grid from the dataset totally - then problem not occured also.

So, possible the source of problem is in EhLib.
Problem detected at least with EhLib (http://www.ehlib.com) version 4.2.16.

[tuasal]

There is one more observation concerning TVirtualTable:
Sometimes after fields are added to TVirtualTable dataset - that fields does not received the "Name" by default. I.e. in the property "Name" (the name of object) there is an empty string. In such a case the file .dfm looks like:
object vtSomeVirtualTable2: TVirtualTable
...
object TIntegerField
FieldName = 'PHYS_VALUE'
end
end
- it is to comparison with when the field has a name, in such a case .dfm should look like:
object vtSomeVirtualTable1: TVirtualTable
...
object vtSomeVirtualTable1PHYS_VALUE: TIntegerField
FieldName = 'PHYS_VALUE'
end
end

It seems to me, that fields should receive a name automatically (though it is possible to specify a name manually).

[tuasal]

We suspecting that error occured because the grid calls the function "DataSet.FieldByName(...)" during dataset maintenance (fields list changing). And if some fields have empty names - then exception raised...

[kovkajevs]

Well, .LoadFromFile(...) re-creates the table structure the way it's stored... Sometimes You add fields in later versions of your software, but saved files stay unchanged.. Keep that in mind too