3

I'm writing an integration between Salesforce.com and another service, and I've hit a problem with integer fields. In Salesforce.com I've defined a field of type "Number" with "Decimal Places" set to "0". In the other service, it is stored definitively as an integer. These two fields are supposed to store the same integral numeric values.

The problem arises once I store a value in the Salesforce.com variant of this field. Salesforce.com will return that same value from its Query() and QueryAll() operations with an amount of precision incorrectly appended.

As an example, if I insert the value "827" for this field in Salesforce.com, when I extract that number from Salesforce.com later, it will say the value is "827.0".

I don't want to hard-code my integration to remove these decimal values from specific fields. That is not maintainable. I want it to be smart enough to remove the decimal values from all integer fields before the rest of the integration code runs. Using the Salesforce.com SOAP API, how would I accomplish this?

I assume this will have something to with DescribeSObject()'s "Field" property where I can scan the metadata, but I don't see a way to extract the number of decimal places from the DescribeSObjectResult.

Technetium
  • 5,902
  • 2
  • 43
  • 54

2 Answers2

8

Ah ha! The number of decimal places is on a property called Scale on the Field object. You know you have an integer field if that's equal to "0".

noodles
  • 96
  • 2
3

Technically, sObject fields aren't integers, even if the "Decimal Places" property is set to 0. They are always decimals with varying scale properties. This is important to remember in APEX because the methods that are available are for Decimals aren't the same as those for integers, and you there are other potential type conversion issues (not always, but in some contexts).

barelyknown
  • 5,510
  • 3
  • 34
  • 46
  • 1
    Just a brief note on your final comment - Apex does consider Integer N and Decimal N.0 to be equal. I do also recall at least one legacy number field (NumberOfEmployees perhaps? I have notes on it somewhere if you are interested) that exhibits Integer behavior. – jkraybill Mar 22 '12 at 03:08
  • Thanks for pointing that out. I should have checked before making that last comment about equality. I'm sure that the type is Decimal for sObject numbers, so I'll edit out that last line. – barelyknown Mar 22 '12 at 04:14
  • 1
    Cool. FYI the "true" type for several legacy number fields (wherever you see xsd:int as the type in the WSDL) is actually not Demical. I found the bug I was talking about -- trying to do a acct.put('NumberOfEmployees', myDecimal) throws "System.SObjectException: Illegal assignment from Decimal to Integer" in Apex. I can't remember if acct.NumberOfEmployees = myDecimal works, it quite possibly does. – jkraybill Mar 22 '12 at 08:09