[fpc-pascal] DB unit and Parameter Binding with Variants

[Michael Van Canneyt]

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.