I've opened a case for this, 10197829, but wanted to report it here as well in hopes of getting it noticed/resolved faster.  I realize this limit is no longer enforced, but older code that checks to see if the limit has been exceeded is now erroring out due to this issue.  Yes, the code can be fixed but in this case the code is part of a managed package with several major versions in the wild and fixing this would require fixing and pushing updates to almost 30 different major releases.

To reproduce the issue, simply execute this in the developer console:

System.debug( Limits.getScriptStatements() );

You'll see that it both returns 200,000 and the cumulative stats will report that 200,000 of 200,000 script statements have been executed.  See this log:

30.0 APEX_CODE,DEBUG;APEX_PROFILING,FINEST;CALLOUT,ERROR;DB,DEBUG;SYSTEM,DEBUG;VALIDATION,ERROR;VISUALFORCE,ERROR;WORKFLOW,ERROR
Execute Anonymous: System.debug( Limits.getScriptStatements() );
Execute Anonymous: System.debug( Limits.getLimitScriptStatements() );
09:04:43.038 (38268000)|EXECUTION_STARTED
09:04:43.038 (38284000)|CODE_UNIT_STARTED|[EXTERNAL]|execute_anonymous_apex
09:04:43.038 (38842000)|SYSTEM_METHOD_ENTRY|[1]|Limit.getScriptStatements()
09:04:43.038 (38906000)|SYSTEM_METHOD_EXIT|[1]|Limit.getScriptStatements()
09:04:43.038 (38930000)|SYSTEM_METHOD_ENTRY|[1]|System.debug(ANY)
09:04:43.038 (38945000)|USER_DEBUG|[1]|DEBUG|200000
09:04:43.038 (38953000)|SYSTEM_METHOD_EXIT|[1]|System.debug(ANY)
09:04:43.038 (38964000)|SYSTEM_METHOD_ENTRY|[2]|Limit.getLimitScriptStatements()
09:04:43.038 (38996000)|SYSTEM_METHOD_EXIT|[2]|Limit.getLimitScriptStatements()
09:04:43.039 (39008000)|SYSTEM_METHOD_ENTRY|[2]|System.debug(ANY)
09:04:43.039 (39019000)|USER_DEBUG|[2]|DEBUG|200000
09:04:43.039 (39027000)|SYSTEM_METHOD_EXIT|[2]|System.debug(ANY)
09:04:43.129 (39069000)|CUMULATIVE_LIMIT_USAGE
09:04:43.129|LIMIT_USAGE_FOR_NS|(default)|
  Number of SOQL queries: 0 out of 100
  Number of query rows: 0 out of 50000
  Number of SOSL queries: 0 out of 20
  Number of DML statements: 0 out of 150
  Number of DML rows: 0 out of 10000
  Number of code statements: 200000 out of 200000 ******* CLOSE TO LIMIT
  Maximum CPU time: 0 out of 10000
  Maximum heap size: 0 out of 6000000
  Number of callouts: 0 out of 10
  Number of Email Invocations: 0 out of 10
  Number of fields describes: 0 out of 100
  Number of record type describes: 0 out of 100
  Number of child relationships describes: 0 out of 100
  Number of picklist describes: 0 out of 100
  Number of future calls: 0 out of 10

We get lots of questions on code coverage and deployment and how those are impacted by managed packages (and managed package unit test failures).  I was hoping that someone at SFDC could confirm/explain that managed packages are not considered as part of your code coverage percentage for deployment or on the Apex Classes page (where you click the code coverage link to calculate your org's coverage) and that managed package unit test failures will not prevent customer code from deploying to production (unless they've explicitly added the runAllTests="true" option in ant deployment).

 

I'd like to have a good authoritative response from an internal SFDC development resource to send to customers as they quite frequently get different answers on this issue when asking SFDC support.  I'm not looking for a huge response, just a basic explanation and confirmation that managed packages are no longer part of the equation when it comes to customer code.

 

Here are some resources I've found that give a brief mention that managed packages are not considered when calculating code coverage:

 

http://na5.salesforce.com/help/doc/en/code_run_tests.htm

 

Note this statement:

 

75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.

Note the following:

• When deploying to a production organization, every unit test in your organization namespace is executed.
• Calls to System.debug are not counted as part of Apex code coverage.
• Test methods and test classes are not counted as part of Apex code coverage.
• While only 75% of your Apex code must be covered by tests, your focus shouldn't be on the percentage of code that is covered. Instead, you should make sure that every use case of your application is covered, including positive and negative cases, as well as bulk and single record. This should lead to 75% or more of your code being covered by unit tests.

My comment: Your organization namespace doesn't include managed packages as each managed package has it's own namespace.

 

Also: https://na5.salesforce.com/help/doc/en/code_manage_packages.htm

 

Specifically this note near the bottom:

 

The code coverage value computed by Calculate your organization's code coverage might differ from the code coverage value computed after running all unit tests using Run All Tests. This is becauseCalculate your organization's code coverage excludes classes that are part of installed managed packages while Run All Tests doesn't.

 

Thanks,

Hi All,

I had scheduled around 22 Jobs till last Friday on on SF Org with different schedules. All these 22 jobs were visible in Scheduled Jobs Tab. Starting from this Monday(16th Feb 2015) I'm getting an Error : System.AsyncException: You have exceeded the maximum number (5) of Apex scheduled jobs when I try to schedule the same number of Jobs.
Its allowing only 5 Jobs to be submitted. 

Org might have been upgraded to Spring 2015 over the weekend. As per the Spring 2015 notes, we can use Apex Flex Queues to shcedule upto 100 Apex Jobs. We tried activating the Apex Flex Queue from Critical Updates section, but still the issue persists.

Need advise on what can be done to get the limit back to 100.

I've opened a case for this, 10197829, but wanted to report it here as well in hopes of getting it noticed/resolved faster.  I realize this limit is no longer enforced, but older code that checks to see if the limit has been exceeded is now erroring out due to this issue.  Yes, the code can be fixed but in this case the code is part of a managed package with several major versions in the wild and fixing this would require fixing and pushing updates to almost 30 different major releases.

To reproduce the issue, simply execute this in the developer console:

System.debug( Limits.getScriptStatements() );

You'll see that it both returns 200,000 and the cumulative stats will report that 200,000 of 200,000 script statements have been executed.  See this log:

30.0 APEX_CODE,DEBUG;APEX_PROFILING,FINEST;CALLOUT,ERROR;DB,DEBUG;SYSTEM,DEBUG;VALIDATION,ERROR;VISUALFORCE,ERROR;WORKFLOW,ERROR
Execute Anonymous: System.debug( Limits.getScriptStatements() );
Execute Anonymous: System.debug( Limits.getLimitScriptStatements() );
09:04:43.038 (38268000)|EXECUTION_STARTED
09:04:43.038 (38284000)|CODE_UNIT_STARTED|[EXTERNAL]|execute_anonymous_apex
09:04:43.038 (38842000)|SYSTEM_METHOD_ENTRY|[1]|Limit.getScriptStatements()
09:04:43.038 (38906000)|SYSTEM_METHOD_EXIT|[1]|Limit.getScriptStatements()
09:04:43.038 (38930000)|SYSTEM_METHOD_ENTRY|[1]|System.debug(ANY)
09:04:43.038 (38945000)|USER_DEBUG|[1]|DEBUG|200000
09:04:43.038 (38953000)|SYSTEM_METHOD_EXIT|[1]|System.debug(ANY)
09:04:43.038 (38964000)|SYSTEM_METHOD_ENTRY|[2]|Limit.getLimitScriptStatements()
09:04:43.038 (38996000)|SYSTEM_METHOD_EXIT|[2]|Limit.getLimitScriptStatements()
09:04:43.039 (39008000)|SYSTEM_METHOD_ENTRY|[2]|System.debug(ANY)
09:04:43.039 (39019000)|USER_DEBUG|[2]|DEBUG|200000
09:04:43.039 (39027000)|SYSTEM_METHOD_EXIT|[2]|System.debug(ANY)
09:04:43.129 (39069000)|CUMULATIVE_LIMIT_USAGE
09:04:43.129|LIMIT_USAGE_FOR_NS|(default)|
  Number of SOQL queries: 0 out of 100
  Number of query rows: 0 out of 50000
  Number of SOSL queries: 0 out of 20
  Number of DML statements: 0 out of 150
  Number of DML rows: 0 out of 10000
  Number of code statements: 200000 out of 200000 ******* CLOSE TO LIMIT
  Maximum CPU time: 0 out of 10000
  Maximum heap size: 0 out of 6000000
  Number of callouts: 0 out of 10
  Number of Email Invocations: 0 out of 10
  Number of fields describes: 0 out of 100
  Number of record type describes: 0 out of 100
  Number of child relationships describes: 0 out of 100
  Number of picklist describes: 0 out of 100
  Number of future calls: 0 out of 10

I've been developing out Visualforce pages in Chrome since we started using Salesforce. Now since the Summer '13 release to our sandbox, there is no longer intellisense for apex code, and every time I tab, where before it would function like normal, now it tabs me out of the box. I checked the Summer '13 release notes, but haven't seen anything about this.

 

Anyone know what's going on?

It seems that the new Summer'13 update enforces you to work with 18 character ID's always. For example, this happens in apex:

 

Id Id15 = string.valueOf(Id18).substring(0,15);
System.AssertEquals (Id15,Id18);

 

Pre-Summer that assertion fails, as Id15 is the 15 character Id and Id18 is the 18 character Id.
In our custom code many times we use Custom Setting and Custom Labels to avoid hardcoding recordtypes, profiles and other "constant" values. We usually worked with 15 character Ids as Salesforce (SOQL) sometimes returns 15 and other times returns 18 character Ids.

 

Now it seems the ID type always returns 18 character, if you do something like this the assertion is true:

 

Id Id15 = '012200000005byN';
System.AssertEquals (Id15,'012200000005byNAAQ');

 

As this is happening now with the Summer'13 but not happening before with Spring'13, this invalidates many coding.

We found this problem as Salesforce triggered a deep system error like this Salesforce System Error: 1619326252-34083 (1564369920) (1564369920) trying to compare a SelectOption loaded with record types with a Custom Settings String Id Stored.

 

This is a really weird annoyance. You can take a workaround working always with ID type instead of storing Ids into Strings, and always working with 18 character Ids, wether you hardcode Ids into apex and formulas (not a good approach) or you use custom setting and labels to store the ids.

 

Hope this helps... I lost all morning trying to figure out this.

Hi All, I'm trying to package my release managed package, and i'm getting lot of failures related to the same error: 
"System.LimitException: Your runAllTests request is using too many DB resources." 

I was able to package before, but seems like we have a new limitation now.... 
I really need this package to go live ASAP and of course, this is a BLOCKER. 

Notice that ALL MY TEST CASES HAVE 0 FAILURES if i run them individually. 

Thanks in advance, 
J.

We get lots of questions on code coverage and deployment and how those are impacted by managed packages (and managed package unit test failures).  I was hoping that someone at SFDC could confirm/explain that managed packages are not considered as part of your code coverage percentage for deployment or on the Apex Classes page (where you click the code coverage link to calculate your org's coverage) and that managed package unit test failures will not prevent customer code from deploying to production (unless they've explicitly added the runAllTests="true" option in ant deployment).

 

I'd like to have a good authoritative response from an internal SFDC development resource to send to customers as they quite frequently get different answers on this issue when asking SFDC support.  I'm not looking for a huge response, just a basic explanation and confirmation that managed packages are no longer part of the equation when it comes to customer code.

 

Here are some resources I've found that give a brief mention that managed packages are not considered when calculating code coverage:

 

http://na5.salesforce.com/help/doc/en/code_run_tests.htm

 

Note this statement:

 

75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.

Note the following:

• When deploying to a production organization, every unit test in your organization namespace is executed.
• Calls to System.debug are not counted as part of Apex code coverage.
• Test methods and test classes are not counted as part of Apex code coverage.
• While only 75% of your Apex code must be covered by tests, your focus shouldn't be on the percentage of code that is covered. Instead, you should make sure that every use case of your application is covered, including positive and negative cases, as well as bulk and single record. This should lead to 75% or more of your code being covered by unit tests.

My comment: Your organization namespace doesn't include managed packages as each managed package has it's own namespace.

 

Also: https://na5.salesforce.com/help/doc/en/code_manage_packages.htm

 

Specifically this note near the bottom:

 

The code coverage value computed by Calculate your organization's code coverage might differ from the code coverage value computed after running all unit tests using Run All Tests. This is becauseCalculate your organization's code coverage excludes classes that are part of installed managed packages while Run All Tests doesn't.

 

Thanks,

I have the following validation code:

 

ISPICKVAL(Status__c, "Pending")

 

How to make this applicable ONLY if the created date is not today, or if the modifying user is a connection user (salesforce to salesforce user)?? Is this even possible on Group Edition??