On Tue, 4 Aug 2009, Andrew Brunner wrote:

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.

In my ideal world, the TParam would not need variants at all.
The 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.

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to