LabVIEW
Possible DateTime bug in Database Toolkit
Solved!
On a related note, how do i Format to String a datetime with fixed decimal point ... %T doesn't quite cut it, nor does %<%.3x %X>T help.
/Y
Have you tried to prepend %.; to the format string for Format into String? That may however not be what you want, since the ADO/ODBC driver or the actual database backend may expect localized decimal strings.
Yeah i tried %.; both in the beginning of the format and inside the %<>T (the latter causing an error).
/Y
Try this?
Notice that the format string starts with %.;
That hardcodes the decimal to a period. The entire string is totally hardcoded, though. So you'd have to make sure your DB is expecting one specifc hardcoded format, no matter where it is deployed. Which I am guessing isn't so hard.
@Jos, yes that's a workaround to a bad implementation. I'll post a descriptive picture.
Observe that neither Boolean nor DateTime can be inserted straight off the bat. I thought the whole idea was to use clusters that matched the database fields ...
/Y
@Yamaeda wrote:
@jos, yes that's a workaround to a bad implementation. I'll post a descriptive picture.
Observe that neither Boolean nor DateTime can be inserted straight off the bat. I thought the whole idea was to use clusters that matched the database fields ...
In theorie yes. And I understand your frustration, but the Database Conenctivity Toolkit makes use of the Windows ADO system. This is a generic ActiveX based database interface that has to work for all databases that come with either an ADO or ODBC driver. And all those drivers have very different ideas about what ADO or ODBC specifically means. When you program an application to interface to a specific database backend you usually do not worry about SQL syntax and functionality difference (well you might have to when you upgrade the database backend 
) but this luxery is not possible for the people writing the Database Connectivity Toolkit.
Sometimes you simply have only the choice between either limiting certain functionality for certain databases or failing for some others when you want to keep it generic. The alternative is to make the interface database backend specific with lots of configuration functionality for most functions where the programmer has to enable or disable some features depending on the database he is using. Such an interface is even more cumbersome to develop and especially maintain, and a complete nightmare for most but the very advanced database programmers to use.
But the fact that prepending %.; doesn't work for absolute (and maybe relative) timestamp formats in Format into String is definitely a bug. NI needs to put that in their CAR database.
