I am very pleased with the core features of the DB components and more specially the SQL components. Many thanks for your efforts. Development of these components for Linux, MAC, and Windows will make this platform more palatable.

After reviewing the code for the TParams and TParam components, have encountered an issue that needs attention. The issue at hand is with regard to the usage of FValue (Variant) for data storage values that get processed during a bind operation.

I have had many issues with Delphi and variants and feel that variants are completely unreliable when it comes to highly efficient transactional systems. Looking at the existing code - I see the Param system making copies of copies of memory and assigning them to the variant. This is totaly acceptable for client applications but in server applications where scale is an issue, this will lead to major performance issues.

I've given it some thought, and think it would be best if TParam had an additional system for reading/writing bindings. TParam now facilitates an additional SetData method as detailed below:

procedure TParam.SetData(Memory: Pointer; ASize:Integer;
AFieldType:TFieldType; AParamType:TParamType)
begin
  FDataType:=AFieldType;
  FValue:=VPointer(Memory); << Access violation here...
  FSize:=ASize;
end;

The only problem I'm having is with the FValue:Variant. How do I get FValue to store the pointer without raising a read access violation?

Looking forward I think a TParamMemoryMode=(pmmCopy,pmmPointer) system is in order here. By default, the memorymode would be Copy and use the existing infrastructure. But if in Memory mode the system will require pointers to values and their DataTypes and Size specified during SetData.

I'm thinking I need to extend the TParam component to include a FMemory:Pointer field as to keep all the old code intact.

Comments... Suggestions...

In my ideal world, the TParam would not need problem is that it must store all kinds of data. Implementing this would mean effectively re-implementing many FVariant mechanisms, such as conversions from one type to another.

I'm not quite sure that I understand what you hope to gain with this new proposed field and parameter ?

Michael.

Michael,

If I extend the Param system to depend on the memory being allocated by the caller of the SetData and that the memory will be there for the duration of the SQL operation then all we need to do is have a pointer to the memory, the size of the memory, and the kind of memory. With these three things we can read/write as needed. The present system is using a Variant data and contains a copy of the initial data that was passed during the SetData.

Eventyally, we could remove the variant and use the getmem method if the TParm is in copy mode and the component would be entirely Variant free.