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... _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
