Re: SQL*Forms V3 problem #2

From: <champs_at_hhcs.gov.au>
Date: 11 Feb 93 17:23:03 +1100
Message-ID: <1993Feb11.172303.623_at_hhcs.gov.au>

In article <1993Feb11.155424.621_at_hhcs.gov.au>, pihlab_at_hhcs.gov.au writes:
> SQL*Forms V3 problem #2
>
> Another form is getting a similar problem but it appears that the returned
> key is losing a digit when it gets returned from the LOV routine. Again, this
> was a working form prior to the upgrade and in fact works client/server from
> a V6.0.34 database client to the V6.0.36.5 server database.
>
> We held off going to V6.0.34.#, V6.0.35.# and V6.0.36.# because Oracle
> advised us there were problems with those release that were fixed in
> V6.0.36.5. Silly me.
>
> Has anybody else had similar problems with this Oracle release?
>
Yes Bruce,
  Three of us just spent the entire afternoon identifying the problem.

  It appears that, when a NUMBER is selected from a list of values, SQL*Forms starts from the LEFT HAND SIDE of the space allocated for the number in the LOV and takes a chuck equal to the size of the target field. A complicating factor is that SQL*Forms ADDS ONE SPACE TO THE LEFT OF ANY LOV NUMBER to allow for a sign, so that if your database source column is declared as NUMBER(n) and your target field is NUMBER (n) then when Forms takes its chunk from the list of values it takes the leading space and ONLY n-1 DIGITS and places this in the target field. If target field size is set to database field size + 1 then the whole number will be selected into the field, and the problem is solved.

eg with a target field size of NUMBER(5) and a database column NUMBER(5) with

   values 12345 and -12345.

 the LOV appears as

       12345       selected into target field as  1234
      -12345       selected into target field as -1234
     

  Another problem with list of values and numbers is that SQL*FORMS, when allocating space in the list of values for a number, it allocates the size of the database source field + 1 for the sign. If the database field is a decimal field (say NUMBER (7,3)) then it still only allocates ONE extra space for the sign, instead of one for the sign + ONE FOR THE DECIMAL POINT. If your source number uses the full precision of the database field (say -1234.567) then it will appear in the LOV as -1234.57 (ie rounding occurs) and the rounded value will be copied to the target field, regardless of the field's size.

---

    /\       Steven Champness (champs_at_hhcs.gov.au)
   /  \      Dept Health Housing and Community Services
  /    \     Brisbane Queensland
 /      \     via

/ / \ Canberra Australia
\ / / /
 \/ / / / MACINTOSH SOFTWARE AXIOM : If you need a manual to operate it

  \/ / /                                it wasn't designed properly in the
   \/ /                                 first place !

    \/ Received on Thu Feb 11 1993 - 07:23:03 CET