+ Start a Discussion
KruviKruvi 

SELECT all

Hi

 

Is there any way to SELECT "All" the files of an object when using SOQL?

 

I know I'll need all the field of an object in my code and I'm trying avoid changing my SELECT query each time I add fields to the object.

 

How can I achive this?

 

Thanks

 

Best Answer chosen by Admin (Salesforce Developers) 
MandyKoolMandyKool

Hi Kruvi,

 

Its not possible in SOQL and I think there is a reason for this.

As developers will do "*" everytime, even if they have to select 1 or 2 fields.

 

This will lower the performance of the system(my thinking..) as the platform is multitanent. That is why there is no "*" metacharacter in SOQL. 

 

But yes, if you want to construct this kind of functionality you can develop it using Apex. But I knw its more painful to construct this kind of functionality than to add a field to your query each time :) 

I think the idea is good, we can give it a try ;) and implement it.

 

If you find any other way to do this plz let me knw as well. That can be really helpful.

 

All Answers

MandyKoolMandyKool

Hi Kruvi,

 

Its not possible in SOQL and I think there is a reason for this.

As developers will do "*" everytime, even if they have to select 1 or 2 fields.

 

This will lower the performance of the system(my thinking..) as the platform is multitanent. That is why there is no "*" metacharacter in SOQL. 

 

But yes, if you want to construct this kind of functionality you can develop it using Apex. But I knw its more painful to construct this kind of functionality than to add a field to your query each time :) 

I think the idea is good, we can give it a try ;) and implement it.

 

If you find any other way to do this plz let me knw as well. That can be really helpful.

 

This was selected as the best answer
sfdcfoxsfdcfox

Just adding my two cents here, but I recently found an article on the use of "SELECT *" in a generic database (i.e. MySQL, Postgre, MS-SQL). What they said makes sense; in normal database development, using the all fields notation is not just lazy (and yes, reduces system efficiency), but it reduces the self-documenting nature of the code you're using, and makes bugs harder to track down. The former is true because when you have an SQL statement that lists the fields it is using explicitly, that allows later developers to have an educated guess at which fields from the query will be used, which will reduce time spent on debugging. The latter is true because when you do use the all fields syntax, a mistyped field name or table name in some other part of the code might accidentally be a valid name, but not what the programmer intends. For example, given:

 

 

CREATE TABLE `CONTACT`(
   `FirstName` CHAR(40) NOT NULL,
   `LastName` CHAR(40) NOT NULL,
   PRIMARY KEY (`FirstName`,`LastName`),
   `Email1` CHAR(255),
   `Email2` CHAR(255),
   `Emaill` CHAR(255),
   `Emailk` CHAR(255)
);

(Yes, I know this is a poor example, but it demonstrates the point. No developer should ever name their fields this way, although I seem to see it happen all the time).

 

 

In this scenario, we have several fields that are easily confused. The first is Email1 and Emaill, which happen to look similar, and multiple developers working on the same code might interchangably use the two fields. If only one of them should have been used, the SQL statement should not use all fields but instead explicitly name the fields, in which case their development language would inform them that one of the fields was not used in the query.

 

The other scenario, of course, is Email1 and Email2, and Emaill, and Emailk. In both of these cases, they have a key that is only one keyboard key away, and a developer might inadvertently type the wrong one in, and not notice it (and the former is a very common database technique). In this case, using all fields would allow a typo through, causing some sort of odd logic bug that would take ages to sort out. Not using all fields would instantly identify the very line of source code where the problem lies.

 

The developers at Force.com are database gurus, and they have much more vast experience than someone like me, who's only really been using databases the last 6 or so years (since I started using Salesforce, although I also use other platforms for database management, such as MySQL or MS-SQL, depending on circumstances). They know many of the pitfalls that developers commonly fall into, and so they've worked out a system that helps eliminate those types of mistakes. It's the same reason why "code coverage" is required for production-quality code. It's not because they hate us or want us to suffer, it's that they want to help developers avoid common pitfalls, thus improving system performance for everyone.

KruviKruvi

True;

 

I guess investing time in coding saves time in debugging :-)

 

 

Cory CowgillCory Cowgill

I wrote a blogpost about this a few months back with code posted to use Dynamic Apex & Dynamic SOQL to perform Select ALL type functionality. You can read it here, it may prove helpful:

 

http://corycowgill.blogspot.com/2011/01/building-dynamic-soql-select-all-query.html

 

BTW, I totally agree with earlier posts from SFDCFox and others, that you should try to limit your selected fields to a subset if possible, but there are occasions where you can't do that for some reasons.