public class API_DocumentRqAndRs {
        public API_Document__c apiDoc{get; set;}
        public List<Rq_Argument_Description__c> rqArgList{get; set;}
        public List<Rs_Argument_Description__c> rsArgList{get; set;}
    }

    public List<API_DocumentRqAndRs> getApiDocumentListRqAndRs(){
        List<API_DocumentRqAndRs> apiDocRqRsList = new List<API_DocumentRqAndRs>() ;
        // Build master list using this list
        List<API_Document__c> apiList = getApiDocumentList();  
        
        API_DocumentRqAndRs apiDocRqRs;
        for(API_Document__c apiDoc : apiList) {
            apiDocRqRs = new API_DocumentReqAndResp();
            apiDocRqRs.apiDoc = apiDoc;
            // Sets the key to query on
	    fApiController.setapiDocId(apiDoc.id);             
            // This returns a query
    	    apiDocRqRs.rqArgList  = fApiController.getRqArg(); 
            // This returns a query
            apiDocRqRs.rsArgList  = fApiController.getRsArg(); 
            apiDocRqRsList.add(apiDocReqResp);
        }
        
        return apiDocRqRsList;
    }

I query for a list from the documents then using that list I create another list of documents with child records.  Right now I cannot hink of another way to do this since I need all the child records for each document.  For every document I have to have the related child records.  Then I display all this to the user.

The records will have to be queried eventually to match the parent.  Why would I need a DB if I was going to read all the child records into a flat file and match the records on my own?  Why do I need a DB when I cannot make queries??

Help please!

rtyanas,

The limits are in place so that all code has an equal chance to run without overloading hardware capacity. You say that a system that uses more queries is somehow better and conforms to higher standards than one that uses fewer queries. In fact, the opposite is true. I shall prove this with a simple piece of code:

for(Lead record:[SELECT Id,FistName,LastName FROM Lead WHERE Id IN :Trigger.new]) {
  Task[] tasks = [SELECT Id,Subject FROM Task WHERE WhoId = :record.Id];
  for(Task leadTask:tasks) {
    if(leadTask.Subject=='Test') {
      delete leadTask;
    }
  }
}

This code uses at minimum two queries, and one query for each additional lead beyond the first in the trigger. It also performs slow DML by operating only on one record at a time, and it also queries records that will not eventually be modified, increasing the number of rows returned unnecessarily. This code could also easily run upwards of hundreds of thousands of script statements on leads with many tasks.

 Here is how an expert would write this:

delete [SELECT Id FROM Task WHERE Subject='Test' AND WhoId IN :Trigger.new];

This code uses only 1 query, regardless of the number of leads or tasks, and performs exactly 1 DML statement, regardless of the number of tasks to be deleted (the system will automatically break them into chunks of 200 records per delete). It requires just 1 script line of execution, and no heap memory. It queries only records that meet the specific criteria without any extra waste.

By your logic, you are saying that the first version of the code I wrote here as an example is somehow more efficient, more elegant, and of higher standards and quality than the latter. This is clearly not the case, as the former example is slow, bloated, does not scale well, and will consume many resources. You may feel that your code is very well written, and "done," but it is not efficient enough to use on this platform. Your code must share resources with other applications, and it is your responsibility to make sure that your application follows these rules.

Fewer queries leads to higher code quality and faster execution time. Until you understand this, you will never appreciate what it means to be a salesforce.com developer (or any other type of developer). No competent developer will state that they cannot work within the limits of the system and need more resources. They will instead find inventive solutions that work within the parameters of the system. This is the difference between a developer that wants lots of money and a developer that wants to write great code (which in turn will actually yield lots of money).

Nobody will want to use your "elegant" system which takes 10+ seconds between each page, which is what will happen if you're continually bumping up against the 100 query limit.