> It's kind of the desired effect. VT_DATE and VT_ERROR values are now
> returned as Variants and not as strings and numbers. This is
> most often
> more convenient, as you don't loose the type information. A VT_DATE
> variant can also be used to format the date in different ways; the
> stringification just formats it according to system locale settings.
Makes sense.
>
> Or do you think this incompatibility is so severe that it
> should be rolled
> back?
Maybe or maybe my understanding how to use these features needs expanding.
Previously I used this statement to return a row of data (DBD::ADO sub
fetchrow_array).
my $row = [ map { $rs->Fields($_->{Name})->{Value} } @$ado_fields ];
Now, I'm looking at something like this: (please excuse the sloppiest as
I'm just hacking the changes in.) My first concern is speed. I haven't
benchmarked the difference, but it is notably slower (to the eye). I'm open
to a better or correct solution. Also I've some concern about forcing the
user into a date/time "format".
my @row;
for my $x (@$ado_fields) {
my $fdat = $rs->Fields($x->{Name})->{Value};
my $ftyp = $rs->Fields($x->{Name})->{Type};
unless ($fdat) {
push(@row, undef);
next;
};
if ($ado_consts->{adDBTime}
== $rs->Fields($x->{Name})->{Type}) {
push( @row, $rs->Fields($x->{Name})->{Value});
} elsif ($ado_consts->{adDBTimeStamp}
== $rs->Fields($x->{Name})->{Type}) {
my $v =
Variant(VT_DATE, $rs->Fields($x->{Name})->{Value});
my $vv = $v->Date(qq{yyyy'-'MM'-'dd});
$vv .= " " . $v->Time( qw{HH':'mm':'ss});
push( @row, $vv);
} elsif ($ado_consts->{adDate}
== $rs->Fields($x->{Name})->{Type}) {
my $v =
Variant(VT_DATE, $rs->Fields($x->{Name})->{Value});
push( @row, $v->Date(qq{yyyy'-'MM'-'dd}));
} else {
push( @row, $rs->Fields($x->{Name})->{Value});
}
}
Tom
---
You are currently subscribed to perl-win32-users as: [archive@jab.org]
To unsubscribe, forward this message to
[EMAIL PROTECTED]
For non-automated Mailing List support, send email to
[EMAIL PROTECTED]
