Access Newbie

[forgottensunset]

What I want to do is create forms to use when replacing a part. These forms
include what part and what system it came from. From there I would like the
information to be logged under the system with the problem description
entered on the replacement form, and also deduct any parts used from the
inventory.

Would it also be possible to have access fill out an excel form? Or at the
very least email me when products drop to a certain level?

 

[Arvin Meyer [MVP]]

What I want to do is create forms to use when replacing a part. These
forms
include what part and what system it came from. From there I would like
the
information to be logged under the system with the problem description
entered on the replacement form, and also deduct any parts used from the
inventory.

You need to build the table structure first and base the form on that.

Would it also be possible to have access fill out an excel form? Or at the
very least email me when products drop to a certain level?

Access doesn't have triggers, so an email cannot be generated by a table
event. But, inventory can be checked when an order is placed via a form, and
an email can be sent from the form event.

 

[Larry Daugherty]

The answer to your every question both expressed and implied is "Yes".

However you have to intelligently factor in Time, Money and your
personal involvement.

You will be involved in any case. The extent and effectiveness of
your involvement will affect the other two elements and will be
affected by them in turn.

You could search for a single solution that meets all of your need.
If and when you find it, it most likely will have a price tag
attached. More likely you won't find anything that does everything
you want. You've already started that search here. I suggest that
you continue it by using Google and other resources by searching on
elements of the solutions you seek. There are also resources that
host freebie and demo software. Simtel.com is one such. CNET.com is
another.

You can develop your own solution using Access. "Access Newbie" kind
of implies that you'd like to take that path. If that's your plan and
you have the time, go for it! If you need a well done solution that
does all that you ask and imply then expect it to be ready in about a
year. Additional money: $0.0, time expended: 1 year, your
involvement and effort: 1 year.

A third path is to have your application built to your specifications:
where ever you are there are probably Access developers in your local
market. There are internet based companies who will get you to fill
out their forms online and who will quote you a price. There are also
independent Access developers who can help you. In any of these
paths: your time and effort are significantly reduced. Both time to
deliver and cost will be hugely affected by what it is that you really
need and want and by the amount of interaction required to know what
that is. Yes, a lot of those independent Access developers are
contributors in these newsgroups but *Don't* post jobs or work
requests into these technical newsgroups. There are job related
newsgroups and other venues altogether for that.

While you can post where ever you choose, this newsgroup is kind of an
omnibus Access newsgroup. If you're looking for newsgroups that are
more focused on things of interest to newbies I suggest

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

In those groups you'll see lots of issues posted by others who are in
the early stages of Access development. You'll get the benefit of
seeing their issues and the solutions to them. The same folks who
post solutions here also lurk those newsgroups and post solutions
there.

A great web site for developers of all levels is
www.mvps.org/access

What ever the path you choose, Welcome to Access.

HTH

 

[bsmith59]

What I want to do is create forms to use when replacing a part. These forms
include what part and what system it came from. From there I would like the
information to be logged under the system with the problem description
entered on the replacement form, and also deduct any parts used from the
inventory.

Would it also be possible to have access fill out an excel form? Or at the
very least email me when products drop to a certain level?

As several other well put replies stated, you have a lot to consider
beyond feasibility. Everything you mention is certainly feasible. I
would recommend that you certainly think about table structures, as
Arvin mentions, but for novice users it is often good to do a sketch
of what your form(s) would look like in advance. Thinking as a user
first, then as a software developer. That may sound backwards and I
may get some chiding for it. Also, if you do choose to go with a
contractor, I'd suggest the same thing, be very explicit about what
you want from a user perspective, and write a fairly detailed set of
requirements at the "what" level. And by that I mean "what the
application should do." That way the programmer can worry about "how"
it gets designed and implemented. If you choose to create your
application yourself, I'd suggest the same process. If you jump to
the "how" it will work immediately (table schemas, VB functions), you
may lose sight of what you ultimately want to see in your solution.

Good luck and have fun!

Brandon Smith-Daigle
long-time software product manager, occasional access developer
http://accesspro.blogspot.com (access tips for non-programmers)
http://www.opengatesw.com

 

[John W. Vinson]

As several other well put replies stated, you have a lot to consider
beyond feasibility. Everything you mention is certainly feasible. I
would recommend that you certainly think about table structures, as
Arvin mentions, but for novice users it is often good to do a sketch
of what your form(s) would look like in advance. Thinking as a user
first, then as a software developer. That may sound backwards and I
may get some chiding for it. Also, if you do choose to go with a
contractor, I'd suggest the same thing, be very explicit about what
you want from a user perspective, and write a fairly detailed set of
requirements at the "what" level. And by that I mean "what the
application should do." That way the programmer can worry about "how"
it gets designed and implemented. If you choose to create your
application yourself, I'd suggest the same process. If you jump to
the "how" it will work immediately (table schemas, VB functions), you
may lose sight of what you ultimately want to see in your solution.

Excellent point! There are two traps to avoid: the Sylla of designing the
application to fit a preconceived form (which will almost surely give a badly
non-normalized, impractical or inflexible design), or the Charybdis of going
all geeky and trying to teach users the minutiae of relational design. (I tend
toward the latter).

At the best, it's an iterative cooperative process, with the user interface
driving the "where", good relational design and good programming driving the
"how", and each informing and quite possibly improving the other. When it's
going well it feels great!

John W. Vinson [MVP]

 

[Larry Daugherty]

Charybdis & Sylla, Oh my!

Is that, as we say in the vernacular, "A rock and a hard place"?

Yep, it's Heaven when it's working and Hell when it's not.