function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Eager-2-LearnEager-2-Learn 

Building a SELECT statement without hard coding field names?

Hi,

 

Is there a way to to iterate through an objects field list so I can dynamically build a SELECT statement?  I don't want to hard code field names because that requires maintenance to the code down the road should a new field be added or worse a field name change.

 

 

Best Answer chosen by Admin (Salesforce Developers) 
bob_buzzardbob_buzzard

There is indeed a way to do this. There's various posts in the blogosphere detailing the process.  Here's one (not mine btw):

 

http://www.mkpartners.com/blog/apex-code/apex-describe-with-dynamic-soql

All Answers

bob_buzzardbob_buzzard

There is indeed a way to do this. There's various posts in the blogosphere detailing the process.  Here's one (not mine btw):

 

http://www.mkpartners.com/blog/apex-code/apex-describe-with-dynamic-soql

This was selected as the best answer
sfdcfoxsfdcfox

That's a common question, and the post above should answer it. However, I'd like to add my usual preaching about this:

 

Please note that this is considered a bad practice to dynamically generate field names. It is the very same reason why "*" (the all fields selector) is not a legal field selector in SOQL. Sometimes you need this functionality for a dynamic use case (a page that can display an field on an object, for example), but if you're building an application that has a specific function, list only the fields you need. This is so that the code is self-documenting in the absence of any other comments, and so that if something does change, your code can actually tell you that it needs to be updated much quicker than trying to do a Find/Replace, which is hardly ever "exactly" what you intend to do.
bob_buzzardbob_buzzard

At the risk of hijacking this thread, while that is a genuine drawback for a narrow use case, if you have a more complex application (for example, one that utilizes a DAO layer), dynamically generating the field names ensures that the required fields are available in all scenarios without the added burden that each calling method supply a list of field names.

 

Horses for courses really; in SFDC one size rarely fits all.
Eager-2-LearnEager-2-Learn

Thank all of you for the feedback.  I will concider it all.
sfdcfoxsfdcfox

Actually, Bob, it's really your thread, not mine. I was just pointing that little tidbit out. This is something you learn in college courses regarding DBA, which is part of my IT major. I'm not saying that dynamically generating fields is always bad. I'm just saying that caution has to be exercised, and it is rarely appropriate to query all fields on a record at one time; you should still design dynamic queries to load only the fields necessary. Consider an object where you need to query 1,000 rows and place them all in memory. There are five long text areas, each filled with an average of 16,000 characters each. By my calculations, that's 80 MB of heap space with a governor limit of 3 MB. Take it as you will, but even SFDC internally is designed around this concept (i.e. a field not referenced on a VF page isn't available in an extension without querying). It's often a mistake to design a solution that always queries all fields when there is a solution to limit the fields queried for the sake of memory, performance, etc.
Eager-2-LearnEager-2-Learn

I hear the both of you and with that I can get the best of both worlds by simply adding some IF logic to exclude the specific fields that I do not want on day one.  This way I include only what is necessary day one but as fields are added they will be included due to the dynamic logic.  If performance becomes an issue only then I will worry about update code. 

 

Feedback on my thinking is appreciated.  I think it simply depends on what side of the fence you want to be on at what point in time.  Because sooner or later code changes are going to be necessary if you are adding fields to an object/table.
richardvanhook123richardvanhook123

See DatabaseUtils.query() in apex-lang.  Here's linke http://code.google.com/p/apex-lang/source/browse/trunk/eclipse-project/src/classes/DatabaseUtils.cls?spec=svn116&r=116
Eager-2-LearnEager-2-Learn

Thanks for the link.  That is a lot of code with no comments to assist in what it is doing!  I am still catching on to this language and Java.
richardvanhook123richardvanhook123

Working on better documentation for apex-lang.  See my blog for some docs: http://richardvanhook.com/2011/04/14/apex-lang-1-17-released/
Eager-2-LearnEager-2-Learn

Unbelievable work!  Thank you very much.