By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,152 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

In large db's, should Memo fields go to their own table?

P: n/a
ARC
This is mainly a speed question.

In this example: I have a QuotesHdr table that has a few memo fields. If
these memo fields are used extensively by some users, and if their are a
large number of records in QuotesHdr, should I break out the memo fields
into a separate table? The thinking here is that, for Quotes selection
dropdowns that display all entries in QuotesHdr for selection, I would think
that the entire record comes down over the network, and those who use the
memo fields would be the ones to notice speed issues.

It will be a fair amount of work to break out the memo fields into one
separate, and I'd like to have some opinions on this. I would think breaking
them out would have the affect of the data not coming down over the network
unless a quote is selected.

Many Thanks,

Andy
Aug 22 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Memo fields are stored separately from the table in which you "see" them --
that is why, at times, they have been more "problematic" than other types of
field.

What, exactly, do you mean by "come down over the network"?

If you have a split front and back end, properly indexed, and select by
indexed fields (which, by definition, are not Memo type), then only the
index is retrieved over the network to select the desired record, so only
the Memo fields associated with the current record of interest will "come
down over the network".

If you are displaying an entire table's or query's worth of data in a
continuous view form for the user to select in a front-back end environment,
you need to reexamine your application's design.

Separating the memo fields into another table is likely not going to help as
much as you might think.

Larry Linson
Microsoft Access MVP

"ARC" <an**@andyc.comwrote in message
news:eS****************@nlpi068.nbdc.sbc.com...
This is mainly a speed question.

In this example: I have a QuotesHdr table that has a few memo fields. If
these memo fields are used extensively by some users, and if their are a
large number of records in QuotesHdr, should I break out the memo fields
into a separate table? The thinking here is that, for Quotes selection
dropdowns that display all entries in QuotesHdr for selection, I would
think that the entire record comes down over the network, and those who
use the memo fields would be the ones to notice speed issues.

It will be a fair amount of work to break out the memo fields into one
separate, and I'd like to have some opinions on this. I would think
breaking them out would have the affect of the data not coming down over
the network unless a quote is selected.

Many Thanks,

Andy

Aug 22 '07 #2

P: n/a
ARC
By coming down over the network, I meant sending the entire record of data,
including the memo fields, accross the network wire to the user's pc. So if
my lookup combo box does contain all quotes, and is sorted on the indexed
field, quote number, and contains quote description, date, and customer
name, then it sounds like the memo field would not be retrieved unless the
quote is actually selected.

Many thanks,

"Larry Linson" <bo*****@localhost.notwrote in message
news:ho%yi.15497$4K6.10684@trnddc02...
Memo fields are stored separately from the table in which you "see"
them -- that is why, at times, they have been more "problematic" than
other types of field.

What, exactly, do you mean by "come down over the network"?

If you have a split front and back end, properly indexed, and select by
indexed fields (which, by definition, are not Memo type), then only the
index is retrieved over the network to select the desired record, so only
the Memo fields associated with the current record of interest will "come
down over the network".

If you are displaying an entire table's or query's worth of data in a
continuous view form for the user to select in a front-back end
environment, you need to reexamine your application's design.

Separating the memo fields into another table is likely not going to help
as much as you might think.

Larry Linson
Microsoft Access MVP

"ARC" <an**@andyc.comwrote in message
news:eS****************@nlpi068.nbdc.sbc.com...
>This is mainly a speed question.

In this example: I have a QuotesHdr table that has a few memo fields. If
these memo fields are used extensively by some users, and if their are a
large number of records in QuotesHdr, should I break out the memo fields
into a separate table? The thinking here is that, for Quotes selection
dropdowns that display all entries in QuotesHdr for selection, I would
think that the entire record comes down over the network, and those who
use the memo fields would be the ones to notice speed issues.

It will be a fair amount of work to break out the memo fields into one
separate, and I'd like to have some opinions on this. I would think
breaking them out would have the affect of the data not coming down over
the network unless a quote is selected.

Many Thanks,

Andy


Aug 22 '07 #3

P: n/a
"ARC" <an**@andyc.comwrote in message
news:A1***************@newssvr21.news.prodigy.net. ..
By coming down over the network, I meant sending
the entire record of data, including the memo fields,
accross the network wire to the user's pc. So if my
lookup combo box does contain all quotes, and is
sorted on the indexed field, quote number, and contains
quote description, date, and customer name, then it
sounds like the memo field would not be retrieved
unless the quote is actually selected.
Because Access-Jet is a file-server database, all the data retrieval and
manipulation is done on the user's machine. The remote MDB is accessed just
as it would be on the local hard drive -- not everything is brought across
the network, but no (repeat NO) code is executed on the server where the
split DB resides. So the actual information displayed in the Combo Box won't
be extracted from the record until the record is retrieved. I believe that
will include the Memo fields, which then just won't be used.

The details of the workings of the Jet engine are not published by
Microsoft -- there was one book, a few years back, on the subject, by Dan
Haught of FMS, Inc.. It has been out of print for some time, and covers an
earlier version of Jet (but I believe most of the information still
applies). I recently tried to purchase a used copy, but it wasn't
delivered, I got a refund, and haven't pursued it beyond that.

If you can get the value for the indexed field without bringing the
additional information to the Combo, then using that in the Query that is
RecordSource for the Form would only bring the index itself across the
network, and then read just the Record of interest from the back end. If
that information is frequently updated, and the user needs the unindexed
fields, it may be that your idea of a separate table for Memos would,
indeed, improve performance. That is, make the base Record contain just the
information you need for the Combo, and link a one-to-one related table in
the Query you construct for the Form or Report's RecordSource.

Larry Linson
Microsoft Access MVP

Larry Linson
Microsoft Access MVP
Aug 22 '07 #4

P: n/a
ARC
Hope you find your book!

I guess the only real way to know for sure is to break out the old
stopwatch, and use a network of at least 2 pc's. Create a very large
quoteshdr table, with tons of notes in memo fields, then put the db on a 2nd
computer, and pull from the first (with both computers logged onto the db).
"Larry Linson" <bo*****@localhost.notwrote in message
news:LI0zi.12710$A57.12500@trnddc04...
"ARC" <an**@andyc.comwrote in message
news:A1***************@newssvr21.news.prodigy.net. ..
By coming down over the network, I meant sending
the entire record of data, including the memo fields,
accross the network wire to the user's pc. So if my
lookup combo box does contain all quotes, and is
sorted on the indexed field, quote number, and contains
quote description, date, and customer name, then it
sounds like the memo field would not be retrieved
unless the quote is actually selected.

Because Access-Jet is a file-server database, all the data retrieval and
manipulation is done on the user's machine. The remote MDB is accessed
just as it would be on the local hard drive -- not everything is brought
across the network, but no (repeat NO) code is executed on the server
where the split DB resides. So the actual information displayed in the
Combo Box won't be extracted from the record until the record is
retrieved. I believe that will include the Memo fields, which then just
won't be used.

The details of the workings of the Jet engine are not published by
Microsoft -- there was one book, a few years back, on the subject, by Dan
Haught of FMS, Inc.. It has been out of print for some time, and covers
an earlier version of Jet (but I believe most of the information still
applies). I recently tried to purchase a used copy, but it wasn't
delivered, I got a refund, and haven't pursued it beyond that.

If you can get the value for the indexed field without bringing the
additional information to the Combo, then using that in the Query that is
RecordSource for the Form would only bring the index itself across the
network, and then read just the Record of interest from the back end. If
that information is frequently updated, and the user needs the unindexed
fields, it may be that your idea of a separate table for Memos would,
indeed, improve performance. That is, make the base Record contain just
the information you need for the Combo, and link a one-to-one related
table in the Query you construct for the Form or Report's RecordSource.

Larry Linson
Microsoft Access MVP

Larry Linson
Microsoft Access MVP


Aug 22 '07 #5

P: n/a
ARC
Ooops, I should have said take time trials of a few thousdand records in a
QuotesHdr table with AND without data in the memo fields. 3 time trials of
each should do it.

"Larry Linson" <bo*****@localhost.notwrote in message
news:LI0zi.12710$A57.12500@trnddc04...
"ARC" <an**@andyc.comwrote in message
news:A1***************@newssvr21.news.prodigy.net. ..
By coming down over the network, I meant sending
the entire record of data, including the memo fields,
accross the network wire to the user's pc. So if my
lookup combo box does contain all quotes, and is
sorted on the indexed field, quote number, and contains
quote description, date, and customer name, then it
sounds like the memo field would not be retrieved
unless the quote is actually selected.

Because Access-Jet is a file-server database, all the data retrieval and
manipulation is done on the user's machine. The remote MDB is accessed
just as it would be on the local hard drive -- not everything is brought
across the network, but no (repeat NO) code is executed on the server
where the split DB resides. So the actual information displayed in the
Combo Box won't be extracted from the record until the record is
retrieved. I believe that will include the Memo fields, which then just
won't be used.

The details of the workings of the Jet engine are not published by
Microsoft -- there was one book, a few years back, on the subject, by Dan
Haught of FMS, Inc.. It has been out of print for some time, and covers
an earlier version of Jet (but I believe most of the information still
applies). I recently tried to purchase a used copy, but it wasn't
delivered, I got a refund, and haven't pursued it beyond that.

If you can get the value for the indexed field without bringing the
additional information to the Combo, then using that in the Query that is
RecordSource for the Form would only bring the index itself across the
network, and then read just the Record of interest from the back end. If
that information is frequently updated, and the user needs the unindexed
fields, it may be that your idea of a separate table for Memos would,
indeed, improve performance. That is, make the base Record contain just
the information you need for the Combo, and link a one-to-one related
table in the Query you construct for the Form or Report's RecordSource.

Larry Linson
Microsoft Access MVP

Larry Linson
Microsoft Access MVP


Aug 22 '07 #6

P: n/a
"ARC" <an**@andyc.comwrote in
news:eS****************@nlpi068.nbdc.sbc.com:
It will be a fair amount of work to break out the memo fields into
one separate, and I'd like to have some opinions on this. I would
think breaking them out would have the affect of the data not
coming down over the network unless a quote is selected.
I'm with Larry on seeing this as a non-issue -- it's not the way Jet
works.

However, I *do* recommend considering splitting memo fields out into
separate tables, either 1:1 or 1:N. There are two basic
justifications here, each being a separate kind of situation:

1. if a memo field is being used as a log where new data is appended
on a regular basis (often with a date stamp), it's a no-brainer,
particularly if multiple people could be trying to edit it at the
same time. In that case, each of those entires in the omnibus memo
field should be it's on record in a 1:N table.

2. for regular memo fields *not* used as a log, it's just safer to
store them in a different table. When the memo pointer gets
corrupted, you have problems with the whole record. But if you move
the memos to a separate table, if a memo pointer gets corrupted, all
that's lost is the memo data -- you don't have to do any recovery to
recreate the rest of the parent record.

I also seriously suggest that all memo editing be done in unbound
textboxes, populated in the OnCurrent event, and written back to the
form's recordsource in the unbound control's AfterUpdate event.

But that might not be necessary with the separate table, as in
there's less fragility, and no contention for locks on the main
record.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 23 '07 #7

P: n/a
"Larry Linson" <bo*****@localhost.notwrote in
news:LI0zi.12710$A57.12500@trnddc04:
the actual information displayed in the Combo Box won't
be extracted from the record until the record is retrieved. I
believe that will include the Memo fields, which then just won't
be used.
It sounds to me like he's displaying the memo field in the combo
box, and that means that all the memos for all the rows displayed in
the combo box *will* be retrieved, but only once each time the form
is opened. From then on, the records displayed in the combo box are
cached locally.

I worry about memo fields displayed in a combo box (sounds like a
mistaken data type), but I don't see it as much of a performance
issue -- there's only going to be a hit on the form open.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 23 '07 #8

P: n/a
ARC
No, the memo fields are not part of the stored query of the combo box. Just
the Quote Number, Quote Date, Quote Description, Customer name, and Company
name. (2 tables: Customers and QuotesHdr)

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"Larry Linson" <bo*****@localhost.notwrote in
news:LI0zi.12710$A57.12500@trnddc04:
>the actual information displayed in the Combo Box won't
be extracted from the record until the record is retrieved. I
believe that will include the Memo fields, which then just won't
be used.

It sounds to me like he's displaying the memo field in the combo
box, and that means that all the memos for all the rows displayed in
the combo box *will* be retrieved, but only once each time the form
is opened. From then on, the records displayed in the combo box are
cached locally.

I worry about memo fields displayed in a combo box (sounds like a
mistaken data type), but I don't see it as much of a performance
issue -- there's only going to be a hit on the form open.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Aug 23 '07 #9

P: n/a
ARC
I thought of that as well. I've had countless support issues with memo
fields, and before the Jetcomp.exe utility and SR-2, it used to corrupt the
entire record. With jetcomp.exe, luckily, it would do a repair and write in:
####### in place of the corrupt memo field, so you would only lose the memo
text, and not the entire record.

Definetely another vote for a heavily used memo field to be in a separate
table.

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"ARC" <an**@andyc.comwrote in
news:eS****************@nlpi068.nbdc.sbc.com:
>It will be a fair amount of work to break out the memo fields into
one separate, and I'd like to have some opinions on this. I would
think breaking them out would have the affect of the data not
coming down over the network unless a quote is selected.

I'm with Larry on seeing this as a non-issue -- it's not the way Jet
works.

However, I *do* recommend considering splitting memo fields out into
separate tables, either 1:1 or 1:N. There are two basic
justifications here, each being a separate kind of situation:

1. if a memo field is being used as a log where new data is appended
on a regular basis (often with a date stamp), it's a no-brainer,
particularly if multiple people could be trying to edit it at the
same time. In that case, each of those entires in the omnibus memo
field should be it's on record in a 1:N table.

2. for regular memo fields *not* used as a log, it's just safer to
store them in a different table. When the memo pointer gets
corrupted, you have problems with the whole record. But if you move
the memos to a separate table, if a memo pointer gets corrupted, all
that's lost is the memo data -- you don't have to do any recovery to
recreate the rest of the parent record.

I also seriously suggest that all memo editing be done in unbound
textboxes, populated in the OnCurrent event, and written back to the
form's recordsource in the unbound control's AfterUpdate event.

But that might not be necessary with the separate table, as in
there's less fragility, and no contention for locks on the main
record.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Aug 23 '07 #10

P: n/a
"ARC" <an**@andyc.comwrote in
news:Rj*****************@newssvr25.news.prodigy.ne t:
No, the memo fields are not part of the stored query of the combo
box. Just the Quote Number, Quote Date, Quote Description,
Customer name, and Company name. (2 tables: Customers and
QuotesHdr)
Then they won't be pulled down until the record they belong to is
retrieved.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Aug 23 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.