# Numeric and Decimal

• This was removed by the editor as SPAM

• Steve -  someone calendar messed up - your post is dated "December 3, 2019 at 12:00 am"

• This post always appears on top of the "latest topic" section for me, is this for anyone else here aswell?

If not, has anyone an idea how to get it rid from there, i have not subscribed to it or anything.

NVM i am stupid, this will probably disappear after Dec the 3rd

• This reply was modified 4 years ago by  ktflash.
• Comments posted to this topic are about the item Numeric and Decimal

• Nice question, thanks Steve

____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”

• This is another example of Microsoft versus ANSI/ISO. When we set up the DECIMAL and NUMERIC data types, we were thinking of COBOL style picture data and BCD data. The NUMERIC(S,P) data type was supposed to be exactly that many decimal places, like COBOL. The DECIMAL(S,P) had to suppose at least that many decimal places, but could be more precise, like BCD.

• jcelko212 32090 wrote:

This is another example of Microsoft versus ANSI/ISO. When we set up the DECIMAL and NUMERIC data types, we were thinking of COBOL style picture data and BCD data. The NUMERIC(S,P) data type was supposed to be exactly that many decimal places, like COBOL. The DECIMAL(S,P) had to suppose at least that many decimal places, but could be more precise, like BCD.

another block of bullshit - we don't think of COBOL - neither does COBOL PIC behave the same way as DB datatypes

COBOL PIC 9(9)V9(3) = SQL decimal(12,3) - how are they the same?

• >> another block of bullshit - we don't think of COBOL - neither does COBOL PIC behave the same way as DB datatypes

COBOL PIC 9(9)V9(3) = SQL decimal(12,3) - how are they the same? <<

When we were picking the datatypes for the SQL standards, we wanted to make it easy for existing datatypes in other languages to map into SQL. The standards describe behavior and not implementation. This is why we have numeric and decimal, as well as real and float in SQL.

Jim Melton's book "SQL:1999" has a chapter on the various language in embeddings. Alphabetically, the languages we supported at that time were Ada, C, COBOL, Fortran, mumps, Pascal and PL/1. Others have been added over the years. Today, we also tend to write more pure SQL code and not using beddings as much.

• frederico_fonseca wrote:

jcelko212 32090 wrote:

another block of bullshit - we don't think of COBOL - neither does COBOL PIC behave the same way as DB datatypes

COBOL PIC 9(9)V9(3) = SQL decimal(12,3) - how are they the same?

Your reply is quite unprofessional and not particularly useful.  There are still many LOC of Cobol running in the world.  Ever changing standards, updated technology, and improved techniques often result in language artifacts that seem dumb to us today.

Personally, I think you owe Joe and apology for the tone and language you used.   And you owe the rest of us a more useful comment on the technical issues under discussion.

Viewing 9 posts - 1 through 8 (of 8 total)