Menus & Memos

[Edward F. Schulz]

Hi Phorum,

I have seen many cases of using a dummy table and storing all tables
as well as reference to using a separate table and putting the memo
field in it. The menus I make are just a form with buttons on it to
open a table for viewing or entering data and also to print any needed
reports. Is this approach not stable enough in some cases to be a
viable technique?

I also need to know why putting a memo field on a form is not
acceptable. Usually the memo fields in my tables have little more than
a few sentences.

I would appreciate learning why my approach is not acceptable, any help that anyone can offer will be garciously accepted.

efs

[Tom Cone Jr]

RE: Menus & Memos

Ed, this has been pretty much beaten to death in lots of earlier threads. In summary:

1) putting the memo field in a linked table protects the rest of your data if the memo field goes bananas (a technical term)

2) Dr. Wayne recommends a very specific sequence for data entry into memo fields to avoid conflicts that are otherwise possible in a multi-user data entry environment.

-- tom

[JerryBrightbill]

RE: Menus & Memos

I am not quite sure exactly what you are asking, but I can try to address the use of a dummy table for menus and why keeping memos in a separate table seems like a good idea.

First, concerning menus. Many developers use a table with very few fields, frequently just one, with just one record and create a menu form using that table. Then, using buttons, the menu can allow the user to open other forms, print reports, etc. There are a number of advantages. One of the biggest is that, normally, there is no action within the application that will need to the access the table the menu is based on. There are a number of maintenance items you may want to include in menu options, like reindexing all files, which will need access to tables that are in use. With one record, there is no index, and since the one record never changes, no maintenance must be done on the table. Plus, when just the form is open, only a very small table is open. Most menus stay open in the background so if you base a menu on a larger table that is opened and edited frequently, you increase the program overhead as you will have the same, larger table open more than once. Simplicity is also a nice benefit. I have a table that is just used for start up menus. When I start work on a new application, I can just copy that table with its form/s and I already have a ready made, customizable menu.

Concerning keeping memos in a separate table linked one to one, this is something done primarily for safety. Some people have had trouble with memo fields becoming corrupted. If they are in their own table, only that table is affected, and the main table is undamaged. If they are part of a main table, you could have a problem where you could not access all of the records if one has a corrupted memo. I have never (yet) had problems with memos. In cases where they are rarely used, and then only for short notes on a few records, I leave them as a field in the larger table. In a case where nearly every record will have a memo, I keep the memos in a separate table. Paranoia won in that case.

Jerry

[Edward F. Schulz]

RE: Menus & Memos

Hi Tom,

I understand the thought behind having a separate table 1 to 1 for the
memos now and agree with everything you say. I'll make it a point to
do that in the future.

As far as the menuing technique, I come pretty close to what is being
suggested, in the future I'll do the dummy table and will sleep better at nights knowing that if it gets corrupted, that all I'll lose is the memos.
Whoever started that either lost a table or did some heavy thinking in
advance.

Thank you both for clearing that up for me,

efs