On Mon, 26 Jan 2004 10:48:07 +0100, Steffen Goeldner
<[EMAIL PROTECTED]> wrote:
>Hi Jan,
>
>the fetch method of DBD::ADO::st contains the following lines:
>
> my $row =
> [ map { $rs->Fields($_->{Name})->{Value} } @$ado_fields ];
> # Jan Dubois [EMAIL PROTECTED] addition to handle changes
> # in Win32::OLE return of Variant types of data.
> foreach (@$row) {
> $_ = $_->As( Win32::OLE::Variant::VT_BSTR() )
> if UNIVERSAL::isa($_, 'Win32::OLE::Variant');
> }
>
>where $rs is an ADO Recordset. Is the foreach loop really
>necessary, i.e. can a Field value be a Win32::OLE::Variant?
Yes, it will return a VARIANT if the data type is VT_DATE.
>I thought the Value method always returns a Perl value?
>What does the comment mean, i.e. what are these 'changes in
>Win32::OLE return of Variant types of data'?
VT_DATE values used to be returned as strings, but that doesn't give
you any control over how the date is formatted. A long time ago I
changed Win32::OLE to return them as VARIANTs. If you include the
Win32::OLE::Variant module, they will still be stringified as before,
but you can then also treat them as objects and use the
Win32::OLE::Variant methods to format them the way you want to.
It was discovered too late that this was a change in behavior for
applications that do *not* use the Win32::OLE::Variant module. Since
reverting the behavior would have broken programs written after the
change, I left the new behavior as is.
In Win32::OLE 0.18 and later VT_CY and VT_DECIMAL values may also be
returned as Win32::OLE::Variant objects, but only if you ask for that
with:
Win32::OLE->Option(Variant => 1);
Cheers,
-Jan
