I'd do as Mike just put the result INTO CURSOR and display that. If you index the gender column of the input data the query will be fast and you won't need to maintain an extra table for counts, that's redundancy and redundant data is doomed to be wrong at some time. You might say you can update the count with each insert or update, but then you'd forget that at one place or not do it, when browsing input and changing something on the fly. The schema of the original table also has one flaw, you can easily have spelling erros or upper lower case differences. Is it political correct to not just have a boolean field for genders, today? Maybe, but I'd say for most cases you don't need to know the details... So my design for such a table might be cName, iGender with an int in range 0 to 2 for 0=unknown, 1=female, 2=male. Bound to an optiongroup with the two options female and male the 0 will be no option selected.
To get a name with the group by query you can again bind the result to such an optiongroup or use ICase():
SELECT ICase(iGender=1,"Female",iGender=2,"Male ","Unknown") as Gendername, Count() as Howmany From inputdata Group By 1
You may or may not add a field rule only allowing int values 0,1, and 2.
Code:
*Sample data
Create Cursor inputdata (iID I AutoInc, cName C(50), iGender I Check iGender>=0 AND iGender<=2 ERROR "Wrong Gender" Default 0)
Insert into inputdata (cName,iGender) Values ("Mary",1)
Insert into inputdata (cName,iGender) Values ("Bob",2)
Insert into inputdata (cName,iGender) Values ("Intern",0)
SELECT ;
Cast(ICase(iGender=1,"Female",iGender=2,"Male","Unknown") as Char(7)) as cGendername ;
, Count(*) as iHowmany ;
FROM inputdata ;
GROUP BY iGender ;
INTO CURSOR crsResult
It's part of the field definition (ideally put into the field comment), what 0, 1, and 2 mean. It's "clear" from the UI, if you always bind it to such an optiongroup, but it's not clear from the data alone, so it's better documented.
Group By iGender can be optimized better than Group By 1, but needs the value range restriction, otherwise several result records will have cGendername "Unknown" and still have a record each due to different iGender values, that's restricted with the CHECK (the table designer has this as field rule). A cursor can't have a field comment/description, so I skipped that part, but a table can have comments for the whole table and fields.
So even this little thing leaves you with some decisions and exercises. If you think it through to the end, you'll not need to come back later.
Bye, Olaf.