Jump to content


Photo
- - - - -

Zero being converted to 80000


6 replies to this topic

#1 Vlodik Myslony

Vlodik Myslony

    Newbie

  • Members
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Australia

Posted 26 August 2009 - 07:14 AM

Hi,
we have an issue where the value in an oracle table is set to zero, but 80000 is being inserted.

e.g. column_value = 0
IF column_value > 0 THEN
UMSG(CONV(column_value),-1)
ENDIF

The above is returning 80000 but only on some records when scanning through many records.
Any ideas?

Thanks

#2 Rory

Rory

    Advanced

  • Members
  • PipPipPip
  • 88 posts

Posted 26 August 2009 - 09:08 AM

Hi Vlodik

In the past I've seen this caused by a parameter to a global function being 0 and then the value of 0 being (unintentionally) changed by the global function ... (very strange I know)

We usually use #zero rather than 0 in logic to avoid this.

Rory

#3 George Macken

George Macken

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 248 posts
  • Gender:Male
  • Location:Co. Wicklow, Ireland

Posted 26 August 2009 - 09:22 AM

Hi

Has the software been changed (fixes applied), the tables changed, or the environment changed, have you changed version of ORACLE etc.,
Has the problem always been present or only now just occurring, if so why now ?

You mention that the column is initially set as 0, check the function that sets this column to 0, that within in this function that literal value 0 has not been corrupted.

For example if in an Interface to a Global Function the "Variable Mapped To" in the Calling Function is 0 then its possible to corrupt the value of 0.
We have seen examples of 0 used as the "Variable Mapped To" and the value of 0 is then no longer ZERO.

Some standards we "try" to follow are
1) If there are values returned thru Globals that are not required in the calling function then we assign/receive these values into $junk or #junk.
2) We avoide using #value = 0 to avoide the possibility of encountering any corruption of 0. When we wish to set a numeric to 0 we use #value = #z, within our application functions we never assign any value to #z and therefore #z always = 0.

see also these earlier posting that may be of help



http://www.proivrc.com/index.php?showtopic=61&hl=juan



http://www.proivrc.com/index.php?showtopic=1975&hl=zero



http://www.proivrc.com/index.php?showtopic=1651&hl=zero


rgds

George

#4 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 26 August 2009 - 11:24 AM

Have you checked the values in the database outside ProIV to confirm what the value actually is? (i.e. could it be a conversion error?)

Is the column name used in more than one function?

#5 Vlodik Myslony

Vlodik Myslony

    Newbie

  • Members
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Australia

Posted 27 August 2009 - 12:40 AM

Hi Vlodik

In the past I've seen this caused by a parameter to a global function being 0 and then the value of 0 being (unintentionally) changed by the global function ... (very strange I know)

We usually use #zero rather than 0 in logic to avoid this.

Rory



This appears to be the cause. Thanks for the quick response!

#6 Lewis Mccabe

Lewis Mccabe

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 455 posts
  • Gender:Male
  • Location:Sarasota, Florida

Posted 28 August 2009 - 04:32 PM

Vlodik,

Is "unintentially changed by the global function" because of a programming bug or a PROIV bug?

Lew

#7 Vlodik Myslony

Vlodik Myslony

    Newbie

  • Members
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Australia

Posted 30 August 2009 - 11:10 PM

Vlodik,

Is "unintentially changed by the global function" because of a programming bug or a PROIV bug?

Lew


Hi,
The issue has been found to be a mapping to Zero (0) in a global function interface mapping.. We have now changed the code to map to a dummy scratch variable instead of zero.

This has now fixed the issue.

Thanks for your help!



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users