>Why would you have a field name for each drug (or whatever)? Sounds like there is a database design issue here. I'd create a table that has a fieldname of "substance" and put the name of the substance into the field and use relationships with the master table. The way you're doing it, the table is going to grow in size each time you have to add a new drug to the application. In fact, it must be quite large now. This also means that you are likely taking a huge performace hit.
>
>Dana

Besides, if application is on drugs...

Kidding aside, each time it seems convenient to have a column for each item, I slap myself and create a table of items. I've once dealt with bakery dispatch program which had each sort of bread in four columns each (one column per shift)... the table was enormous, though it had only a couple of hundreds of records (one per delivery address), and I was invited to patch it when they invented a new kind of bread. I wrote a new app which actually used a table with customer+breadtype+shift as a key. It needed, roughly, 10% of space. When I packed the original table to see how it worked, it zipped to 2-3%. The average ratio for a normal .dbf is 10-13%. This taught me to check this percentage more often on my tables, and each time it falls below 9%, I just get an idea that there's a design flaw - a table holds too little information.