Decimal Digit Changes in Specify 6.8.03

Our Response

To address the issues discussed by the community related to the double (floating point) to decimal field conversion during the 6.8.02 schema update, we plan to introduce changes in Specify 6.8.03 that address feedback we have received and return Specify 6 to the way it visualized and exported values in floating point fields in 6.8.01 and earlier.

These changes will most commonly affect fields used for measurements such as minElevation, maxElevation, and all Number*fields in various database tables.

This planned update to Specify 6 retains the data type changes to BigDecimal we made in 6.8.02 but changes the behavior of data inBigDecimal fields within the software itself, including Specify forms, labels, reports, and exports.

After this proposed change, the number of digits to the right of the decimal point in BigDecimal fields will be the number of digits entered by the user through forms, and will appear in mostly the same way (see below) in query results, labels and reports, and exports.

The underlying database would still store non-integer numbers with 10 decimal digits, but the extra zeros will never be visible, they will be truncated (removed) for displays, query results and exports.

So the behavior within Specify would look and act like it did before the change from floating point to decimal data type in Specify 6.8.02, but the data type will remain BigDecimal.

An important consideration will be that all trailing zeros in a decimal field would be truncated, so if you entered data into a Specify BigDecimal field, this is what would happen:

Entered Displayed, Exported, etc.
3 3.0
3.0 3.0
3.140 3.14
3.10 3.1
3.01 3.01
3.141592653 3.141592653

This is the same behavior that float fields had before the Specify 6.8.02 update.

Up to 9 digits come back faithfully (unless there is a trailing zero - the zero gets truncated).

So with 3 entered, we falsely imply a higher level of resolution: 3.0

With any number with a trailing zero (except the first decimal digit), that zero will be truncated, lowering the level of precision: 3.140 turns into 3.14

Questions

Are there other considerations about the change from Float to BigDecimal that we have not considered?

We are wondering how many people currently or likely will use Specify for precise measurements where the exact level of precision is critical to maintain.

For fields where an entered trailing zero must be protected and returned, would using a character field in those cases, treating the digits as text, be an adequate solution?


Thank you for taking the time to respond to our inquisition. Please reply with any other considerations or questions that you have about this change, as well as any advice or special considerations we should have.


All Float → Decimal Fields

Accession

  • Number1
  • Number2

Attachment Image Attribute

  • Number1
  • Number2

Borrow

  • Number1
  • Number2

Collecting Event Attribute

  • Number9
  • Number12
  • Number13
  • Number1
  • Number2
  • Number3
  • Number4
  • Number5
  • Number6
  • Number7
  • Number8
  • Number11
  • Number10

Collecting Trip Attribute

  • Number9
  • Number12
  • Number13
  • Number1
  • Number2
  • Number3
  • Number4
  • Number5
  • Number6
  • Number7
  • Number8
  • Number11
  • Number10

Collection Object

  • Number1
  • Number2

Collection Object Attribute

  • Number42
  • Number38
  • Number39
  • Number40
  • Number1
  • Number10
  • Number11
  • Number12
  • Number13
  • Number14
  • Number15
  • Number16
  • Number17
  • Number18
  • Number19
  • Number2
  • Number20
  • Number21
  • Number22
  • Number23
  • Number24
  • Number25
  • Number26
  • Number27
  • Number28
  • Number29
  • Number3
  • Number31
  • Number32
  • Number33
  • Number34
  • Number35
  • Number36
  • Number4
  • Number5
  • Number6
  • Number7
  • Number9
  • Number37
  • Number41
  • TopDistance
  • BottomDistance

Collection Object Property

  • Number21
  • Number22
  • Number23
  • Number24
  • Number25
  • Number26
  • Number27
  • Number28
  • Number29
  • Number30
  • Number1
  • Number2
  • Number3
  • Number4
  • Number5
  • Number6
  • Number7
  • Number8
  • Number9
  • Number10
  • Number11
  • Number12
  • Number13
  • Number14
  • Number15
  • Number16
  • Number17
  • Number18
  • Number19
  • Number20

Common Name TX Citation

  • Number1
  • Number2

Conservation Description

  • Width
  • Height
  • ObjLength

DNA Primer

  • Number1
  • Number2
  • ReservedNumber3
  • ReservedNumber4

DNA Sequence

  • Number1
  • Number2
  • Number3

DNA Sequencing Run

  • Number1
  • Number2
  • Number3

DNA Sequencing Run Citation

  • Number1
  • Number2

Deaccession

  • Number1
  • Number2
  • Number3
  • Number4
  • Number5

Determination

  • Number1
  • Number2
  • Number3
  • Number4
  • Number5

Disposal

  • Number1
  • Number2

Exchange In

  • Number1
  • Number2

Exchange Out

  • Number1
  • Number2

Geo Coord Detail

  • GeoRefAccuracy

Geologic Time Period

  • EndPeriod
  • EndUncertainty
  • StartPeriod
  • StartUncertainty

Gift

  • Number1
  • Number2

Lithostrat

  • Number1
  • Number2

Loan

  • Number1
  • Number2

Locality

  • MinElevation
  • MaxElevation
  • ElevationAccuracy
  • LatLongAccuracy

Locality Detail

  • StartDepth
  • EndDepth
  • Number1
  • Number2
  • Number3
  • Number4
  • Number5

Material Sample

  • GGBNConcentration
  • GGBNAbsorbanceRatio260_230
  • GGBNAbsorbanceRatio260_280
  • GGBNVolume
  • GGBNWeight
  • GGBNSampleSize
  • Number1
  • Number2
  • ReservedNumber3
  • ReservedNumber4

Paleocontext

  • Number1
  • Number2
  • Number3
  • Number4
  • Number5

Permit

  • Number1
  • Number2

Preparation

  • Number1
  • Number2

Preparation Attribute

  • Number1
  • Number2
  • Number3

Preparation Property

  • Number21
  • Number22
  • Number23
  • Number24
  • Number25
  • Number26
  • Number27
  • Number28
  • Number29
  • Number30
  • Number1
  • Number2
  • Number3
  • Number4
  • Number5
  • Number6
  • Number7
  • Number8
  • Number9
  • Number10
  • Number11
  • Number12
  • Number13
  • Number14
  • Number15
  • Number16
  • Number17
  • Number18
  • Number19
  • Number20

Project

  • Number1
  • Number2

Reference Work

  • Number1
  • Number2

Repository Agreement

  • Number1
  • Number2

Shipment

  • Number1
  • Number2

Taxon

  • Number3
  • Number4
  • Number5

Taxon Attribute

  • Number1
  • Number2
  • Number3
  • Number4
  • Number5
  • Number6
  • Number7
  • Number8
  • Number9
  • Number10
  • Number11
  • Number12
  • Number13
  • Number14
  • Number15
  • Number16
  • Number17
  • Number18
  • Number19
  • Number20

Taxon Citation

  • Number1
  • Number2

Treatment Event

  • Number3
  • Number4
  • Number5

Voucher Relationship

  • Number1
  • Number2
  • Number3

These changes are highly welcome and will likely resolve our problems.

For fields where an entered trailing zero must be protected and returned,
would using a character field in those cases, treating the
digits as text, be an adequate solution?

yes, a text field could do the job especially for any ID numbers containing a decimal point (something to avoid but which was used in legacy catalogue numbers.

I hope that the changes will also remove the trailing zeros from the Lat/Long values

That is indeed the case! The latitude and longitude fields will have the same behavior during exports, queries, and reports and labels as any other decimal field.