Question : uggestions for database structure for a program which allows user to add custom fields

I have written a system (C# 2.0 and MS SQL Server) which allows researchers to store data on various patients/subjects belonging to different research studies. There is a customisation section where they can add their own fields specific to each study and set them to be numeric, date, text, dropdown etc. There is no limit on the amount of custom studies and custom fields that can be added.

Basically I have a main table with about 100 fields that stores common data e.g. patient name, age, weight etc. and these extra custom fields are stored in a CustomPatientFieldData table. I don't know the best way to approach the CustomPatientFieldData table in terms of database storage. As far as I can see there are two ways -
(1) Set the CustomPatientFieldData table to have say 1000 fields, and when the user defines custom fields it merely defines custom labels and points to different columns within this. Easier to program for with data binding, performing searches, but limiting in terms of storage possible and wasting a lot of space - adding one custom field takes up a new row with 999 empty fields. And eventually it will hit a limit and I'll need to add more fields.
(2) The way I have approached it already - make the CustomPatientFieldData consist of PatientID, FieldID and FieldData - FieldID pointing to the type of field (containing field type, label, dropdown contents if appropriate) and FieldData containing the actual data. This saves a lot of space but the storage of this will look like a mess - PatientID's scattered all over the table, and each custom field taking up a new row in the database. Obviously for people wanting to look at this custom data at a later date for reporting purposes, it won't be very meaningful either.

This is going to be a database installed in a few separate customer sites and I want to get it right from the outset.
What are your opinions, and have I chosen the right approach to this? Or is there something completely different that I could be trying?

Answer : uggestions for database structure for a program which allows user to add custom fields

from these two options I would always choose option 2, because set limits do always have a bad taste and there will be the time where limits will be reached.
Of course somehow option 2 will always be looking a little unstructured if you select the data without a order by statement. with the right index set to order by conditions there will be no noticeable speed issue.
The guys that build reports do always complain *giggles*. My experience with reportings is that data structures do never fit 100% in all circumstances. There will always be a certain amount of head scratching how to gather the data the way you need them. OLAP cubes are a good toolset for forming the data the way you need them.
If I need to store a variable amount of data as extensions to a fixed set of information (as additional information if you want to call it like that) I use that form of storage, too.
Sometimes it results in a little more work in visualizing the data in a proper way afterwards, but its worth the flexibility.