>Bret,
>
>There is no work around for VFP 3, a numeric key in a combo or list causes the list or combo to return the index of the itme rather than its value. VFP 5 fixes this, but in VFPO 3 there is no way to fix other than writing code to change the keys to character in the combo and use the VAL() of the key to update the table.

It occurs to me that the reason it seemed to work before was because the other combo.rowsource was a new, sorted table, so the key values probably matched the listitem numbers.

The goal is to select items in table3 to associate with the current record in table1, and put a new record in table2 with the parentkeys for each. My first attempt to convert the keys to character in the SQL was to cheat: SELECT field1, field2, ALLTRIM(STR(keyfield)) AS keyfieldstr FROM table3 ... which the manual hints is not acceptable, since STR and ALLTRIM are not among the accepted functions, like COUNT() or whatever. Is such a statement acceptable to the RDBMS police? If I use this SQL to make a cursor and BROWSE, it seems to work. Mycursor.Keyfieldstr has type C and correct values, and no error messages. But when I put this statement in the combo.Rowsource, I still get a numeric combo.value. Should I leave the combo.Rowsource blank and make the cursor in the combo.Init? In the combo.Init, I could say

SELECT field1, field2, keyfield,"" AS keyfieldstr;
INTO CURSOR mycursor ORDER BY keyfield
REPLACE ALL keyfieldstr WITH ALLTRIM(STR(keyfield)) IN mycursor
* a bunch of code to make mycursor read-write
SELECT 0
lnSelArea=SELECT()
USE DBF("mycursor") in (lnSelArea) AGAIN ALIAS NewAlias
SELECT mycursor
USE
SELECT 0
lnSelArea=SELECT()
USE DBF("NewAlias") IN (lnSelArea) AGAIN ALIAS mycursor
SELECT NewAlias
USE
SELECT mycursor
*(whew)
THIS.RowSourceType = 3
THIS.RowSource = mycursor

I guess I should USE IN mycursor in the combo.Destroy.

Or is there a better way?