IB is
generally happy with increases in field sizes because internal storage doesn't
map directly to the data type - see the manuals for more.
From
the Delphi side - it's the Static TField objects that will complain, rather than
the controls-on-forms so if you concentrate on DataSets with static field
objects it may speed your job. Having said that TFloatField, or TBCDField (if
you've got ENABLE BCD=TRUE for the BDE - which will give you better calc
accuracy anyway and more size independence against IB - though slightly slower
calc speeds) are happier with size changes at the back-end.
Max
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Willie Juson
Sent: Tuesday, 25 May 1999 21:37
To: Multiple recipients of list delphi
Subject: [DUG]: Changing Numeric Column in IB5Hi all,we've just discovered that Numeric(8,4) in our database design is sort 4 or five digits left of the decimal point and 4 decimal places (not 8 and 4 as initially thought). Not a big problem except the app has gone live in an "everything must happen yesterday week" industry and for some reason our users want some reports that total properly - demanding sods.I've done some modify scripts (IB 5.5) changing several columns from (8,4) to (12,4) and tested some of our forms/reports against the new database structure - so far with no problems - is anyone aware of any holes we can unsuspectingly fall into doing this. I know increasing/decreasing string field sizes causes problems especially with dbgrids, but so far this numeric change seems to have had no impact on our forms - except some reports no longer give an overflow error . There are approx 290 forms and I simply don't have time to exhaustively test each one (and/or sleep, eat and breath and write the other 600 forms we need to finish the app by april 1st this year!) so any comments would be much appreciated.regards
