Instead of using Standard Query Language (SQL), Salesforce decided to create it’s own variation of the language for querying their databases. Salesforce Object Query Language, known as SOQL, has a basic syntax that is very similar to SQL but there’s some differences.

Most developers that are new to Salesforce immediately notice that there’s know way to select all of the fields for an object. SOQL doesn’t have a wilcard operator like SQL does. For developers that have experience in languages like C#.NET, Java or PHP it’s really weird not being able to do something like

select * from tableName

Don’t fear! There is a way to Select All Fields in SOQL and this post will cover how to, and why it’s actually not a good idea. Using Dynamic SOQL and describes its possible to get a set of all of the fields and then query them.

In the below example, I’m going to assume that you want all of the fields for the Opportunity object.

// This is the object for which we required data.
Map<String, Schema.SObjectField> fieldMap = Opportunity.sObjectType.getDescribe().fields.getMap();
 
// Get all of the fields on the object
Set<String> fieldNames = fieldMap.keySet();

// Build a Dynamic Query String.
List<Opportunity> opps = Database.query('select ' + string.join(fieldNames, ',') + ' from Opportunity'); 

There’s another approach that can be used which requires the Id to work.

Id rId = 'SomeValidSFDCId';

DescribeSObjectResult describeResult = rId.getSObjectType().getDescribe();		
Map<String, Schema.SObjectField> fieldMap = describeResult.fields.getMap();
 
// Get all of the fields on the object
Set<String> fieldNames = fieldMap.keySet();

// Build a Dynamic Query String.
String soqlQuery = ' SELECT ' + string.join (fieldName, ',') + ' FROM ' + describeResult.getName() + ' Where Id =: rId';

// Need to return a generic list of sObject because we don't necessarily know exactly what the object is.
List<sObject> record = Database.query(soqlQuery);

The reason I don’t recommend using Dynamic SOQL like this is because it can cause issues with view state. Dealing with view state exceptions can be really frustrating and very time consuming. I’ve written about Debugging and Resolving View State problems in the past.

The main reason I abandoned this process though was that if two users update the same record or an async process updates records there’s a good chance the wrong values might be updated again or committed to the database over other changes.

In additional, it really goes against Salesforce Best practices and can lead to lots of little unexpected consequences. For example, Security practices aren’t very efficient when validating the fields this way. Where possible it’s always better to try and let the platform do the work.