Best Practices for Handling A Large Matrix of fields

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I've got a 10 x 7 matrix of fields (70 fields) that I'm managing. The
matrix is used to hold a set of related inputs. I need to store (and manage)
that number of fields because they correspond to inputs for a financial
model.

I'm just wondering, how have others attacked this issue in the past?

Would it be better to use the spreadsheet control included with the Office
Web Components? Or, am I doing what needs to be done using the text box
control?

Just curious,
Orlanzo
 
Is there no way to manage the data as rows in a table? That's what Access
excels at (no pun intended)
 
Hi Doug,

Thank you for responding. The inputs will eventually reside in a table as
they must be retained for historical purposes. I'm most interested in seeing
how others have managed such a large group of controls as they'll share the
same code for events, need default values, etc.

I guess, I'll just need to adopt a naming convention allowing me to loop
through them using the form's Control's collection.

What are you inferring by managing through tables?

Thanks again,
Orlanzo
 
It sounds like a task for a spreadsheet - not a database.

Why don't you use Excel?

The need to "retain the results for historical purposes", does not
justify using a database product. You could just store the Excel
spreadsheet(s), no?

HTH,
TC (MVP Access)
http://tc2.atspace.com
 
Hi TC:

Collecting the inputs is a small component of the overall application. The
inputs will need to be stored and I'd rather store them in the database for
future use. I can query them for other information.

I'm not comfortable with the Excel Object model. I'm concerned t may take
too much time trying to understand it, integrating it into the larger
application, and doing so within the time constraints before me.

It does seem like Excel would be most useful in collecting the inputs. I
considred using the spreadsheet control from the Office Web Components to
assist. Again, the learning curve with Excel's object model is the blockage.
 
Sorry, that does not make sense to me.

You only need to understand the Excel object model, if you plan to
write code in Excel VBA. So this suggests, that you do plan to write
some code in VBA.

If you store the data in Access, and you similarly plan to write some
code in VBA, you'll need to understand the *Access* object model -
which is quite as complicated as the Excel one.

If you do *not* need to understand the Access object model, then, I
can't see that you need to understand the Excel object model either.

So I still can not see any logical justification for storing the data
in Access, instead of Excel. Particularly since you mention using the
spreadsheet control from the OWC! That seems to be a tacit admission
that you need a spreadsheet - not a database - to manage the data how
you want.

HTH,
TC (MVP Access)
http://tc2.atspace.com
 
Back
Top