OLEObject Instead of Memo Field

[Saccess]

Hello Newsgroup,

I have (previously) constructed a backend (application file) using Access 2003, I
am now upgrading (due to substantial application upgrades) the backend
(application file) to Access 2007. Generally, the application file stores imported
matrices of integers, and doubles which the user is able to perform calculations
on, and graph. The imported matrices were never more than 248 column in size, so
placing a matrix of numbers in one table was never an issue. Briefly, the data the
application deals with is market research data.

The numeric matrices can now be arbitrary in length, that is I have one matrix
that has 1,376 columns, of type long (integer in the programming language).
Despite the row count, I am able to store the matrices in Memo fields as coma, new
line delimiter strings. This works just fine, even performance wise. Extracting a
matrix from a, record x field, I break up the delimiters, cast from String to
either Int32, or Double accordingly, and perform requested calculations, and
graphing. Nothing broken, performance is good, but, something has me thinking...

Rather than store the data matrices in memo fields (hence requiring some kind of
delimiter), why not look into storing the data matrices into OLE Object fields.
This may relieve the need for delimiters. Despite being confident I can achieve
this, what I do not know is, in this situation would there be any advantages in
doing so? What would the disadvantages be? Is it worth doing?, and Is actually
this possible? Best stick with Memo fields?

I don't really want to implement a matrix spanning over many tables of one-to-one
join, unless you claim this is the best way.

e.g;

Table: ResponseMatrix
===========================================
ID | MatrixName | DataType | Data (Currently Memo)
===========================================
1 | Brand | 0 | 1, 43,1,23,45,56,66,.....21
| | | 2, 5,23,456,65,45,.....3
| | | n, .......................
----------------------------------------------------------------
34 | Segments | 0 | another matrix like the above....
----------------------------------------------------------------
56 | Motivation | 1 | another matrix like the above....
----------------------------------------------------------------
77 | .... | ... | another matrix like the
above....
===========================================

C#: OleDb data access layer
C#: Application rules layer
C#: Interface

Would like;
===========================================
ID | MatrixName | DataType | Data (OLEObject)
===========================================
1 | Brand | 0 | 1 43 1 23 45 56 66 ..... 21
| | | 2 5 23 456 65 45 .....3
| | | n .......................
----------------------------------------------------------------

I know I would not see the data in this type of field until extracted.

Thanks and regards,
- Saccess

 

[Saccess]

Hello Newsgroup,

This issue (pondering in my head) has been solved, googling 'Access 2007 OLE
Object vs Memo field', and similar phrases, yields a few good pages that state at
the database level, memo fields are more reliable, particularly when storing
numeric arrays of data. I was trying to bypass having a delimiter (in my field
data), and casting in my code, but that apparently is a good trade off to the
'trouble' OLEObject fields can apparently cause. Never experienced trouble with
OLEObject fields, I've only used for storing graphs, but there have been a few
people made very sore because of them, as I read.

Sorry for the long post, no need to respond.

Thanks and regards,
- Saccess