Announcement

Collapse
No announcement yet.

CC5 Object Access and ADO

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • CC5 Object Access and ADO

    I am trying out the new object access method to the MS ADO object.

    I managed to get a recordset and set a field to get the 1st column.

    DIM Fld AS Int_field (Int_field interface as generated by CC5 com Browser)

    set fld = rs.fields.item(0)

    fld.value as defined by the interface is a variant, yet when I apply any variant method to it, like VARIANT$(fld.value)), the compiler complains of data type mismatch.

    Any one ?

    Regards.

    Kunhock

  • #2
    >like VARIANT$(fld.value)),

    Show code line where used. Are you sure the target of the assignment is a dynamic string variable? That is, the mismatch occuring on the source or target?

    And, are you sure fld was set correctly in the preceding line? ISOBJECT would tell you.

    Also I think SET was deprecated and should be replaced with LET now... let me look....yup....

    Previous versions of PowerBASIC Compilers used the SET statement for creation of objects. LET now includes all the functionality of the old SET statement, so you should plan to remove all SET statements as soon as possible. This involves nothing more than changing every SET to LET, or simply deleting every SET.
    MCM
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      fld.value as defined by the interface is a variant, yet when I apply any variant method to it, like VARIANT$(fld.value)), the compiler complains of data type mismatch.
      You must first assign the value to a variant, e.g.

      Code:
      DIM vValue AS VARIANT
      vValue = VARIANT$(fld.value))
      ? VARIANT$(vValue)
      Forum: http://www.jose.it-berater.org/smfforum/index.php

      Comment


      • #4
        Ya .. the receiving string is dynamic string ..and yes .. the fld is tested to be object if I run the program, that is when compiled without using variant$.

        When i try variant$(fld.val) , it does not matter whether target variable is string or variant .. the complain by compiler is the same, which is data type not matched. There is no telling whether the code will or will not work, the compiler syntax checking block it from going further ..


        Regards and Thanks.

        Kunhock

        Comment


        • #5
          Sorry, there is a mistake in the code I posted. It should be:

          Code:
          DIM vValue AS VARIANT
          vValue = fld.value
          ? VARIANT$(vValue)
          The Value method returns a variant, not a dynamic string.
          Forum: http://www.jose.it-berater.org/smfforum/index.php

          Comment


          • #6
            Yes .. that work .. thanks a lot

            Regards.

            Kunhock

            Comment


            • #7
              >The Value method returns a variant, not a dynamic string

              Another set of words with special meanings: that should be the value property, not the value method.
              [FROM ADO version 2.7 doc]
              Value Property
              Indicates the value assigned to a Field, Parameter, or Property object.

              Settings and Return Values
              Sets or returns a Variant value that indicates the value of the object. Default value depends on the Type property.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Even after a couple of days, this is still bugging me.

                When the compiler sees the statement...
                Code:
                   S =  VARIANT$(fld.value)
                ... it "knows" that the value propery of the fld (Int_Field) object is a variant.

                So why should it need an explicit assignment to another variable of type VARIANT?

                Not exactly parallel circumstance but is sure seems a lot like this: given ..
                Code:
                TYPE Foo
                   L AS LONG 
                END TYPE 
                
                 LOCAL fld AS Foo 
                
                  S = FORMAT$(Foo.L, "#,")
                ... it does not need...
                Code:
                 LOCAL X AS LONG 
                    X =    Foo.L 
                    S =   FORMAT$(X, "#,")
                .. because the compiler "knows" when it encounters the FORMAT$ that FOO.L is a numeric datatype, and thus is a legal argument to the FORMAT$() function.

                Enquiring minds want to know.

                ???

                MCM
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment

                Working...
                X