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
10  2891 
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
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
"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
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
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
"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/
"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/
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/
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/
"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/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jon Smyth |
last post by:
I am trying to create a database programmatically using vb5 with the DAO 3.6
object. I'm using the following segment, but I'm not having any luck. I
can't seen to find much help either. Any...
|
by: deathyam |
last post by:
Hi,
I have an Excel 97 app in which I'm using SQL INSERTs to insert data
into an Access 97 database table.
The table structure is as follows:
VersionID (PK) (Long)
MetricID (PK) (Long)...
|
by: Thomas Zimmermann |
last post by:
Hi
I have an Accesss 97 database that imports data from an Oracle database.
Some of the text fileds in the oreacle database have a fileds size larger
than 255 characters. If I just link the...
|
by: Ryker |
last post by:
I have a form where "notes" are entered on an individual.
Unfortunately, these notes are usually longer than the 255 characters
allowed in a single text box. To get around this, I have three note...
|
by: sparks |
last post by:
I have a table in 2003 that has 221 fields defined.
I tried to add another variable and got this error.
I was surprised when it didn't say too many fields defined.
I look at the error...
|
by: Stubert |
last post by:
I have a training module db that stores information about employees
and what training they have carried our or need to carry out. One
table in this database stores what training needs to be carried...
|
by: ARC |
last post by:
I'm having trouble here with Access 2007 and connecting to a different
database.
The code below works great IF the previous back-end database connection is
still present and you are trying to...
|
by: steph |
last post by:
I have a table with 250 fields. Of course you are wondering why 250
fields... what could I possibly be storing in so many fields?
I am using this table as a general import table for files that...
|
by: tekctrl |
last post by:
Anyone:
I have a simple MSAccess DB which was created from an old ASCII flatfile.
It works fine except for something that just started happening. I'll enter
info in a record, save the record,...
|
by: Kemmylinns12 |
last post by:
Blockchain technology has emerged as a transformative force in the business world, offering unprecedented opportunities for innovation and efficiency. While initially associated with cryptocurrencies...
|
by: Naresh1 |
last post by:
What is WebLogic Admin Training?
WebLogic Admin Training is a specialized program designed to equip individuals with the skills and knowledge required to effectively administer and manage Oracle...
|
by: antdb |
last post by:
Ⅰ. Advantage of AntDB: hyper-convergence + streaming processing engine
In the overall architecture, a new "hyper-convergence" concept was proposed, which integrated multiple engines and...
|
by: Matthew3360 |
last post by:
Hi,
I have been trying to connect to a local host using php curl. But I am finding it hard to do this. I am doing the curl get request from my web server and have made sure to enable curl. I get a...
|
by: Oralloy |
last post by:
Hello Folks,
I am trying to hook up a CPU which I designed using SystemC to I/O pins on an FPGA.
My problem (spelled failure) is with the synthesis of my design into a bitstream, not the C++...
|
by: Rahul1995seven |
last post by:
Introduction:
In the realm of programming languages, Python has emerged as a powerhouse. With its simplicity, versatility, and robustness, Python has gained popularity among beginners and experts...
|
by: Ricardo de Mila |
last post by:
Dear people, good afternoon...
I have a form in msAccess with lots of controls and a specific routine must be triggered if the mouse_down event happens in any control.
Than I need to discover what...
|
by: ezappsrUS |
last post by:
Hi,
I wonder if someone knows where I am going wrong below. I have a continuous form and two labels where only one would be visible depending on the checkbox being checked or not. Below is the...
|
by: DizelArs |
last post by:
Hi all)
Faced with a problem, element.click() event doesn't work in Safari browser.
Tried various tricks like emulating touch event through a function:
let clickEvent = new Event('click', {...
| | |
