SPONSORS:






User Tag List

Results 1 to 6 of 6
  1. #1
    Senior Member
    Join Date
    Aug 1999
    Location
    Cambridge, UK
    Posts
    470
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Float problem with DB_ functions?

    I am having a problem with the DB_ functions (DB_Execute, DB_FetchNext etc.) in SilkTest. We are connecting to an odbc datasource which we know to be reliable (from using other odbc clients), so this bug definitely seems to be in the silktest code. The problem is that when receiving floating-point values back from DB_FetchNext, they are inaccurate at the fifth and sixth decimal places. They aren't being rounded off, they just have a couple of arbitrary (and usually incorrect) digits in these positions. Has anybody else encountered a similar problem?

  2. #2
    Senior Member
    Join Date
    Jul 2002
    Location
    Paris (France)
    Posts
    182
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Float problem with DB_ functions?

    The default precision for 4Test is 6 decimal places. If you want more, say 10 decimal places, do the following right before your fetch:

    REAL rPrecision = 0.0000000001
    SetPrecision (rPrecision)
    {your code}

    For more information about this, look up "SetPrecision" in the online help.




    ------------------
    David Genrich
    Icarian
    555 North Mathilda Ave
    Sunnyvale, CA 94086
    davidg@icarian.com

  3. #3
    Senior Member
    Join Date
    Aug 1999
    Location
    Cambridge, UK
    Posts
    470
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Float problem with DB_ functions?

    It was worth a try, but it didn't work I'm afraid. It's not a problem with the precision of comparison - The DB_FetchNext function just seems to be mangling floats after the sixth or seventh significant figure it seems.
    The annoying thing is that for over a year we've been using an equivalent set of functions that one of our developers wrote in a dll for us, because we didn't want to pay the extra for the DB functions; but there were a few problems with these dll functions, so I thought that now the DB functions are free anyway, I would try using them instead. But this problem is really ridiculous, it does make our database checks unreliable.

  4. #4
    Senior Member
    Join Date
    Aug 1999
    Location
    Cambridge, UK
    Posts
    470
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Float problem with DB_ functions?

    Another problem I've just found with the DB functions - they operate on the host machine, not the target machine.
    I think I can see why Segue have made this stuff free - because it's not very good. There's not even a mention of it anywhere in the user's guide that I can find - looks like they don't care about it much.

  5. #5
    Junior Member
    Join Date
    Mar 2000
    Location
    Chelmsford, MA , USA
    Posts
    6
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Float problem with DB_ functions?

    If the ODBC object os correctly set up and points at a networked DB, how can the DB function be acting on the local machine? Do you have the ODBC object configured properly?
    Bruce Berger
    SQA Manager
    Kronos, Inc.
    2 Omni Way
    Chelmsford, MA 01824
    bberger@kronos.com

  6. #6
    Senior Member
    Join Date
    Aug 1999
    Location
    Cambridge, UK
    Posts
    470
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Float problem with DB_ functions?

    I don't know exactly what you mean by an odbc object to be honest. All I know is that odbc datasources have to be set up per machine, and if I am runnin Silktest on machine A and running a script on machine B, DB_Connect fails to connect to it's datasource if it is defined on machine B but not A, but it will work if the datasource is defined on machine A (where silktest is residing). To be honest it makes scripting easier (I can just set up the relevant odbc datasources on one machine, instead of on every machine I want to run the script on), but it did waste about a couple of hours of my (and a developer's) time until it became obvious what it was doing.

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 07:43 PM.

Copyright BetaSoft Inc.