Starting a new project - Do's and Don'ts?!?!?!?

[Guest]

I have a resource manager db that I'm "trying" to develop. My grandiose ideas
are proving more daunting due to my inability versus reality.

I'm wanting to build something that allows a user to 1) add a resource 2)
modify a resource 3) prints reports based on specified criteria stored in a
query 4) review or look at a resource based on user input, a simple search
and review with no editing.

Can anyone give some pointers/tips on what I should steer towards and or
avoid as I attempt this project.

Some functionality that I'd like to have.....

On the ADD RESOURCE form..
A confirmation button that gives the option to add another resource or save
the record and close the form. Would also validate the entered data, ( I
figure most of the validation can be based on the REQUIRED FIELD property).

EDIT RESOURCE form....
What would I need to do to have a history table? If a record gets changed I
want a history of what those changes are in another table.

PRINT REPORTS form....
I have a an exsiting Excel report that I use, can I get Access to generate
the same report with the same formatting?

Your help is appreciated!!!

 

[Allen Browne]

Okay, you have an idea of how your program should work. That's good.

The next thing might be to spend time learning how Access works. The first
thing will be to learn about relational tables. For example, one resource
will probably be booked many times over the years, so you have at least 2
tables - Resource, and Booking with a one-to-many relation between them.
Chances are that you will get repeats amongst your bookers (people?
companies? staff?), so you will need some kind of Client table to manage
them. Depending whether bookings are for a single client or multiples, or
whether a client is likely to book multiple resources at once, you will have
other tables to add to the design.

After creating the simplest relational design that handles all the
one-to-many relations you need, you can then start to think about the
interface for entering resources, staff, lookup tables, and of course the
bookings themselves. Fortunately, Access uses bound forms, so it helps
create the interface for you. A form can be used for finding, adding,
editing and deleting, so you do not need to create separate forms for each
of these.

Along the way, you will be creating queries that combine data from multiple
tables. These queries will also serve as the source for the reports you need
to create to lay the data out for printing. Access has its own reporting
capabilities. You will find it is usually much easier, more flexible, and
more stable to use the Access reporting than to try to programmatically
stuff requests from Access into Excel.

Your requirement to create a history table might disappear once you have a
relational design that keeps the previous bookings in place instead of
overwriting them every time. If not, it is possible to program Access to
give you an audit trail of changes, through you will need some understanding
of SQL and VBA to achieve that. Details in:
Audit Trail - Log changes at the record level
at:
http://allenbrowne.com/AppAudit.html

 

[aaron.kempf]

dont use access you ****ing retard

Access is for losers.

go and take a class on SQL Server or Oracle or something.. but MDB is
obsolete; and it has been obsolete for 10 years now.

it would be RIDICULOUS to learn Access in October 2006.