Hi Julius,

Well, let me begin by saying that you have a really cool design going there. Congrats for that!

Regarding your query, there seem to be many things there that could be preventing it from working properly.

One suggestion I would make would be for your Advanced Query in the Listing_List > Preparation action to be:

SELECT {LISTING}.*
FROM {LISTING}
WHERE (({LISTING}.[LP] > @MIN_PRICE) or @MIN_PRICE = 0)
AND (({LISTING}.[LP] < @MAX_PRICE) or @MAX_PRICE = 0)
AND (({LISTING}.[BR] > @MIN_BEDS) or @MIN_BEDS = 0)
AND (({LISTING}.[BTH] > @MIN_BATHS) or @MIN_BATHS = 0)
AND ((CharIndex(@TPC, {LISTING}.[TPC]) -1) = 0) 
AND (((CharIndex(@AREA, {LISTING}.[AR]) -1) = 0) OR (@AREA = '0'))

The issue is that you probably weren't accounting for the "No Maximum" and "No minimum" options in the search filter, and having a condition where

LP < 0 and LP > 0

just wouldn't work well. :)

Secondly, the filter definition is not propertly done, it seems. You have defined - and well - a structure for the filter. However, you are not using it in runtime - I assume it must have been one of your experiments :)

Still, either way, if you are using that LISTING_FILTER structure, I would assume that the MIN_BED, MIN_BATH, MIN_PRICE and MAX_PRICE to be all integers (well, maybe you could also use currency for the prices, if you'd like).

However, you are now using separate session variables - MAX_PRICE, MIN_PRICE, etc, but their data type is always LISTING Identifier. I think that's just wrong.

If you are going to use these separate variables, their data types must be consistent, but NOT Listing Identifiers. They must be integers, if I read your eSpace correctly.

I hope this helps, and please let us know how it goes!

Regards,

Paulo Tavares

Hi Paulo,

Thanks for your help I've instituted your changes. I'm using session variables for the purposes of the sidebar search query. The last piece is finding a way to get end user selections from the list box at the bottom of the sidebar search into the "AREA"  variable so that the query will yield results from multiple neighborhoods should the user decide to select multiple areas. Please let me know if there is a way to accomplish this.

Julius

Hi Julius,

Great stuff, And is everything working now asides from that Area issue?

I'd probably like to hear what others have to say about this particular question, since they will have other - ond probably much better - ideas on how to approach this problem. You have a multi-select input, if I understand correctly, and want to do a query based on its values, is that it?

My first suggestion would be to create a structure, with each attribute representing an option of the multi-select input.

For example, if the options would be:

New York
Los Angeles
San Francisco
Boston

I would create a structure "Area_Filter" with 4 boolean attributes,

NewYork
LosAngeles
SanFrancisco
Boston

and I would set each one of them to true or false, depending on whether they were selected or not.

After that, I would pass that structure to the query, and use those attributes in a condition somehow.

A second alternative, probably a best one, would be to create those areas as a Static Entity, named Area, for instance.

Then you could create an "Area_Filter" session variable that is a Record List of the Area data type, and would only contain the IDs of the selected Areas in the filter.

Then, for the query, you could generate the condition as text, for instance

and (AreaId = 1 or AreaId = 2 or AreaId = 3)

and pass it to the Advanced Query with Expand Inline set to true.

I hope these are not overly complex alternatives, and that they will get you going.

Does anyone else have other alternatives they've used in the past?

Regards,

Paulo Tavares