Devart Forums

tuasal

It was discovered that the value of IsLibrary (at least in case of unit Ora.pas) can depend on: whether some IDE experts are used. For example, if any expert from the JCL/JVCL library used then IsLibrary returns true - as it occured at me. The same thing occured if GExperts is used. If specified experts disabled - then IsLibrary always contains value false (during the check in unit Ora.pas)!

Similar, it is impossible to rely on value of variable IsLibrary reliably... It can be possible to use any other method instead of check of value of the given variable?

tuasal

Plash wrote:IsLibrary is True for DLL but it is False for packages

hmmm.... how it can be?....

I have found some IsLibrary-related info: here "IsLibrary problem - false in DLL" and here "DLL and VCL problems".

...possibly, you are compiling the ODAC packages with runtime packages?

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...

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 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

We are using C++Builder 6 build 10.166.

You wish to tell, that projects with fields of type (for example) TOraTimeStampField are normally open at you in C++Builder 6? Are you sure??? Whether it is possible to know, how exactly you checked it?

Then a question: Whether ODAC call the "RegisterClass(TOraTimeStampField)", or carries out similar actions in order to "register" the class TOraTimeStampField (and other fileds classes) in IDE?

I had to address to the one who has access to source code of ODAC (v6.10.1.10). And we have discovered that the call "RegisterClass(TOraTimeStampField)" is made only in one place. And before this call there is a check of a kind " if not IsLibrary then... " is made... But in case of .bpl (in which the ODAC components resides) this check ("not IsLibrary") returns (and always should return) "false". Because "IsLibrary variable is true if the module is a DLL", and .bpl IS a .dll library. And therefore the RegisterClass(TOraTimeStampField) should not be carried out, and the forms with TOraTimeStampField fileds (and others) not loaded by IDE in design-time - always, irrespective of C++Builder version or build number.

tuasal

Whether usage of components

Code: Select all

TCursorField
TBFileField
TOraDataSetField
TOraReferenceField
TOraTimeStampField
TOraIntervalField
TOraNumberField
TOraXMLField

at design-time in C++Builder (version 6, and possible others) was tested? Or it should work only "theoretically"?

After I have added to dataset the field of type TOraTimeStampField such form does not wish to open by IDE (C++Builder 6); though it is compiled successfully. At careful studying the possible reasons it has been found, that ODAC library does not register any types of fields which list is resulted above.

All ODAC packages (.bpl) have been registered by me as is specified in a installation instructions. Only one version of ODAC library (6.10.1.10) is installed in system, and paths to packages are checked carefully, and also any "conflicts" should not be (with old or packages of another versions).

I have registered the specified fields classes "manually", i.e. have executed (for IDE):

Code: Select all

RegisterClass(TCursorField);
RegisterClass(TBFileField);
RegisterClass(TOraDataSetField);
RegisterClass(TOraReferenceField);
RegisterClass(TOraTimeStampField);
RegisterClass(TOraIntervalField);
RegisterClass(TOraNumberField);
RegisterClass(TOraXMLField);

After that the form with fields of type TOraTimeStampField (and others) opens successfully!

The same problem seems was described in the message "Class TOraNumberField not found. Ignore the error and continue?" and till now has not been solved (since December 2005)...

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 ...").

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

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

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.

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.

tuasal

hmm... Then the statement "Existing BDE-based applications can be easily migrated to ODAC" mismatches true?! And actually should sound as "ODAC behaviour is more correct than BDE"? With all the ensuing consequences...

In fact in other (popular) databases there is a distinction between "empty string" and NULL. And the logic of some Delhi functions and components is depends on it. It turns out, that it is not always easy to migrate from BDE to ODAC...

tuasal

Sometimes the described error (exception with the same call stack, as in case of a mistake described above) raised at absolutely small amount of records - less than 10 (but lookup fields and text fields with concerning "big" length are still present).

tuasal

Is there any solution (without patching source code) to force dataset to "interpret" empty string as "NOT NULL"? Or to replace NULL with empty string. There are third-party components (in JVCL pack, for example) at which use it is sometimes impossible to consider equivalent "NULL" and "empty string".

This replacement (NULL value to "empty string" and back) should work is as much as possible transparent for all components which address to fields ODAC dataset (TOraTable, etc). In particular, if a component carries out search of record using methods Lookup & Locate, then it specifies the "empty string" (a variable of type VARIANT with string '', instead of VARIANT-value "NULL", as should be actually) and therefore the record, having value NULL in the corresponding field, will not be found.

Devart Forums

Search found 20 matches

ODAC custom field types not working at design-time in C++Builder

Now ODAC 6.10.1.10 - problem stiill exist

Problem with TVirtualTable