>>>I'm designing a survey which will have a lot of drop down lists for foks to pick their choices, thus avoiding entry mistakes and making entry quicker for them. >>> >>>I had originally created a million (ok about 25) "code" tables, one for each code type, such as "computer type", "vendor" or "language". I realized it would be more efficient to combine all of these into a "allcodes" table which has 3 fields, the codetype (i.e. what category of lookup code is it?), the actual code I'd previously assigned (00123, 00124, 00125 etc.) and a description field containing the name to be displayed on the drop down boxes. I figure I can then use a combination of codetype and code for my key fields in my data tables. >>> >>>I'm not entirely sure how I want to do this and can't believe I'm inventing anything new. Do any of you have any samples/ideas to share or point me towards info on this approach... and if you think it's the right one ;^)! >> >>Sounds like your pretty well on target. The main thing I try to do is have a code & and description in a table. The code being the Link field that I can link to any other table as the project grows. As long as the link fields are unique you should be ok. The codes are a good idea because descriptions "can be" harder to work with when manipulating data. They can be used just to show the "Human" what the heck the code represents. >> >>Sounds like you on the right track. Now you can have as many code tables as you like and be able to link them to each other with no problem. The thing you want to eliminate is data redundancy. Not only does it require more work but slows a system down and requires more resources. >> >>HTH, >>Tom > >Mandy, in addition to Tom's suggestions, you might consider making arrays from the data in the large lookup table. This is particularly useful if the users aren't adding data to the lookups. I have a similar project where all the lookup information is stored in 12 arrays which are then stored in application properties at the time the EXE loads (Public variables can also be used). These arrays are only updated/changed if someone goes in to the Lookup-editing screen. > >All my combos call the arrays, which are two-column arrays, code and code description, alphabetized by code description. Barbara & Mandy For Lookups I use Cursors. One big reason is cursors are shared between memory & Disk, at VFP's discretion. Arrays are kept in main Memory. if your Lookups are of any size and you have a few of them, you will be burning up main memory. With Cursors if the Data is of any size the Cursors will be created on disk thus freeing memory for your app & operating system. HTH, Tom