Re: ADO Date Problems

What you are seeing is a reference to a "Win32::OLE::Variant" object (not a hash). The quick solution is to use Win32::OLE::Variant; and your variant value will just print, using a default format.

Use print $variant->Date('yyyy-MM-dd'); to format it however you'd like.

Add use Win32::OLE::NLS qw/:LOCALE :DATE/; and you can use any system formats, ie print $variant->Date(DATE_LONGDATE) will print something like "Thursday, December 19, 2002" - depending on the locale settings in Windows. If you need the time to print as well, import :TIME from the NLS module.

This is documented in ActiveState's help file (or perldoc Win32::OLE::Variant, if you prefer)

Comment on Re: ADO Date Problems Select or Download Code

Replies are listed 'Best First'.
Re: Re: ADO Date Problems by Anonymous Monk on Dec 20, 2002 at 17:37 UTC
Thanks for your response. My problem is that several applications have been already developed that rely on an ADO date being returned as as string as well as being being converted from a string to an ADO Date during a field update. I can re-code the applications, but it will take a substantial amount of time and effort. This experience makes me a little uneasy about developing future applications in PERL.	[reply]
Re^3: ADO Date Problems by Solo (Deacon) on Dec 20, 2002 at 22:06 UTC
I found variants frustrating when I first dug into them, too. However, this is no different than other languages that have peculiar handling of certain types; for instance VB requires you use 'SET' when assigning an object to variable or property. This is just part of learning the language and the libraries one uses. What language was used when developing the applications that expect ADO date field values to return a string? I see this problem a lot when people attempt to port a VB example to Perl. ADO is made to work most easily with VB. The Win32::OLE::Variant module handles the datatypes in VB that in part make ADO so easy to use in VB. Perl and ADO can co-exist and I find them very useful (especially when calling stored procedures with many arguments)--but using Perl and ADO together is harder than the other usual combinations of Perl/DBI or VB/ADO. In short, I wouldn't guage my decision whether to continue using Perl on how difficult is was to get Perl/ADO working properly. That said (and since this is PM, it had to be said first) there is another option. You can craft your SQL queries to solve this problem for you. `select CONVERT(varchar(30),date_fieldname,120) as date_fieldname from +...` [download] By using CONVERT (use CAST if ANSI compatible--check syntax), you can return a datefield as a string and should be able to avoid changing lots of code (as you indicated you would have to). I think there is an implicit conversion during updates, so strings can be used when writing to a date field. If your data provider/data source doesn't support ANSI or TSQL, this SQL fix may not be possible. Update: added bits about non-TSQL databases. -- May the Source be with you. You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.	[reply] [d/l]