If it's not in Apex code you don't need the : and you need to add ( )
So your SOQL could be rewritten as:
SELECT Id, Syndication_Documents__c
WHERE Syndication_Documents__c IN ('a4fa0000000KzbV','a4fa0000000KzbW')
If you're doing it from Apex and have a Collection (Set, List, or Map) you can bind them to the query and avoid the ...
Well that was easy (does that sound sarcastic?). I installed the 32-bit Java runtime environment, so now I have two JREs: 32-bit one in C:\Program Files (x86)\Java\jre1.8.0_73 and 64-bit one in C:\Program Files\Java\jre1.8.0_73
And I didn't even have to change JAVA_HOME to get the data loader working, it just works now. Automagically. Not even PATH was ...
Yes, it's possible to mass convert leads in Apex Code. See the documentation on Database.convertLead here: Database.convertLead docs
You can convert up to 100 leads at a time and you can use it in a scheduled class or as part of a batch apex operation (or both) if you want to convert much larger sets of leads. The documentation linked above contains good ...
Inserting null values is an option that you need to manually set for the api call. Once you set that option you just leave the cells empty and it will null out any fields where the cell is empty.
In dataloader.io you set this option here:
That option is greyed out for me and from the dataloader.io discussion boards it looks like they haven't implemented ...
Figured out how to do this using Lexiloader, by referring to process.bat that comes with the official (Windows) Apex Data Loader, which just runs a Java class in the dataloader jar.
Here's a sample Windows command:
process confDir csvInsertArtist
And here's the equivalent OS X command line (assumes LexiLoader v.29 installed in /Applications, adjust path ...
1) If I need to load 10,000,000 (10 million) records into salesforce, Can I use Dataloader and select the 'Use Bulk API' option on settings screen?
The data loader supports any size file that your system can handle and Java can read in memory. In theory, it could support hundreds of millions of records. The bulk API has smaller limits, but the data loader ...
I would suggest you to go with data loader using SOAP API, which is by default (not Bulk API).
You do not need to write any code to use Data loader
It is tested solution, so no bugs
With SOAP API you will need around 500+ API (100000 records / 200 batch size = 500 API required) which is not too much (we have 100k API limit per 24 HRS for ...
Since you have already changed the setting of data loader "Insert null values".
so, in the .csv, email field will be blank. NO quotes, NO NULL word.
If you open the .csv in notepad or notepad++, it will show values like this where email and phone are showing blank:
You should successfully load the data.
You could certainly be able to extract and insert your custom settings via the data webservice APIs and also via the Apex data loader.
Another often seen practice is to have an Apex code snippet or maybe even Apex method which can be called to setup custom settings and perhaps some minimal test data. This Apex snippet or method can then be executed via the ...
Part of your code is only operating on the first record in the batch of records.
List<SC_Cadeia_de_Influencia__c> listaCadeia = [
WHERE PIN__c = :Trigger.new.PIN__c
The Trigger.new.PIN__c only gets the first element in the batch or records being inserted or ...
Yes that is correct, governor limits will apply to each batch, which in turn is decided by the batch size set on the dataloader.
The dataloader will chunk the records from your csv file in batches of the number of records you've specified, and hence the governor limits are therefore distributed.
The last modified date of the every record will definitely change ,since an update of record will eventually happen even if field values are not changed .
If you need to explicitly code such scenarios ,i would definitely recommend to do an explicit update and update only those records whose field values have changed .
The name method is not a good way of going about this. For one, it's a pain to change if others need to use the same functionality, or if you do want to fire triggers.
If you did want to make a "No triggers" flag, I would make it a custom checkbox field, then mark it as TRUE on your file before uploading via the data loader. If your trigger fires "Before" ...
These settings are stored in the CustomObjectTranslation metadata object, and you can deploy them in any tool that uses the metadata API. (You can make this change by using the metadata APIs either using ANT and manually building a package.xml, or by writing a custom script to do it using SOAP.)
You can also use Gearset to make this change*. To do this ...
You're in luck: you don't have to wait until Summer '19 hits your org, bringing with it Polymorphic SOQL, or use a subquery on WhatId, because you can query through the non-polymorphic AccountId relationship on the Task and Event objects:
SELECT Id FROM Task WHERE Account.RecordType.DeveloperName = 'My_Record_Type'
Opportunities don't have any polymorphic ...
Yes, SFDX commands do consume and count towards the limits of the resources they utilize on your target orgs, including API calls, Bulk API jobs, streaming and platform event consumption, and others.
You can check your limits consumption (which also counts as an API call!) by doing sfdx force:limits:api:display.
In DataLoader (or other API tools) you can specify the batch size to be 30 ;) Means more round trips between the client and the server but this will make sure you stay within the limits. There's also similar setting in Excel Connector if you're using this to load data.
As for the actual root cause... I suspect the logic you're talking about is stored in ...
This sounds like informatica is using the bulk API. This doesn't actually create the records as they're being uploaded like the non-bulk SOAP and REST APIs do but places them into a queue where salesforce processes them asynchronously.
Take a look at the informatica options to see if you can fall back to the SOAP API if this is a serious issue; it will be ...
There is Test.loadData() which can be used to load a number of testing records from a CSV file stored as a static resource.
This is great if the intention of the data is for running automated test cases. Not so useful if you want to setup an org for an actual user.
You can use external ids to relate records that you are loading with the parent (i.e. records that they look up to - both Master Detail and Lookup)
Accounts and Contacts is a great example. If you have Accounts loaded in, and they have an External Id Field say External_Id__c, then you can use this field to relate the Contacts you are loading to the Accounts ...
For objects with self-reference (aka "Hierarchy") fields, the best method is to load in two steps:
Load all records but leaving out the ParentId field (remove it from Talend schema).
Update all records to set ParentId values (map only Id or Ext-Id, and the ParentId).
For 2 objects with cyclical references, the approach is similar:
Load all records of ...
NOTE: All of these answers depend on the OOTB functionality. It is possible to adapt the Data Loader to perform all of these actions by using Java and importing the classes; this isn't an answer that covers that in-depth. There is an OSS version of ADL on GitHub, if you're so inclined.
GUI: Does Dataloader GUI work with SAML?
No, SAML requires browser ...
You have two options here.
Either download Apex dataloader latest version which support TLS 1.2
and second not so good option is disable this update in your org.
The following steps can be followed to disable this feature:
Navigate to Setup
In the Quick Find bar, type in Critical Updates
Select Critical Updates
Locate the Require TLS 1.1 or higher ...
As you mentioned in the Question, I guess workbench operated in the Bulk API but in Parallel Processing mode. Parallel Processing mode is known to throw these kind of errors. Refer to the section Managing Locks to Maximize the Benefits of Parallelism in this The Salesforce Bulk API - Maximizing Parallelism and Throughput Performance When Integrating or ...
The Non Profit stater pack code is all up on GitHub - you'll probably want to look at the Contacts and Org piece for Opportunity triggers:
If you have access to the PowerofUs Hub, that's a good resource for questions as well.
For other packages, the ISV can login to you org if you grant them access, and when they do, they'll see their code/debug in full in ...
yes, history cannot be created since AccountHistory, CaseHistory and ContactHistory doest't support create() operation.
See the following docs for more information.
Account History SOAP API
Contact History SOAP API
Case History SOAP API
Your best bet will to create a custom object and store history information in it.