programming questions

[Guest]

I have limited experience of progamming, and have been trying to figure out
how I can use VB to really increase the access benefits. I have 2 main
questions that I think can be answered w/ programming.

1)I have a list of products in a table, some of which contain sub assemblies
(and thus sub data sheets), and some which don't (and thus contain empty
sub-data sheets). How can I eliminate the EMPTY sub-data sheets, or at least
the plus sign indicting the sub data sheets next to the products which do NOT
have any sub assemblies? In other words, I want to eliminate the false
notion created by the plus sign that there is a sub assembly to a certain
product when in fact there is not.

2)The products table contains a boolean field that the user checks when
constructing a customer order. For products with sub assemblies, which are
required components of the product, how do I ensure that when a product is
checked, all sub-assemblies are checked as well? Basically, I need a macro,
etc- that will go through and automatically "select" sub-assembly components
of all selected products. This is a long way of saying, how do I set the
option field of all sub data sheets to true.

3) There are 4 products- A, B, C, and D. Both A and B require product D.
When a user is selecting products from a table (using a boolean field), how
can I automatically select D when A or B has been selected? Basically, how I
want to construct a series of If Then statements, saying If A then D, but I
really don't know how/where/what command/etc- to do this.

Any help would be GREATLY appreciated. If you have any suggestions, it
would be really helpful to know exactly where any coding goes, and exactly
how to "call" certain fields etc. I have been really frusterated by these
details for the last week. thanks!

 

[Larry Daugherty]

Your more urgent need is for a lot more learning about relational
database design and a lot of the rules for getting things done in
Access.

Two sites that I usually recommend are:

microsoft.public.access.gettingstarted
microsoft.public.access.tablesdesign.

Also, there's a great site of Access lore: www.mvps.org/access

The very fact that you're concerned with data presentation in the
tables is an indicator that you haven't yet completed a user
interface. The tables and the relationships between are the
foundation on which the rest of your application will be built. Once
the table design is done you should only be back into them if you need
to make design changes or to review what you have done. Your users
should never be permitted into the tables.!

There are lots of good books on Access. I suggest that you research
them and start with a good one at the beginner level. Access is more
difficult for beginners than the other Office applications. That's
largely because people beginning Access are also beginning to learn
about databases. In combination that makes for a long and difficult
learning curve. It is worth the trouble if you intend to write data
management applications.

HTH

 

[Guest]

Thanks for your input, I will check out those sites shortly. However, I want
to clarify some of my aims. I have already completed a set of tables,
queries, forms, etc- and have created what I think are the necessary
relationships. The reason that the user is entering stuff in the tables, is
because I believe it to be the most efficient way to get things done (it will
be used by an in-department user creating an order). The main table is
essentially a very long checklist of potential items. Doing this selection
process in a form just seems to be less efficient, and that is why they are
using the table.

 

[Larry Daugherty]

Requiring users to enter data directly into tables is an invitation to
disaster!

You cannot protect your data from errors that people might make in
tables. You cannot train people enough that they will never make an
error.

You implicitly build in a lot of protection for your data simply by
using forms. In addition you can explicitly add a lot of help,
guidance and control from a form that is impossible when things are
done directly in the tables.

This isn't about doing it my way, it's about doing it the correct way.

A word to the wise is sufficient.

HTH