on 6/12/03 2:34 PM, Bryan Love at [EMAIL PROTECTED] wrote: > I've run into this one before and it sucks. Your best bet, if you want the > number of unique property ids is to run another query that does a > SELECT COUNT DISTINCT propertyID AS pCount... > > But whether or not it will work to use this number as the recordcount is > anyone's guess. You may have to keep track manually. >
You're kidding me... I had thought about "jury-rigging" it by doing exactly that. But thought I'd be ashamed of doing something like that... Am I correct in assuming that the recordcount of the join is actually correct? It's a fact that I can verify whenever I group them properly (by grouping them on propertyID) and it always comes out correct. This leads me to believe that the query is actually *THE* correct way to retrieve this information in this particular manner...it's just going to be a pain to do a "next n records" browse type of function? Is this correct? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
