Ticks as a floating point value on XP (not 2000)


Licensed User
I have a desktop application that saves a ticks value into a column in a table control (and also into a column value in a SQL Lite database).

I then use this value when filtering records.

On Windows 2000, the TicksColumn value is reported as an 18 digit string (as expected) however on XP the value is reported as a floating point value (e.g. 6.33432093 E+17). A simple MsgBox is used to determine this.

Now when I compose a SQLlite Select statement with

"... WHERE TicksColumm > '" & Calendar1.value & "'" the select doesn't return the expected records on XP but works as expected on Win 2000.

Any ideas where the difference is introduced?

Do I need set the TickColumn value with Format(Now,"D18") to ensure it is always held as a string?

Are there other known gotchas with desktop apps on different platforms?

Dave Lancaster


Licensed User
Thanks for reply. Have tried without apostrophies with no change.

However I can now exlude any platform differences.

I have proven with the enclosed test program that

MsgBox DateParse("13/04/2008")

returns 633436416000 on Windows 2000 and XP when run interpretively under B4PPC.

however it returns 6.33436416E+17 on Windows 2000 & XP when run as a compiled executable.

The net result is that my application works 100% under B4PPC but not once it is compiled.

Any further suggestions gratefully received.

Dave Lancaster


Active Member
Licensed User
Seems to have something to do with the type of compilation

Using XP and a non-optimized compiled version I get 633436416000,
but when using an optimized compilation I end up with 6.33436416E+17

all the best / Björn


Licensed User
Erel, Bjorn,

The brain is now in gear ... and it is to do with the way that the result from DateParse() is cast by the machine.

I now get the exponential form of response if I use int(dateparse("13/04/2008")) both as an executable and under B4PPC.

Therefore I can now force my application to always use exponential tick values (floating point integers - what's that all about then?).

So, the fix to the problem is

1) Use int() to force the result to be cast as E+nn format
2) Use Erel's original suggestion of dropping apostrophes from SQLlite SELECT statement to make sure value is always treated as numeric. (I suspect it was performing a string comparison before).

One for the knowledgebase I think.


Dave Lancaster