function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
emuelasemuelas 

Simple pagination class error

Iam trying to write an extension class for pagination as follows below.
However this is throwing a compilation error:


Error: Compile Error: Method does not exist or incorrect signature: Database.getQueryL​ocator(LIST<Product2>) at line 5 column 71.

Please help me as i  have justt modified this from a forum post and iam not sure how to do it

 

 

also,how do i incorporate this in my  vf page??

 

Please help!

public class samplePagination {
public ApexPages.StandardSetController samplePagination{
get {
if(samplePagination== null) {
samplePagination= new ApexPages.StandardSetController(Database.getQueryL​ocator([ select id,created_inv__c,supplier__r.id,pid__c,pinv__c,Product_Type_custom__c,purchase_price__c,name,select__c,description,family,productcode from product2 where id
in (select product2id from pricebookentry where pricebook2.name='Purchase') ]));
//set number of records you want to show on UI.
samplePagination.setPageSize(5);
}
return samplePagination;
}
set;
}
// indicates whether there are more records after the current page set..
public Boolean hasNext {
get {
return samplePagination.getHasNext();
}
set;
}

// indicates whether there are more records before the current page set..
public Boolean hasPrevious {
get {
return samplePagination.getHasPrevious();
}
set;
}


public ApexPages.StandardSetController samplePagination

{

get

{

if(samplePagination== null)

{

samplePagination= new ApexPages.StandardSetController(Database.getQueryL​ocator([select id,created_inv__c,supplier__r.id,pid__c,pinv__c,Product_Type_custom__c,purchase_price__c,name,select__c,description,family,productcode from product2 where id
in (select product2id from pricebookentry where pricebook2.name='Purchase') ]));

//set number of records you want to show on UI

samplePagination.setPageSize(5);

}

return samplePagination;

}

set;

}

HarmpieHarmpie

Remove the [] around the query. It has to be a string passed to the getQueryLocator(); e.g.

 

ApexPages.StandardSetController std = new ApexPages.StandardSetController(Database.getQueryLocator('select id,name,description,family,productcode from product2 where id in (select product2id from pricebookentry where pricebook2.name=\'Purchase\')'));

 

mtbclimbermtbclimber

 


Harmpie wrote:

Remove the [] around the query. It has to be a string passed to the getQueryLocator(); 


 

That's actually not correct. You can (and SHOULD) use the static binding in place of dynamic (string) whenever you can as it contributes to our integrity enforcement system, i.e. we won't let an admin delete one of the referenced custom fields which would break the code when we see the dependency.  The string approach is meant for situations where the query is actually generated dynamically. If you know what you want at compile time use static.

 

That said, I don't see anything wrong with your query. I tried it in my own org  (minus the custom fields) and it didn't work but when I retyped it from scratch and commented out what I pasted it worked. I've seen some cases of weird characters getting into code posted on the boards before, if that works for you then perhaps you copy pasted this from something? If so what was it, if it was one of our docs or our boards, wiki, etc I'd like to know so we can try to address it.

 

Thanks and hope this helps,

HarmpieHarmpie

Thanks for clearing that up mtb. I probably fell for the copy/paste problem then, as I tried the code and got the same error. Then I tried the string approach, which worked and jumped to conclusions :)

 

As for the static binding vs string based queries. Whenever I use string based queries, I would make sure to at least use the important fields for the code in a test class. This would also ensure meta-data protection. Same applies for external integrations that integrate with sfdc, use the important fields to that specific integration in a formula field, testclass whatever. This keeps you integrations alive :)

mtbclimbermtbclimber

Good points but if you know what fields you want at compile time why wouldn't you use static (non-strings)? If you mis-type a name you won't know until you run it?

HarmpieHarmpie

You're right, not something you would typically do often. Bu still can imagine there might be a soql query with some static fields and also some configurable fields. In most cases the static one's would still probably be standard fields (like Name), but can also imagine scenario's where the static query fields could be custom fields.