CC5 Object Access and ADO

[kunhock Koo]

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

[Michael Mattias]

>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

[José Roca]

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.

DIM vValue AS VARIANT
vValue = VARIANT$(fld.value))
? VARIANT$(vValue)

[kunhock Koo]

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

[José Roca]

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

DIM vValue AS VARIANT
vValue = fld.value
? VARIANT$(vValue)

The Value method returns a variant, not a dynamic string.

[kunhock Koo]

Yes .. that work .. thanks a lot

Regards.

Kunhock

[Michael Mattias]

>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]

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

When the compiler sees the statement...

   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 ..

TYPE Foo
   L AS LONG 
END TYPE 

 LOCAL fld AS Foo 

  S = FORMAT$(Foo.L, "#,")

... it does not need...

 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