My problem is a bit more complicated than that. Here's the situation:

I have a table, repair_checklist. This contains one row for each item on the checklist. Following the item are 6 logical fields to tell which type of repair each item in the checklist applies to. The effect of this is that each kind of repair has a different subset of the checklist that applies to it.

I also have a table, repairs. For every repair, I need to keep track of whether each item in the checklist for that type of repair has been completed.

The only way I could think of doing this besides what I did is to have a logical field in the repairs table for each item in the checklist. The trouble with that is that the checklist is made up by the user, so I'd have to change the fields tacked on to the end of the repairs table each time the checklist changes.

Since they're all logical fields, I simply compressed them into one 250 character string. A 250 limit on the checklist is acceptable for this app.

-Michelle



>Michelle,
>
>This is just to give you maybe a couple of new ideas, not trying to get you to change your whole app...
>
>There are knitting machines in the database I'm working on at the moment. The end user wants to be able to create various subsets of those machines for reports. I give them a selection grid with a checkbox and the MachineName the grid is based on a temp table that has one row for every machine and it sets the lSelected for the row based on the previously selected items stored in a separate table. It's really pretty workable and is all data driven. They can add new machines and create new subsets without any code changes. The client hasn't seen this yet I hope they think it's as cool as I do. *g*
>
>>If the checklist were set at design time, then yes, that would be better. But Converting records into fields is too much of a headache.