The problem with a database design like this is that if next week, you need 103 values, you need to change your database, AND your program.
separating these values into a child table will solve this.
Not knowing what you are actually trying to model, I have to fall back on giving you a generic example
A Table may look like:
ParentTable
--------------
ParentTableID (primary key)
ParentTableColumn1
ParentTableColumn2
A Child Table where ParentTable is referenced:
ChildTable
---------------
ParentTableID (primary Key, foreign key - references ParentTable)
ChildTableID (primary Key)
ChildTableColumn1
or
ChildTable
---------------
ChildTableID (primary Key)
ParentTableID (foreign key - references ParentTable)
ChildTableColumn1
Difference between the two child tables are that the ParentTableID is or is not part of the primary key of the child table. In your case, I would surmise you would need ParentTableID to be part of the primary ID..
So your Parent Table would hold basic information about what each value (your spinedit values) refers to, and in your case, your 100 spin edit values would be in the child table. Only one column in the child table is needed, not 100..
To get the spinedit values, a query may look like:
Select ChildTableColumn1
From ChildTable, ParentTable
Where ParentTable.ParentTableID = ChildTable.ParentTableID and
ParentTableID =

aramValue
Set the Parameter for the query to the instance you are interested in.