Hi,

Maybe you can work around it by doing this in your select:

example:

select convert( decimal(38,2), 0.00) as myDecimalField from dummy

by using the convert function it does generate the correct type. I know, "not ideal" but it works.

release 17;
datawindow(units=0 timer_interval=0 color=1073741824 brushmode=0 transparency=0 gradient.angle=0 gradient.color=8421504 gradient.focus=0 gradient.repetition.count=0 gradient.repetition.length=100 gradient.repetition.mode=0 gradient.scale=100 gradient.spread=100 gradient.transparency=0 picture.blur=0 .....

......

........

table(column=(type=decimal(2) updatewhereclause=yes name=mydecimalfield dbname="mydecimalfield" )
retrieve="select convert( decimal(38,2), 0.00) as myDecimalField from dummy" )

HIH,

regards

Hi,

a   cast(0 as decimal(8,2)) as ohcrap should to the job.

hth

Thank you for your response, Miguel.  That does look like it would work as a workaround.  Right now we have just been doing an 'edit source' and manually changing the values from decimal(0) to decimal(2) or whatever.  

I'm really trying to get Appeon to acknowledge this for the BUG that it is and would sleep better knowing they are working towards fixing it in a timely manner.

Thanks,

Derek

It's interesting to see the following also. PB or ODBC interface only seems to look at "significant" decimals.

If you do this, without any convert:

---

select 0.00 as zeroField, 1.23 as nonZeroField from dummy

then you'll get:

---

decimal(0) for a value of 0.00 and  

decimal(2) for a value of 1.23

 table(column=(type=decimal(0) updatewhereclause=yes name=zerofield dbname="zerofield" )
column=(type=decimal(2) updatewhereclause=yes name=nonzerofield dbname="nonzerofield" )
retrieve="select 0.00 as zeroField, 1.23 as nonZeroField from dummy
" )

Hi Derek;

  FYI: Same issue in PB2019. The "Cast()" workaround suggestion though works great in all newer PB's with SA16/17 (in my testing) today.

Regards ... Chris

Is this something that updating the pbodb###.ini file can fix?