Hot answers tagged

14

Take a look at Working with Very Large SOQL Queries. Querying for field != null will hurt your performance. Typically, a custom index isn’t used in these cases. The queried values exceed the system-defined threshold. The filter operator is a negative operator such as NOT EQUAL TO (or !=), NOT CONTAINS, and NOT STARTS WITH. The CONTAINS ...


11

From documentation: The default timeout is 10 seconds. A custom timeout can be defined for each callout. The minimum is 1 millisecond and the maximum is 120,000 milliseconds. The maximum cumulative timeout for callouts by a single Apex transaction is 120 seconds. This time is additive across all callouts invoked by the Apex transaction.


8

Behind the scenes, when start() returns, it is handed back to a process that begins the process of breaking the items into the appropriate scope size. The process roughly looks like: List<List<Object>> objects = new List<List<Object>>(); Object[] temp = new Object[0]; Database.QueryLocator locator = batch.start(context); Iterator<...


7

Text field indexes do not index "null" values. In other words, the database can't reduce the cost for a query that filters for a null value in a text field. If most of your table has values, but a few do not, this can easily cause the query timeout exception you're receiving. Odds are, you'll probably need to resort to more drastic measures, such as perhaps ...


5

I suggest querying the child records in the execute method instead. This should speed up the start() method significantly. And it should solve the cpu time limit problem as well. public Database.QueryLocator start(Database.batchableContext context) { return Database.getQueryLocator( [SELECT Id FROM Foo__c WHERE ... AND ...] ) } public void ...


5

"CPU time" is the time taken by your code to execute, excluding database transaction time, callout time, etc. It is 10,000 ms for synchronous transactions. "Time limit exceeded" means your transaction waits for more than 120 seconds and your action was not executed within time frame. For example, you are waiting for response on call from webservice and your ...


5

The argument to HttpRequest.setTimout is a millisecond value so for 2 minutes: req.setTimeout(2 * 60 * 1000); PS With the clarification that the desire is to make the web service call after a 2 minute delay I suggest you experiment with this Need System.schedule cron string for run once approach. In your case you would build the cron string to be 2 minutes ...


5

The callout timeout is tricky, because it applies both to single callouts and as a cumulative limit across a transaction: The maximum cumulative timeout for callouts by a single Apex transaction is 120 seconds. This time is additive across all callouts invoked by the Apex transaction. Here, it looks like you're running into the cumulative version of this ...


5

Here's how I'd approach these queries. The date calculation can be simplified and updated to handle the time portion of the timestamp. SELECT s.subscriberKey , s.jobid , sub.EmailAddress FROM [_Sent] s INNER JOIN [_job] j ON j.jobid = s.jobid INNER JOIN _Subscribers sub ON s.SubscriberKey = sub.SubscriberKey where s.EventDate > convert(date, ...


4

CORRECTIONS The above solution did not work as you cannot convert a Managed package back to Beta if it was already released. And the version where we added the relevant field was released years before I contacted support. So no, the only thing you can do is either deprecated and remove the old field from the package and migrate it to a new packaged ...


4

One of the most important callouts that was not made here would be contained in the following query syntax: INNER JOIN [_job] j ON j.jobid = s.jobid INNER JOIN _Subscribers sub ON s.SubscriberKey = sub.SubscriberKey where s.EventDate > convert(date, getDate()-7) AND j.EmailName like '%TOBERESENTDK%' It is imperative that instead of: INNER JOIN ...


4

Debugging a CPU time issue is probably one of the more frustrating things to try to track down and resolve. One thing to keep in mind here is that the line of code that your error points to isn't necessarily the problem, it's just where you happened to go over the CPU limit. Measuring CPU time usage is more of a pain than, say, Query Rows (since each query ...


4

After googling around for a while, I found out that there is a ScratchOrgInfo record in the dev hub which precedes the scratch org record, and which remains in the database after the org has expired or been manually deleted. According to the docs: ScratchOrgInfo Represents a scratch org and its audit log. Use this object to create a scratch org and keep a ...


3

Your query uses 'anti-patterns' and doesn't use indexed fields that's why it sometimes times out on you. The Id Not IN(SELECT contact__c is not an efficient way to query because it requires the SOQL engine to look through every record. On top of that you then use an ORDER BY clause that's 2 levels deep on fields that aren't indexed. The ORDER BY takes a lot ...


3

I don't think it is possible. Meanwhile you can upvote this idea Session Timeout settings for a specific user.


3

Any activity on a session ID resets the timer. This includes polling, streaming, or generally doing anything at all that interacts with the user. Worse, implementing your own time out method in your page (e.g. calling /secur/logout.jsp if no action is detected), may result in the user's session expiring in a different tab, etc, which many users tend to do ...


3

I think i found the reason why its not selective query. When we use inner query SFDC cant use index. It doesnt matter whether we pass NULL into IN clause. If we just pass the list of IDS then query becomes selective and it works fine. Here is is screen shot of my test. This blog helped me to reach to this conclusion.


3

If you read properly in the link you have provided, The expires_in attribute is given on the call back URL and not as web service response. Even if you get expires_in there is still a catch. The expires_in will only tell the value from Org session settings/profile session settings and which can't be used to decide the actual timeout value. You have 2 ...


3

I've run into this in the past, and there have been a few other stack exchange posts on this. The problem is with the external web service, and the most practical approach is one of the 2 options: Run a scheduled batch job that runs hourly (or as you need) that calls out to the other system. If you get an exception, retry the call out via async apex. ...


3

I've previously outlined my go-to for timeout mitigation here. You can use the hidden _customObjectKey column in every DE and the % mod operator to split the processing of your query into multiple queries. For your query, you could split it into 3 queries like this: Query 1 SELECT Sub_ID , Field1 , Field2 , Field3 , Field4 , Field5 , Field6 , Field7 , ...


2

Try running the query using the new query resource feedback parameter in both environments. There may be a difference in the query plan being used based on the volume of data and available indexes. See Developing Selective Force.com Queries through the Query Resource Feedback Parameter Pilot There should be an option to access this in the Developer Console ...


2

If you were already in touch with SF support, it doesn't harm to ask them for more details, they have access to data & logs specific to your org. I believe the culprit is the following: Where Email != Null As far as I know the != operator can not rely on idexes and will always result in a full table scan. The documentation states: Typically, a ...


2

Unless you were to query the jobs through each iteration, you'd run into that problem because you'll never see them complete. Instead, you'd want something more like a do-while: AsyncApexJob[] jobs; do { jobs = [SELECT ... FROM AsyncApexJob WHERE Id IN :ids AND Status IN ('Queued','Processing')]; } while(!jobs.isEmpty()); Of course, you'll also run ...


2

For anyone who ends up on this question, or with this issue, Salesforce has confirmed this as a bug with Communities and has escalated on their end for a resolution in a next release. Session lockout time passes but community user is not logged out automatically Note that if you are exposing anything "sensitive" through your Community and need to ...


2

I know this is a late response but I've encountered this error in a similar situation (using Apex to make HTTP callouts to an external database). In my case I suspect the error was due to the large amounts of data being repeatedly created and deleted during testing, with a Data Storage limit approaching full. https://developer.salesforce.com/forums/...


2

Regarding to Salesforce support this somewhat relates to this Known Issue Enabling debug logs/opening developer console, can strongly affect the Apex CPU time when VF page utilizes a lot of getters and setters and as workaround they recommend to: Do not have Debug Logs against the running user Do not have the developer console open Debug the affected VF &...


2

Here is little effort to share what I know about these issues: Have you seen this in your environment as well? Yes, In various Salesforce environment I have seen this issue. This issue is not limited to Developer or Production instances. We have seen this in full sandbox instances. Instances in which it has been identified are na26, na2, na23 and ...


2

The session of Enterprise WSDL is governed by Session Settings by your administrator .You can navigate to SetUp | Security Controls | Session Settings to set the timeout value The default is 120 minutes (two hours) and maximum values is 12hrs(Longer session time outs can be not safe depending on the business.) If you make an API call, the inactivity timer ...


2

Learn about and use the Query Plan Tool to find out what is going wrong and then work on a fix based on that knowledge.


2

Like any database table, queries can become increasingly slower when a lot of entries are placed into the table. You can help alleviate this problem by setting up a History Retention Policy to limit how far back your records go. Once the retention period is met, those entries move from the FieldHistory table to the FieldHistoryArchive table to keep queries ...


Only top voted, non community-wiki answers of a minimum length are eligible