I am using version 33.0 of the JavaScript AJAX Toolkit (/soap/ajax/33.0/connection.js), and am making a describeLayout() call. I am trying to retrieve a limited subset of the describeLayout metadata --- specifically, just the recordTypeMappings for a few specific Record Types. There are no examples in the AJAX Toolkit documentation of doing this, but it (mostly) works and is documented in the API docs (http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_describelayout.htm) (with different syntax, which is worrying as well).

Here's my basic call --- I get the describeLayout for the Account object, but pass in 3 Record Type Ids:
 

var result = sforce.connection.describeLayout('Account',["012G0000000jVOmIAM","012G0000000jdgIIAQ","012G0000000jVOhIAM"]);

This returns a valid payload, but what's weird is that it only returns recordTypeMappings for the last 2 Record Types I requested, not 3! If I request 2 Record Types, it returns recordTypeMappings for just the last Record Type I requested! And when I request it for just 1 Record Type, it returns ALL Record Type mappings. 



So my question is, is this the way it is supposed to be working? Or is this a bug?

Hi All,

I've recently started having issues with production code whereby an overnight batch started complaining about "Batchable instance is too big". I suspected that the heap size might have at some point exceeded its limits (due to the batch having a stateful shared map that accumulates data across the batch execution blocks). Upon inspection the system was throwing error when the heaps size reached 42% (approx 5.4 million bytes) of its heap size capacity. Confused I called all the Limits class methods at the end of the execution block to see if anything had exceed its limts, yet the only thing even remotely alarming was the heap size, of which again was not exceeding the limit.

In response I tried to replicate the issue with a simple example. The class I created is shown below:

  global class TestBatch implements Database.Batchable<sObject>, Database.Stateful
  {
      global Map<Integer, Integer> globalMap = new map<Integer, Integer>();

      global Database.QueryLocator start(Database.BatchableContext bc) 
      {
          return Database.getQueryLocator('SELECT Id FROM Account');
      }

      global void execute(Database.batchableContext bc, List<sObject> objects)
      {
          Integer i=globalMap.size();
          final Integer interval = 1000;
          for(Integer x=0; x<100000; ++x)
          {
              globalMap.put(i, i);
          
              if(Math.mod(x,interval) == 0) 
              {
                  System.debug(LoggingLevel.Error, 'Limits.getHeapSize(): ' + Limits.getHeapSize());
                  System.debug(LoggingLevel.Error, 'Limits.getLimitHeapSize(): ' + Limits.getLimitHeapSize());
              }
              
              ++i;
          }
      }
      
      global void finish(Database.BatchableContext bc) 
      {
      }
  }

This code should easily compile in any sandbox. If you open the command line and enter the following command:

  Database.executeBatch(new TestBatch(), 1);

It should iterate throught few times, assuming that there are a few accounts in the system. After two successful execution blocks, the system started complaining with the same error, even though the heap size only reached approximately 2.7 million bytes.

Does anyone have any throughts as to why Salesforce complains about a large instance when it hasn't even reached half way through their enforced limits?

In our org, we have two users whose records are returned twice when called via APEX, or via the API.

If this SOQL is executed:

Selected Id, LastViewedDate, LastReferencedDate from User where Id='005xxxxxxx'

is executed in our org, you can see where the same result is returned twice. In fact, if you include a "limit 1" on the end of that SOQL query, it STILL returns those two, identical results.

If both LastViewedDate and LastReferencedDate are removed from the query, only one result is returned for each record, which is the expected, normal behavior.

Anyone else seen anything strange like this?