Windows 8 & 10 not showing decimal value

[ChuckS]

Hello Everyone,

I am running into a strange issue where my application, that has being working perfectly for the past 2 years, is not wanting to show any digits past the decimal or even the decimal point.

Normally I see something like this as a challenge, as part of the fun of coding something is in trying to solve oddities like this. I searched the forums as best I can considering I am not even sure how to structure the search query.

What I am doing to getting a value from a database but it is a number stored as a text value. I know, not the smartest move but it is not my database but that is what I have to deal with. So I retrieve my value, strip the white spaces and assign it to a Global variable. The value changes but is current 0.29 and the majority of the time it is zero point something.

I then set this value to a label on the GUI. Below is the basics. I left out the database call to get the value and the GUICreate where the label it show.

Global $MyVar

$MyVar = StringStripWS($result("FSSCPM").Value, 8)

$labelMyVar = GUICtrlCreateLabel($MyVar, 333, 521, 40, 17)

On Windows 7 32 and 64 bit it works. Label shows the value as 0.29 as it should. Windows 8 and 10 just show zero.

I checked to make sure it wasn't the label size that was just to small to show the entire value but that is not the case. I also did a ConsoleWrite to simply add 1 to this value. On Windows 7 system is gives me 1.29 but on Windows 8 and 10 is gives me 1. Doing a ConsoleWrite on just the variable give me 0 so I understand why the simple addition is coming up as 1 but no idea why just on Windows 8 and 10 systems.

I recompiled the application using the latest version (v3.3.14.2) and the issue is the same.

Again not being one to give up easily I reluctantly pose the situation to everyone. I hope it is something simple that I am just over looking (not seeing the forest because of the trees) and if it is I am ready to take the laughing and pointing for overlooking the obvious.

 

Thanks.

 

[jchd]

What gives:

ConsoleWrite(VarGetType($result("FSSCPM").Value) & @LF)

What does a ConsoleWrite show when you feed it the result of each of the following queries:

select '0.29';
select 0.29;

 

[ChuckS]

Hello jchd,

The first ConsoleWrite returns DOUBLE

The first select (quoted value) returns STRING.

The second returns DOUBLE.

 

Thanks

 

The above results of the ConsoleWrites are the same for both Windows 7 and Windows 8 systems.

Edited October 26, 2015 by ChuckS
Forgot to mention:

[ChuckS]

Some additional testing and the results.

I used the StringFormat command to see how it would affect the result.

I know the value from the database is no more than three places to the right of the decimal.

$MyVar = StringFormat("%.3f",StringStripWS($result("FSSCPM").Value, 8))

On Windows 7 systems is work as expected. The label in the GUI shows 0.290 (0.29 being the returned value from the database) so the trailing zero added from the "%.3f".

On two different Windows 8 systems I am testing with the label shows as 0.000

Not sure if this helps at all but it is a result I was not expecting for Windows 8

[jchd]

Are you definitely positive that the Win8 machines are querying the very same DB as the Win7 ones?

Also what gives ConsoleWrite on the result of this on both system:

select cast(FSSCPM as text) from .... <rest of your normal query>;

You may have to adapt the SQL to your engine syntax but you get the idea.

[ChuckS]

Definitely reading from the same database. It is an AS400 (DB2) and I am using an ADODB connection so it functions like most other DB calls.

I will perform the CAST test and post the results but it will unfortunately be tomorrow before I will be able to do that.

 

Thanks 

 

[ChuckS]

I was able to resume the testing and it looks like using CAST solved the issue.

In the SQL query I CAST the field as CHAR and that did the trick. Both original Windows 8 systems and one Windows 10 are working as they should. Windows 7 systems are still working as they always did.

I am not sure why this was a problem with Windows 8 and 10. It acts like on those systems it was converting to an INTEGER but no where in the code am I doing that. 

Based on JCHD's testing suggestions we confirmed the VARTYPE was DOUBLE when retrieved from the database. I am still using the StringStripWS command so it was not the cause. I am glad the issue is solved but would sure like to know the exact reasoning behind it.

I may write a little test that I can post in its entirety so others can give it a try and see it they have the same results..

 

A huge thank you to JCHD for the feedback and the solution. I seriously doubt I would have even tried the CAST option on my own.

 

 

[jchd]

I don't have an explanation, since this works as expected, at least under Win7 (can't easily test under W8 or 10):

Local $v = 0.29
ConsoleWrite(VarGetType($v) & ' --> ' & StringStripWS($v, 8) & @LF)

 

[ChuckS]

I just finished a similar test and it worked as well on Win8.

I have narrowed it down to the DB query result. On two Win8 and a Win10 system if I do not CAST the field in the SELECT query, it returns what appears to be a INTEGER instead of DECIMAL or DOUBLE.

I had it write to console the raw value during the below While...WEnd. 

While Not $result.EOF
        ConsoleWrite($result("FSSCPM").Value & @LF)
        $result.MoveNext
    Wend

Windows 7 writes 0.29

Windows 8 and 10 writes 0

I also changed the SELECT query to a different field that had a value larger than 1. In this case it was 2.531

Following the same testing as above the Win7 system write to console was 2.531 but Win8 and 10 was simply 2 which kind of leads me back to the value somehow being seen as an INEGER.

I am thinking this is not an Autoit issue but rather how the ADODB query functions in Win8 and 10. 

 

 

[jchd]

Can you have a look at the DDL of that table? Would it be possible that the column definition is REAL but has a limitation of zero decimals?

Sorry if I ask dumb questions - I don't have DB2 installed anymore and I'm locked into W7 (maybe not a bad thing, this).

Edited October 27, 2015 by jchd