• Sam Kamensky
  • NEWBIE
  • 30 Points
  • Member since 2015

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 1
    Likes Given
  • 6
    Questions
  • 9
    Replies
Background:

The FieldHistoryArchive table is neither available from dataloader nor dataloader.io
So I had to go with Workbench on this one.

When querying the FieldHistoryArchive (whether you turn on include archived records or not), your query result will only show certain fields of the query based off of the other fields that were included in your query.
Additionally, it seems that workbench cannot resolve the field names for NewValue and OldValue.

For example, and my use case, when I use this query:
 
SELECT Id,NewValue,OldValue,ParentId FROM FieldHistoryArchive

My columns in the result are
Id    Unknown_Field__1    Unknown_Field__2    ParentId

and the data from the query successfully displays.

However if I use the query:
 
SELECT Field,Id,NewValue,OldValue,ParentId FROM FieldHistoryArchive


My columns in the result are
Field    Id    ParentId



and the OldValue and NewValue are skipped completely!

Is this a bug?
 
I have code that creates CaseShare records for the case based on some criteria from another class.

The code that creates the CaseShare is called both on update and creation of the case. It works smoothly when the case is updated, but not when it's created. When attempting to debug my issue I got confused because the debug logs apparently showed that the records were being inserted. In fact, the debug logs show the same exact things for when the case is inserted (the DML doesn't work then) as when the case is updated (the DML does work then).

Here is the debug log for both when the case is created (DML doesn't work then) and when the case is updated (DML does work) line 55 is where my insert is happening:
USER_DEBUG|[54]|DEBUG|Value of csShareList: (CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000004JDY4IAO}, CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000000dNNWIA2}, CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000000dBqjIAE}, CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000005aSlXIAU})
00:53:58.516 (755158871)|SYSTEM_METHOD_EXIT|[54]|System.debug(ANY)
00:53:58.516 (755161876)|STATEMENT_EXECUTE|[55]
00:53:58.516 (755228490)|DML_BEGIN|[55]|Op:Insert|Type:CaseShare|Rows:4
00:53:58.516 (755248812)|HEAP_ALLOCATE|[EXTERNAL]|Bytes:20
00:53:58.516 (825013969)|DML_END|[55]

Additionally, here's the code that does the insert:
if (!csShareList.isEmpty()){
                System.debug('Value of csShareList: ' + csShareList);
                insert (csShareList);
                
            }

 
I think my two options are pass the id to a class and query the fields I need there, or, pass the entire sObject and do no querying.

Assuming that the sObject will always come from a trigger (as I understand it no querying is needed when using trigger.new as it automatically contains the entire sObject), do I ever need to query again? Or can I simply pass the sObject I get from the trigger to any and every class I want? 
I have a field in two sandboxes with the same ID (they both came from production). The field is on the Opportunity
Let's call them sandbox1 and sandbox2.
I changed the API name of the field in sandbox1 (along with some apex references).
But when I deployed the change set from sandbox1 to sandbox2, instead of changing the API name in sandbox2 to match the API name in sandbox1, it created a new field with the changed API name and left the old field intact and unchanged.
Is it possible to rename API names of fields with change sets? Or will it always create a new field when I move it from one environment to another?
I have three pieces of code on the Opportunity that do three different things.
However, one thing they have in common is that they all update a single field to some value.

I have two options. Either I can:
1. Have each of the three pieces of code update the field whenever their logic is found to be true
OR
2. I can have a formula field on the Opportunity determine what the value should be, taking into account all three pieces of code, and use a workflow to update the value of the field to the formula value.

The advantage to number 1 is that whenever I or someone else looks at the code in the future, all of the components will be in one piece of code. 
I won't have to hunt around to find that field on the opportunity. I'll be able to see all of the functionality for each piece of code in one place.

The advantage to number 2 is that I can use the logic in workflows and I only have to update it in one place if there are any changes to how I want this field to get updated.
For example:

For the sObject method addError(errorMsg) the documentation says to mark "a record with a custom error message and prevents any DML operation from occurring."

Does that mean the system will mark internally that a record occurred, and a developer can search for these errors later on?
Or does it mean that the error will be available for the duration of the transaction in which the marking of the error occured?

Seen Here:
https://developer.salesforce.com/docs/atlas.en-us.198.0.apexcode.meta/apexcode/apex_methods_system_sobject.htm#apex_System_SObject_addError

Thank you
 
I have code that creates CaseShare records for the case based on some criteria from another class.

The code that creates the CaseShare is called both on update and creation of the case. It works smoothly when the case is updated, but not when it's created. When attempting to debug my issue I got confused because the debug logs apparently showed that the records were being inserted. In fact, the debug logs show the same exact things for when the case is inserted (the DML doesn't work then) as when the case is updated (the DML does work then).

Here is the debug log for both when the case is created (DML doesn't work then) and when the case is updated (DML does work) line 55 is where my insert is happening:
USER_DEBUG|[54]|DEBUG|Value of csShareList: (CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000004JDY4IAO}, CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000000dNNWIA2}, CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000000dBqjIAE}, CaseShare:{CaseAccessLevel=Edit, CaseId=500180000050EsoAAE, UserOrGroupId=005E0000005aSlXIAU})
00:53:58.516 (755158871)|SYSTEM_METHOD_EXIT|[54]|System.debug(ANY)
00:53:58.516 (755161876)|STATEMENT_EXECUTE|[55]
00:53:58.516 (755228490)|DML_BEGIN|[55]|Op:Insert|Type:CaseShare|Rows:4
00:53:58.516 (755248812)|HEAP_ALLOCATE|[EXTERNAL]|Bytes:20
00:53:58.516 (825013969)|DML_END|[55]

Additionally, here's the code that does the insert:
if (!csShareList.isEmpty()){
                System.debug('Value of csShareList: ' + csShareList);
                insert (csShareList);
                
            }

 
I think my two options are pass the id to a class and query the fields I need there, or, pass the entire sObject and do no querying.

Assuming that the sObject will always come from a trigger (as I understand it no querying is needed when using trigger.new as it automatically contains the entire sObject), do I ever need to query again? Or can I simply pass the sObject I get from the trigger to any and every class I want? 
For example:

For the sObject method addError(errorMsg) the documentation says to mark "a record with a custom error message and prevents any DML operation from occurring."

Does that mean the system will mark internally that a record occurred, and a developer can search for these errors later on?
Or does it mean that the error will be available for the duration of the transaction in which the marking of the error occured?

Seen Here:
https://developer.salesforce.com/docs/atlas.en-us.198.0.apexcode.meta/apexcode/apex_methods_system_sobject.htm#apex_System_SObject_addError

Thank you
 
Hi,

    Can any one let me know that total how many standard objects are available in salesforce ?


    Response is highly Appriciated.
  • January 07, 2014
  • Like
  • 0

Recently, I was writing some classes that needed to detect if the org they were in was a sandbox or not and determine which endpoint to call accordingly. Since there isn's an isSandbox method in Apex, I had to create my own. This will work in visualforce controllers/extensions and from standard classes. You can read the full details at http://www.ericsantiago.com/eric_santiago/2011/12/determining-salesforce-server-pod-and-if-sandbox-via-apex.html

 

Code as follows

 

public String currentPod { 
            String server;
            
            if (ApexPages.currentPage() != null){ //called from VF page
            		server = ApexPages.currentPage().getHeaders().get('X-Salesforce-Forwarded-To');
            } else { //called via standard class
            		server = URL.getSalesforceBaseUrl().getHost();
            }
            
            if ( server != null && server.length() > 0){
                server = server.substring(0 ,server.indexOf('.'));
                
            }
            return server ; 
   }

   public Boolean isSandbox {
            String pod = currentPod();
            if (pod != null && pod.length() > 0 && pod.toUpperCase().startsWith('C')){
                return true;
            }
            return false;
   }

 

When using the data loader, I cannot view the "Login IP Range" object in the "Select Data Objects" screen. I have the most recent version. Is this something that needs be made available to us? It would be extremely helpful to us when updating profiles and just being able to export our current allowed ranges. When updating profiles and just being able to export our current allowed ranges.