You will definitely get it from here!

Deploying from Sandbox - Loss of Permissions, Page Assignments, Field Security etc. When you add profiles to assign permissions in a change set, it only impacts the components of the change set. Change sets are never destructive, so they can't remove permissions you've assigned in production. You are safe to include the profiles during the change set deploy. Just be aware some Profile settings are always transferred when you include the profile in the change set (e.g. Profile's system permissions). To avoid overwriting the production profile settings from sandbox, simple solution is to first send change set with anything (e.g. Account custom field) which is the same on prod and sandbox + all profiles from prod to sandbox - this will apply the production permissions to sandbox - and then you can send your change set from sandbox to prod. As sandbox has already been updated to prod status, you won't overwrite anything and only add new stuff to the profiles on pro

There are several differences and several similarities as well.  Similarities:   They both create a one (parent) to many (children) relationship. One Account could have many Opportunites on it. They both create a related list on the parent object listing the children. Both kinds of relationships are created from the child object in salesforce.com by creating a field that represents the relationship. Differences: Unless you specify explicitly when creating the relationship, a child in a master-detail reclationship typically cannot be re-parented. With a lookup relationship you just click the magnifying glass next to the lookup field from the child record. (Standard salesforce.com objects are sort of an exception here.) With a master-detail relationship, when you delete the parent record, the child records are deleted as well. With a lookup relationship, the child records are orphaned. With a master-detail relationship, you are able to use the "rollup summary&

In multi-threaded applications where multiple threads make calls to the methods of a single object, it is necessary that those calls be synchronized. If code is not synchronized, then one thread might interrupt another thread and the object could be left in an invalid state. A class whose members are protected from such interruptions is called thread-safe. Although, there is no rule that makes the code thread safe, the only thing you can do is make sure that your code will work no matter how many times is it being actively executed, each thread can be interrupted at any point, with each thread being in its own state/location , and this for each function (static or otherwise) that is accessing common objects. If a method (instance or static) only references variables scoped within that method then it is thread safe because each thread has its own stack: In this instance, multiple threads could call ThreadSafeMethod concurrently without issue. public class Thing { publ