You need to sign in to do that
Don't have an account?
Fran Korb
SELECT DISTINCT
I am trying to build a pick list of countries from the Contact.MailingCountry field in a very large community (200,000+ members).
SOQL does not provide the SQL SELECT DISTINCT statement and there are several alternatives found on the web.
The following query fails with 'Too many query rows: 50001’ :
SELECT n.Member.Contact.MailingCountry c, COUNT_DISTINCT(n.Member.Id) FROM NetworkMember n WHERE n.Member.IsActive = TRUE GROUP BY n.Member.Contact.MailingCountry LIMIT 50
Is there a better way to build a list of unique entries for a specific field in a large database that is optimized and performant?
SOQL does not provide the SQL SELECT DISTINCT statement and there are several alternatives found on the web.
The following query fails with 'Too many query rows: 50001’ :
SELECT n.Member.Contact.MailingCountry c, COUNT_DISTINCT(n.Member.Id) FROM NetworkMember n WHERE n.Member.IsActive = TRUE GROUP BY n.Member.Contact.MailingCountry LIMIT 50
Is there a better way to build a list of unique entries for a specific field in a large database that is optimized and performant?
First, try running the following query (Removing the first selected should reduce your result set just a bit) I'm guessing you'll still hit the same error though, so you might want to try some other approach.
How about the following: Create a batchable class that writes the MailingCountry to a custom object? Create a custom object with an External Id of say country, then have the batch job write to that object. Make the external id case SENSITIVE if you'd like to determine if users are using different cases of countries. Below is an example of what that batch job might look like.
Once you have the custom object, then you can export it to excel or run reports (There should be a managable number of countries / records to work with).
Also, you'll likely want to do some data cleanup, validation rules, etc to perhaps manage those countries a bit better in the future.
All Answers
The 'Too many query rows: 50001’ is very hard to solve.
- The "simple" workaround is a batch which will count the total numbers browsing all the data sorting by Member.Contact.MailingCountry (calculated and stored total values).
The big problem is the scope of this batch which is not suitable for evaluating total numbers (the scope can split the values of the same MailingCountry that makes things more difficult). The readings will not be longer than some minutes for some hundreds of thousands of records but the writings will be longer.Create a working dataset with coarse aggregations
https://resources.docs.salesforce.com/sfdc/pdf/big_objects_guide.pdf
Regards
- Declarative Rollups for Lookups!
Volume Considerations. For each rollup, there is a maximum of 50,000 child relation records that can be summarised each time child record/s insert/update/delete operations are made (which may process several configured rollups). The rollup processes children to rollup by their parent record relationship and an optional further filter if provided. Meaning so long as this relationship does not result in more than 50,000 child records per parent parent record it will be successful. Take a look at this blog post which describes some new configuration settings (see bottom of blog post) to help calibrate the tool when running the Scheduled or Calculate jobs to help work within the 50,000 row limit.https://github.com/afawcett/declarative-lookup-rollup-summaries
First, try running the following query (Removing the first selected should reduce your result set just a bit) I'm guessing you'll still hit the same error though, so you might want to try some other approach.
How about the following: Create a batchable class that writes the MailingCountry to a custom object? Create a custom object with an External Id of say country, then have the batch job write to that object. Make the external id case SENSITIVE if you'd like to determine if users are using different cases of countries. Below is an example of what that batch job might look like.
Once you have the custom object, then you can export it to excel or run reports (There should be a managable number of countries / records to work with).
Also, you'll likely want to do some data cleanup, validation rules, etc to perhaps manage those countries a bit better in the future.