Returning Numeric values exactly as inserted

  • I am inserting numeric values from 0.01 to 9.99 into a SQL 2000 database using the Numeric(3,2) datatype. Occasionally the values will only have 1 or even 0 decimal places, 1.2 or 3. For data validation purposes, if the value inserted was 1.2, I need to have 1.2 returned from a query. When I look at this in Query Analyzer, I always get the trailing zeros. But in Enterprise Manager, it shows the value as entered.

    How can I get this to work?

    Thanks,

  • EM has many limitations in the GUI outputs, this is just one of those. What is your goal and where is it ultimately going to be viewed?

  • For data validation purposes, where is the difference between 1.2 and 1.20?

    You can always use the char or varchar data type, but I guess that doesn't make your life easier at all.

    Frank

    http://www.insidesql.de

    http://www.familienzirkus.de

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • I am dealing with an application that stores data records in text files. When data records are written to the text files, decimal values are not written with a consistent precision. I am writing another VB application that will put those records in a database.

    Each record in the text file has an associated hash value to ensure data integrity. The hash value is based on all of the characters in the record. After I write the record into the database, I need to read it back from the table, recreate the hash and compare it to what is in the original text file. At that point, there is a difference between 1.2 and 1.20.

    The decimal values are temperature and humidity readings with their associated voltage outputs. I would really like to store these readings as decimal values. But it looks like that might not be feasible given my hashing requirements.

    Looking at the data in Enterprise Manager gave me some hope that SQL 2000 somehow "remembers" exactly how a decimal value is entered. If I can't make that work, varchar it is.

    Thanks for your input.

    Jeff

  • Would using char/varchar but having a check on the field to ensure numeric(3,2) validity help?

  • I forgot one small item. The main reason for putting the data in a database is for easy reporting. Using the SQL aggregate functions, AVG, STDEV, MIN, MAX, etc. over a time period is the information we are looking for. It is alot simpler to do that on decimal fields. If I am forced to use varchar, then my reporting gets a little messier.

    Thanks again.

  • Why don't you write the code in the VB application to convert to numeric after reading from the text file and compare for the validity of data stored ??

    Linto

  • Store value as both varchar and decimal, use the varchar to show original input and use decimal value for calculations.

    Far away is close at hand in the images of elsewhere.
    Anon.

  • Thanks for all of your input. Since I haven't seen any replies about returning a decimal value that has not been modified by the leading or trailing zeros, I will have to trudge forward with alternative plans.

    Writing the numbers to a varchar and a decimal field is probably my best bet. But, this data could be audited by FDA regulators and they might not appreciate verifying data in one field and reporting from another.

    Jeff

  • Probably doesn't add anything to the discussion, but would using a computed column expression help with the FDA issue? If you have a varchar column NUM_AS_STRING you could create the decimal column in your table creation statement as follows:

    
    
    NUM_AS_STRING varchar(15) null,
    NUM_AS_NUM as cast(NUM_AS_STRING as numeric(3, 2))

    Then you only need to insert into the varchar column. The numeric column will not be a different value, just a different representation. Mind you, knowing what regulators are like, this might not make a difference to them

    Cheers,

    mia

    Life moves pretty fast. If you don't stop and look around once in a while, you could miss it.


    Cheers,
    mia

    Life moves pretty fast. If you don't stop and look around once in a while, you could miss it.

  • I got around this issue by using a "SmallMoney" data type instead of Real, Decimal, or Float. When I tried using the other data types, a Value of "4.5" would be entered into SQL as "4.44449" or something similar. It was very annoying!

  • How about STORING the data as CHAR or VARCHAR and when you need to do calculations, CAST the data to DECIMAL.

    Not a 'pretty' solution, but you only need to store the data once.

    -SQLBill

Viewing 12 posts - 1 through 11 (of 11 total)

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