Dmitry,

I don't know if it's the *best* way to do it or not, but I created one lookup table in SQL that handles all of my lookup needs. It's structure includes primary key, group type, display text, display order, include flag, return type, character return value, integer return value. Then, I simply created a few stored procedures to work with this table. The primary one simply takes a group type and an include flag as parameters and will return the display text, return type, and both return value fields in the order specified by display order. This way, I can return a list suitable for display in a combobox. I also created a custom combobox that has a custom property to specify the group type and it pulls the data (via the stored procedure) automatically. So, anytime I need to let the user select a lookup value, I simply drop this combobox on the form and set the one custom property and the ControlSource and I'm done. It works great for me.

HTH,
Chad

>I am looking for advice, input on the following.
>
>In the Clipper application I am converting to VFP/SQL Server, I have tons of lookups of two-field structure: Value (C,10) and ValueDescr C(40). In the Clipper app they are all physically stored in one .DBF file. In SQL Server I am creating a separate table for each lookup, CompReference1, CompReference2,...CompCategory, and so on.
>
>Do you think it is ok if all of those lookup tables are of exactly the same structure, as:
>VALUE C(10)
>VALUEDESCR C(40).
>
>Basically right now I am doing a basic convertion but I am concerned that when I start using more advanced features of SQL Server, this type of the "same" structure might be a downside.
>
>Please let me know what you think.
>
>Thank you