Hi Spectre, and welcome to the forum....
I'd agree whole heartedly with Rudy, that its easier to debug a SQL statement by seeing the whole statement rather than a fragment. So I'd suggest you reproduce the SQL here.
You mention it doesn't return all rows you expect. How do you know this is the case?, what are you expeccting as opposed to what did you get. Can you identify which terms in your SQL are not returnign the correct number of rows. Offhand I'd expect the problem is going to be your age / date of birth clause, and the reason is down to how you are phrasing your criteria and how you convert that specification into soemthing that can be matched against a date of birth.
Can I make few style comments
you seem to be including uneccesary ifs in your code
for example
Code:
if ($_POST['sex'] != 'all')
{ $unique = ' WHERE sex = "'.$_POST['sex'].'"';
} elseif($_POST['sex'] == 'all')
{ $unique = ' where (sex = "male" OR sex = "female")';
}
could be expressed as
Code:
if ($_POST['sex'] != 'all')
{ $unique = ' WHERE sex = "'.$_POST['sex'].'"';
} else
{ $unique = ' where (sex = "male" OR sex = "female")';
}
however in reality if a users hasn't made a selection on that criteria why include it in the first place
Code:
if ($_POST['sex'] != 'all')
{ $unique = ' WHERE sex = "'.$_POST['sex'].'"';
}
The reason behind the removal is that it makes your SQL simplier for both the SQL engine and mere mortals to read. It makes it easier for others to help. There is another knock on advantage in that you are using numeric values for such lookups and that means removing the potetnailly confusing depech marks which seem to cause so much confusion.
I think you may be creating problems for yourself in the future, if not now by using text for your categories, not only are you hardcoding your categories, so a change in category requires a change to the application, rather than just the data. There is also a potential risk that your applicaiton may fail due to mispellings. Generally its better to store such attributes indirectly as a number, referencing another table. Rudy's (R937) site has a
useful tome on the basics of database design
HTH