Return to Answer

You just need to know the number of accounts the query returns? Why not use getNearbyTech.size()? No need to use an aggregate expression.

edited to add getNearbyTech is declared as a list, so getNearbyTech.size() will get you the number of elements in the list. The ".size()" method call takes no parameters. You can read more about list methods here

To reference the size in a visualforce page, you'd need to declare getter/setter methods in your controller class:

public Integer NumAccts {get; set;}

and set the value at some point (usually in the constructor)

 NumAccts = getNearbyTech.Size();

Then you can reference the count in a Visualforce page like this:

{!NumAccts}

The only think I'm unclear about is whether the "@remoteaction" affects whether the size will be available when the constructor runs. If not, there may be an extra hoop to jump through to refresh the page when the query actually complete. Perhaps someone else here will let us know.

second edit The problem here is @remoteaction. This answer explains why. Short version - @remoteaction calls can't update the Visualforce page view state.

I think Keith C is on the right track in his comment. You might need to run a separate query that does not use the child relationship and use a for loop to examine and count the relevant records yourself. This could be done in the constructor and the result stored in NumAccts for use in Visualforce as shown above.

You just need to know the number of accounts the query returns? Why not use getNearbyTech.size()? No need to use an aggregate expression.

edited to add getNearbyTech is declared as a list, so getNearbyTech.size() will get you the number of elements in the list. The ".size()" method call takes no parameters. You can read more about list methods here

To reference the size in a visualforce page, you'd need to declare getter/setter methods in your controller class:

public Integer NumAccts {get; set;}

and set the value at some point (usually in the constructor)

 NumAccts = getNearbyTech.Size();

Then you can reference the count in a Visualforce page like this:

{!NumAccts}

The only think I'm unclear about is whether the "@remoteaction" affects whether the size will be available when the constructor runs. If not, there may be an extra hoop to jump through to refresh the page when the query actually complete. Perhaps someone else here will let us know.

second edit The problem here is @remoteaction. This answer explains why. Short version - @remoteaction calls can't update the Visualforce page view state.

I think Keith C is on the right track in his comment. You might need to run a separate query that does not use the child relationship and use a for loop to examine and count the relevant records yourself. This could be done in the constructor and the result stored in NumAccts for use in Visualforce as shown above.

You just need to know the number of accounts the query returns? Why not use getNearbyTech.size()? No need to use an aggregate expression.

edited to add getNearbyTech is declared as a list, so getNearbyTech.size() will get you the number of elements in the list. The ".size()" method call takes no parameters. You can read more about list methods here

To reference the size in a visualforce page, you'd need to declare getter/setter methods in your controller class:

public Integer NumAccts {get; set;}

and set the value at some point (usually in the constructor)

 NumAccts = getNearbyTech.Size();

Then you can reference the count in a Visualforce page like this:

{!NumAccts}

The only think I'm unclear about is whether the "@future" affects whether the size will be available when the constructor runs. If not, there may be an extra hoop to jump through to refresh the page when the query actually complete. Perhaps someone else here will let us know.

You just need to know the number of accounts the query returns? Why not use getNearbyTech.size()? No need to use an aggregate expression.

edited to add getNearbyTech is declared as a list, so getNearbyTech.size() will get you the number of elements in the list. The ".size()" method call takes no parameters. You can read more about list methods here

To reference the size in a visualforce page, you'd need to declare getter/setter methods in your controller class:

public Integer NumAccts {get; set;}

and set the value at some point (usually in the constructor)

 NumAccts = getNearbyTech.Size();

Then you can reference the count in a Visualforce page like this:

{!NumAccts}

The only think I'm unclear about is whether the "@remoteaction" affects whether the size will be available when the constructor runs. If not, there may be an extra hoop to jump through to refresh the page when the query actually complete. Perhaps someone else here will let us know.

second edit The problem here is @remoteaction. This answer explains why. Short version - @remoteaction calls can't update the Visualforce page view state.

I think Keith C is on the right track in his comment. You might need to run a separate query that does not use the child relationship and use a for loop to examine and count the relevant records yourself. This could be done in the constructor and the result stored in NumAccts for use in Visualforce as shown above.

You just need to know the number of accounts the query returns? Why not use getNearbyTech.size()? No need to use an aggregate expression.

You just need to know the number of accounts the query returns? Why not use getNearbyTech.size()? No need to use an aggregate expression.

edited to add getNearbyTech is declared as a list, so getNearbyTech.size() will get you the number of elements in the list. The ".size()" method call takes no parameters. You can read more about list methods here

To reference the size in a visualforce page, you'd need to declare getter/setter methods in your controller class:

public Integer NumAccts {get; set;}

and set the value at some point (usually in the constructor)

 NumAccts = getNearbyTech.Size();

Then you can reference the count in a Visualforce page like this:

{!NumAccts}

The only think I'm unclear about is whether the "@future" affects whether the size will be available when the constructor runs. If not, there may be an extra hoop to jump through to refresh the page when the query actually complete. Perhaps someone else here will let us know.