June 12, 2009 at 4:22 am
Hi,
I want to validate the given number. how to check for the following requirements in sql server 2005
1) how to check whether the given number is integer
2) how to check whether the given number is decimal
pls help me....
June 12, 2009 at 6:37 am
here's the first way i thought of: compare the value to the convert(,int) of itself.
declare @number decimal(18,4)
Set @number = 10.0
--here's one way, compare the value to the integer conversion of itself.
IF number = convert(int,@number)
PRINT 'Can Be Integer'
ELSE 'Must Remain Decimal
Lowell
June 12, 2009 at 10:25 pm
anandhakrishnabca (6/12/2009)
Hi,I want to validate the given number. how to check for the following requirements in sql server 2005
1) how to check whether the given number is integer
2) how to check whether the given number is decimal
pls help me....
I'm curious... why do you need to do such a validation? What is the business rule behind it all?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2015 at 2:07 pm
Jeff,
A business case for this might be inventory. In our case we had a clerk enter in an invalid unit of measure then she completed some transactions. This resulted in decimal places in our inventory when the items were 'whole'.
Specifically in our case the item comes in a pack of 6. The master case should have had 10 packs of 6 in it. Instead she said it had .44 of a pack in it.
John
December 18, 2015 at 3:34 pm
John Hanrahan (12/18/2015)
Jeff,A business case for this might be inventory. In our case we had a clerk enter in an invalid unit of measure then she completed some transactions. This resulted in decimal places in our inventory when the items were 'whole'.
Specifically in our case the item comes in a pack of 6. The master case should have had 10 packs of 6 in it. Instead she said it had .44 of a pack in it.
John
What is the datatype of the "field" this entry was made to? I'm thinking that the front end would be the right place for this type of "business logic".
--Jeff Moden
Change is inevitable... Change for the better is not.
December 21, 2015 at 11:34 am
The front end can only do so much to stop bad user action. We have some items which allow decimal places and some that don't. Our system has a check for that but only if the person who sets it up does so 'correctly'. Alas it is not done correctly every time.
December 21, 2015 at 4:36 pm
John Hanrahan (12/21/2015)
The front end can only do so much to stop bad user action. We have some items which allow decimal places and some that don't. Our system has a check for that but only if the person who sets it up does so 'correctly'. Alas it is not done correctly every time.
Agreed. With the idea of and simplicity of input data masking on the front end, I don't know why more people don't take advantage of such things for numeric and date/time "fields".
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply