VT_DATE support for milliseconds 
Author Message
 VT_DATE support for milliseconds

Hello,

I am working with VC++ and ADO (using the #import syntax), and I have faced
problems trying to insert or update timestamp fields in my database,
including millisecond values.

Now, it is documented that the routines VariantTimeToSystemTime and its
inverse do not provide support for milliseconds. However, the millisecond
information is included in the double value that constitutes the date field
of the variant. I have been able to extract millisecond information based on
the algorithm that is described. So, so far, if the database value has
millisecond information I am able to see it.

The problem occurs when I try to insert a value. Let's say, that I construct
a double value, based on the inverse of the algorithm mentioned, that
contains millisecond information. I put this value in a VARIANT of type
VT_R8. However, upon calling

myField->PutValue(myVariant)

it seems that the variant automatically transforms into a VT_DATE variant,
and the information is lost. This conversion is done implicitly, I seem to
have no control over it. Therefore, the msec information is not stored in
the database. The corresponding DB field is of ADO type adDBTimestamp.

Details about my code :

double dTime=37275.650985579 //corresponds to 19/1/2002 15:37:25.154
_variant_t *pvaTemp=new _variant_t(dTime, VT_R8); // no problem here, the
value is the same
myField->PutValue(*pvaTemp);

After the last call is completed, trying to read the value immediately gives
37275,650983796 , which corresponds to 19/1/2002 15:37:25.000 ... And the
msec information is rounded or truncated... I tried to directly create a
VT_DATE variant, instead of a VT_R8, but the result is the same.

How can I keep this information in the database? How can I prevent the
change of type into VT_DATE? Is there any flag or something? Any hint or any
pointers on this would be greatly appreciated...

Thank you in advance,

Regards,

Nikos



Sun, 18 Jul 2004 20:27:55 GMT
 VT_DATE support for milliseconds

One option is to use FILETIME for the time format. FILETIME is a structure
with two DWRODs, which you can cast to a 64-bit integer or store as two
32-bit integers. FILETIME has even greater resolution - 100 picoseconds.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

Quote:

> Hello,

> I am working with VC++ and ADO (using the #import syntax), and I have faced
> problems trying to insert or update timestamp fields in my database,
> including millisecond values.

> Now, it is documented that the routines VariantTimeToSystemTime and its
> inverse do not provide support for milliseconds. However, the millisecond
> information is included in the double value that constitutes the date field
> of the variant. I have been able to extract millisecond information based on
> the algorithm that is described. So, so far, if the database value has
> millisecond information I am able to see it.

> The problem occurs when I try to insert a value. Let's say, that I construct
> a double value, based on the inverse of the algorithm mentioned, that
> contains millisecond information. I put this value in a VARIANT of type
> VT_R8. However, upon calling

> myField->PutValue(myVariant)

> it seems that the variant automatically transforms into a VT_DATE variant,
> and the information is lost. This conversion is done implicitly, I seem to
> have no control over it. Therefore, the msec information is not stored in
> the database. The corresponding DB field is of ADO type adDBTimestamp.

> Details about my code :

> double dTime=37275.650985579 //corresponds to 19/1/2002 15:37:25.154
> _variant_t *pvaTemp=new _variant_t(dTime, VT_R8); // no problem here, the
> value is the same
> myField->PutValue(*pvaTemp);

> After the last call is completed, trying to read the value immediately gives
> 37275,650983796 , which corresponds to 19/1/2002 15:37:25.000 ... And the
> msec information is rounded or truncated... I tried to directly create a
> VT_DATE variant, instead of a VT_R8, but the result is the same.

> How can I keep this information in the database? How can I prevent the
> change of type into VT_DATE? Is there any flag or something? Any hint or any
> pointers on this would be greatly appreciated...

> Thank you in advance,

> Regards,

> Nikos



Mon, 19 Jul 2004 02:33:36 GMT
 VT_DATE support for milliseconds
Alexander, Thank you for your reply...

However, limited resolution is not exactly my problem. In the double value I
have at my disposal, using VT_DATE (or VT_R8), the milliseconds value is
included *before* I actually attempt to insert the value in the database.
The main problem is that it does not get inserted in the database. The
function Field::PutValue(...) just removes the millisecond information.
After PutValue is called, the Field instance contains a value for the time
rounded to the second.

What could be wrong here? Is it a known behaviour? Could FILETIME help out
on this one, since the Field::Type is adDBTimestamp and the accepted format
is a double number?

Any hint or pointer would be greatly appreciated,

Thank you in advance,

Nikos


One option is to use FILETIME for the time format. FILETIME is a structure
with two DWRODs, which you can cast to a 64-bit integer or store as two
32-bit integers. FILETIME has even greater resolution - 100 picoseconds.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================


Quote:
> Hello,

> I am working with VC++ and ADO (using the #import syntax), and I have
faced
> problems trying to insert or update timestamp fields in my database,
> including millisecond values.

> Now, it is documented that the routines VariantTimeToSystemTime and its
> inverse do not provide support for milliseconds. However, the millisecond
> information is included in the double value that constitutes the date
field
> of the variant. I have been able to extract millisecond information based
on
> the algorithm that is described. So, so far, if the database value has
> millisecond information I am able to see it.

> The problem occurs when I try to insert a value. Let's say, that I
construct
> a double value, based on the inverse of the algorithm mentioned, that
> contains millisecond information. I put this value in a VARIANT of type
> VT_R8. However, upon calling

> myField->PutValue(myVariant)

> it seems that the variant automatically transforms into a VT_DATE variant,
> and the information is lost. This conversion is done implicitly, I seem to
> have no control over it. Therefore, the msec information is not stored in
> the database. The corresponding DB field is of ADO type adDBTimestamp.

> Details about my code :

> double dTime=37275.650985579 //corresponds to 19/1/2002 15:37:25.154
> _variant_t *pvaTemp=new _variant_t(dTime, VT_R8); // no problem here, the
> value is the same
> myField->PutValue(*pvaTemp);

> After the last call is completed, trying to read the value immediately
gives
> 37275,650983796 , which corresponds to 19/1/2002 15:37:25.000 ... And the
> msec information is rounded or truncated... I tried to directly create a
> VT_DATE variant, instead of a VT_R8, but the result is the same.

> How can I keep this information in the database? How can I prevent the
> change of type into VT_DATE? Is there any flag or something? Any hint or
any
> pointers on this would be greatly appreciated...

> Thank you in advance,

> Regards,

> Nikos



Mon, 19 Jul 2004 15:54:41 GMT
 VT_DATE support for milliseconds
OK, I just found out that milliseconds are not supported by ADO. The
described behaviour is by design, Microsoft says...

So, please consider this posting obsolete...

Thank you,

Nikos



Mon, 19 Jul 2004 17:45:11 GMT
 VT_DATE support for milliseconds
Nikos,

The post is not obsolete at all -- in fact I found it very informative.

Although you may not have found the answer as you would have preferred, for
those of us that read the posts here in this NG, we have something to file
away in our kit.  Thanks

Roy Fine


Quote:
> OK, I just found out that milliseconds are not supported by ADO. The
> described behaviour is by design, Microsoft says...

> So, please consider this posting obsolete...

> Thank you,

> Nikos



Mon, 19 Jul 2004 22:42:53 GMT
 
 [ 5 post ] 

 Relevant Pages 

1. datetime datatype support milliseconds

2. Does ADO.NET Support Milliseconds?

3. What's with that VT_DATE date variant?

4. Help converting VT_DATE to String?????

5. What's with that VT_DATE date variant?

6. Oracle, ADO and VT_DATE parameters

7. OH-CINCINNATI-106557--Visual Basic-Technical Support-ORACLE-Help Desk Support-TECHNICAL SUPPORT

8. New York - Sybase DBA - Global Web Trading System Support - Derivatives Trading Support - Fixed Income Trading Support

9. NYC - Sybase DBA - Global Web Trading System Support - Derivatives Trading Support - Fixed Income Trading Support

10. The Millisecond Bug...

11. BUG??: DATE TIME milliseconds

12. Problem with milliseconds


 
Powered by phpBB® Forum Software