Numeric and Decimal

Question

Post reply

Numeric and Decimal

November 20, 2019 at 7:00 am

This was removed by the editor as SPAM
Steve Jones - SSC Editor

SSC Guru

Points: 736172
More actions
December 3, 2019 at 12:00 am

#3685142

Comments posted to this topic are about the item Numeric and Decimal

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

You must be logged in to reply to this topic. Login to reply

frederico_fonseca SSCoach Points: 16154 More actions · Answer 1

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

ktflash Default port Points: 1400 More actions · Answer 2

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.

Unbenannt

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

This reply was modified 5 years ago by ktflash.

I want to be the very best
Like no one ever was

https://www.sqlservercentral.com/articles/forum-etiquette-how-to-post-datacode-on-a-forum-to-get-the-best-help

Stewart "Arturius" Campbell SSC Guru Points: 72624 More actions · Answer 3

Nice question, thanks Steve

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

jcelko212 32090 SSCrazy Eights Points: 9303 More actions · Answer 4

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.

Please post DDL and follow ANSI/ISO standards when asking for help.

frederico_fonseca SSCoach Points: 16154 More actions · Answer 5

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?

jcelko212 32090 SSCrazy Eights Points: 9303 More actions · Answer 6

>> 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.

Please post DDL and follow ANSI/ISO standards when asking for help.

Ray Herring SSCertifiable Points: 5533 More actions · Answer 7

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.