function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
SFDC_LearnerSFDC_Learner 

Reg: Difference between Custom Object and Custom Settings?

Hi, can any one differentiate the differences between custom setting and custom object? Where we use custom settings and custom objects exactly?
skodisanaskodisana

Hi,

 

Custom Settings is nothing but Cache i.e. If you want to use the records in that table no need to write any queries. If there a common static data across the Org then you can use Custom Settings. 

Ex:

 

Map<String_dataset_name, CustomSettingName__c> mcs = CustomSettingName__c.getAll();
CustomSettingName__c mc = CustomSettingName__c.getValues(data_set_name);



If you want to access the data from Custom object then you have to write the queries.

 

Thanks,

Kodisana

 
Shashikant SharmaShashikant Sharma

Custom object is  a record table and Custom setting is a configurations table. Custom object is like any Database table that we used to have in SQL or in any other database. CustomSetting is like configuration file that we used to have. Even though List type of custom setting looks like that it is also a custom object but there are differences. LIke in custom settings there is a limit on no of records, you can not write trigger, workflow etc on custom setting.

I hope this will help you.

 

for more you can see : http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_custom_objects.htm

http://www.salesforce.com/community/winter10/custom-cloud/granular-security-sharing/custom-settings.jsp
SFDC_LearnerSFDC_Learner

Hi,

 

Could you please a sample program on custom setting methods?

 

 
spandana@sfdcspandana@sfdc

Custom Settings vs. Custom Objects

In some ways, Custom Settings look very much like Custom Objects. In fact, if you use a tool like the Data Loader to view a list of objects in your org, you’ll see that Custom Settings are listed together with Custom Objects, without any visible distinction between the two. However, while both Custom Objects and Custom Settings allow you to define Custom Fields, there are some important differences.

  • Limited field types – Custom Settings support only Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, Text Area, and URL field types. Most notably absent are Formula and Picklist, as well as field types that define relationships to other objects, like Lookup and Master/Detail. You can’t create lookups from Custom Objects to Custom Settings either.
  • No validation rules – You can’t define validation rules on Custom Settings.
  • No workflow or triggers – You can’t define workflow rules or triggers on a Custom Setting. Any validation of data, update of related records, or other actions that you might use workflow or a trigger to perform for a Custom Object have to be implemented differently for a Custom Setting.
  • No page layouts or record types – You can’t re-arrange fields on the page layout for Custom Settings. Custom Settings aren’t really intended to be visible to every-day users. If you need them to be, you can create Visualforce pages to allow users to view and manipulate Custom Setting data.

So if Custom Settings are so limited, why use them?

Avoiding Governor Limits

Depending on how your Apex code interacts with Custom Settings, they can have zero impact on certain governor limits. That’s right – you can retrieve all of the values in a Custom Setting with absolutely no impact on the governor’s count of the number of queries you’ve performed or the number of rows you’ve retrieved.  This makes Custom Settings particularly useful for reference data, like lists of Postal Code / State mappings.

There are a few caveats, however. First, you have to query the Custom Setting in a very specific way in order to take advantage of this “no governor limit” feature. Specifically, you have to use the Custom Setting’s GET methods, not SOQL, to query for data. See the Apex Language Reference for more information. Second, other governor limits, like those on heap size and number of script statements, do still apply. Even with these caveats, though, Custom Settings can provide a welcome relief from the limits on queries and rows.

Hierarchical Access to Data

There are two types of Custom Settings: List and Hierarchy. List-type Custom Settings are very similar to Custom Objects, but Hierarchy-type Custom Settings are very different.  Hierarchy Custom Settings allow you to associate specific rows with specific Users or Profiles. For example, you could define a Hierarchy Custom Setting that associates a different commission rate with different sales reps, with separate rows for each sales rep’s User Id. Then you could add a formula field to the Opportunity object, and reference the Custom setting with a formula like:  $Setup.CustomSettingName__c.CustomSettingFieldName__c.  Whenever someone views an Opportunity record, the formula will be evaluated, and Salesforce will find the Custom Setting row for the currently-running User; if none is found, it will find the row for the current User’s Profile (if one has been defined); and if none is found again, it will find an organization-wide default value (if defined).

This ability to define hierarchical data is very powerful, as it allows you to define user-specific customizations. A common use of Hierarchy Custom Settings is to define application-specific defaults on a user-by-user basis. For example, imagine you’ve developed a Visualforce page displays a list of Accounts, allows the user to select one, and then displays the Cases for that Account. You could store each user’s most recently selected Account in a Hierarchy Custom Setting, and then, the next time the user visits the Visualforce page, it could pre-select the Account that the user selected the last time he was on the page.