Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

How can I cast values using TADO components?

ajoajo Posts: 40Member
Hi,

I have a TADOStoredProc with one parameter being a float. This parameter is designated as type ftFloat in the Object Inspector so Delphi is recognizing the SQL sp correctly.

I have a string value that I want to assign to the Float parameter. My syntax is:

TADOStoredProc1.Parameters.ParamByName('@fltTest').AsString := 'AString'

This line produces a compiler error: 'Undeclared Identifier: AsString'. 'AsString' (or any such cast) does not appear to be a valid procedure for a TADOStoredProc component. (Also in the code I have variable assignations to TADOQuery results which are fine--'tVariable := ADOqry1Field1.AsString' is OK.)

I have used similar stored procedure syntax in the past with the BDE stored procedure component (TStoredProc) and have not had a problem.

I know that I can work around it by casting the value being assigned to the parameter e.g.:

TADOStoredProc1.Parameters.ParamByName('@fltTest').Value := StrToFloat('AString')

However, I would prefer not to use that method because I think (and please correct if I'm wrong)
1. Using '.Value' leaves that Parameter type a Variant until it's assigned at runtime (less efficient)
2. Casts of 'StrTo...' etc. require involving TFormatSettings

I really *really* don't want to just set the .Value to 'AString' and hope Delphi converts automatically.

I would really appreciate any assistance with this problem. Thanks!

Comments

  • zibadianzibadian Posts: 6,349Member
    : Hi,
    :
    : I have a TADOStoredProc with one parameter being a float. This parameter is designated as type ftFloat in the Object Inspector so Delphi is recognizing the SQL sp correctly.
    :
    : I have a string value that I want to assign to the Float parameter. My syntax is:
    :
    : TADOStoredProc1.Parameters.ParamByName('@fltTest').AsString := 'AString'
    :
    : This line produces a compiler error: 'Undeclared Identifier: AsString'. 'AsString' (or any such cast) does not appear to be a valid procedure for a TADOStoredProc component. (Also in the code I have variable assignations to TADOQuery results which are fine--'tVariable := ADOqry1Field1.AsString' is OK.)
    :
    : I have used similar stored procedure syntax in the past with the BDE stored procedure component (TStoredProc) and have not had a problem.
    :
    : I know that I can work around it by casting the value being assigned to the parameter e.g.:
    :
    : TADOStoredProc1.Parameters.ParamByName('@fltTest').Value := StrToFloat('AString')
    :
    : However, I would prefer not to use that method because I think (and please correct if I'm wrong)
    : 1. Using '.Value' leaves that Parameter type a Variant until it's assigned at runtime (less efficient)
    : 2. Casts of 'StrTo...' etc. require involving TFormatSettings
    :
    : I really *really* don't want to just set the .Value to 'AString' and hope Delphi converts automatically.
    :
    : I would really appreciate any assistance with this problem. Thanks!
    :
    You can try to set the Value property to AString and then change the DataType to ftFloat. Perhaps this will change the Value property to a float.
    Otherwise you have two options:
    - Create a new descendant of TParameters, which implements an AsString property.
    - Write your own StrToFloat variant, which does not rely on the TFormatSettings.
    Either way you will have to use the Value property as an OLEVariant, because of the nature of the BDE and ADO setup.

    There is a final option, which does not use the DBE all together, but you then need to define and implement your own specialized database objects. If run-time speed is what you want, this is the way to go, because an optimalized, specialized code is always than an optimalized generic code.
Sign In or Register to comment.