Setting Up tables

[Guest]

I run a charter boat, there are many other charter boats in the port I fish
out of, there are also ports to the north and south of our port that have
charter fishing.
What I first wanted to do was compare there rates to see what would be the
going rate, for 5 hours of fishing, looking at that I found that the boat &
fishing equipment they have makes for more or less of a charge.
So the tables are for all the different things about captains and there
boats who I compete against.
I keep all the cost for our boat in the company books so do not need to
include a table for boat and trip cost. I know how much I have to charge but
want to find out how much I can charge and still get customers.
Are there sample tables of a problem like this, there must be some way to
enter this data with out having to look up ID number and boat name? If I
understand what you wrote and put it into my needs. I need a (product) boat
table that would list all the boats and many other tables that would list all
the different equipment that each boat has. But I can’t understand how to
enter the data without having the boat name in the first record.
Anyhow thanks for the help for all, the project has slowed way down but will
be much better when done.
We do not fish in the winter so if I can’t comprehend this problem by spring
I will look for a expert data baser.

 

[steve]

sorry

you cant do this with microsoft access 2003.

you must upgrade to microsoft access 2004:
http://www.ammara.com/access_image_faq/access_loading_image_dialog.html


HTH

Steve

 

[Jeff Boyce]

I'm not aware of an Access 2004 version. Besides, I don't think you
mentioned which version you are considering. Careful what links you
follow...

If you have been working in Excel, you may have set up tables in Access that
mirror a spreadsheet. While this is easier for you, it is much harder for
Access. Access is a relational database, so you don't want to feed it
spreadsheetly data.

If you aren't familiar with the terms "normalization" and "relational
database", plan to study up a bit. If you structure your Access tables this
way, you'll get better use of the features and functions Access offers.

Take a look (if you are willing to follow the link <g>) at Jeff Conrad's
list of resources concerning database design:

http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html

(especially Database Design 101)

Good luck!

Jeff Boyce
Microsoft Office/Access MVP

 

[Larry Daugherty]

It seems that you have a good grasp of the market and of the business
you're in and that you're willing to invest the time and effort to
improve your returns.

First and foremost in creating any kind of a project is creating some
working documentation.

The first document is a Problem Statement. It should include a
description of the market and the business and the issue(s) you
want/need to resolve.

The next document is a Solution Statement or Product Specification.
It describes everything about the product you're going to create that
solves the problem you have defined.

Next, play over in your mind the elements in play in your
Problem/Solution domain and isolate the entities involved and how they
play together: One element you didn't mention but that I believe is
more important than all of the rest combined is MARKETING. I do
recommend that you continue this project but I also recommend that you
research the marketing efforts of your competition. I think you'll
find that the marketing has more impact on sales and on rates than
anything else, including boat size, age, crew, equipment, ...

Some entities in your app.: Port, Person (Captain is an attribute
of a person - so, too, might be "crew"), Boat (Rate is an attribute of
Boat), Term (hour, day, week, ??), Equipment, etc. You'll think of
others. Every instance of a single entity will be recorded in a
single table.

Next comes the Functional specification. It describes the functions
within your application that solve particular internal and external
issues.

At this point, a flaw in your concept of using Access is evident: You
asked about sample TABLES. The design of a particular table makes
sense only in the context of an over-all design. Your question
implies that you believe you should be massaging data directly in
tables. Not so! You should create Forms and queries to massage the
data in tables and Reports to display things that you choose in ways
that you choose. Tables are designed in anticipation of some higher
level user interface behaving as described just above. Access is not
Excel!

Once the schema (~tables) is properly designed and implemented then
creating meaningful queries and reports is a breeze. For example you
could query to find all boats from a specific port or from all ports
whose rates are between Low Rate and High Rate and return a
list/report of all boat names with Captain names and with their port
names and their current rate. You could easily show that information
ordered by boat name or by port or by rate or by Captain name or by
all of the foregoing.

If your only motivation in fiddling with Access is to build this
single application then you'll probably be better off getting
professional help.

If you want to learn Access so that you can become efficient in
developing lots of applications then I recommend that you read a book
or tow and that you continue to lurk here and in

microsoft.public.access
microsoft.public.access.gettingstarted
www.mvps.org/access

The Access learning curve is long and steep but once you're over the
hump the rewards can be tremendous.

HTH

p.s. What's a hillbilly doing on the briny?

 

[Guest]

Jeff
I have the 2003 version. I had it where I used to work and all the data was
supplied in tables. I never had to enter the data but made up queries to find
out what I wanted to know. Now I don’t have people who enter the data and
have to understand and do it myself.
For a life time I have not spent time learning just to learn. At work we had
hundreds of tables, I am sure that it was a relational data base. I will take
a look at the link and see if I can move foreword on this.
Thanks for the help

 

[Guest]

Larry
I just got sick of fishing mountain streams with small fish, and found a way
to make a living with deep water and big fish.
A good tip on marketing research it’s a fragmented business from one boat
owners to fleets of 6 or more. The way I think of this is have a table with
fields that list the different areas to advertise, and then list each boat. I
ca get the crew, equipment from another table in a query.
I don’t think the answers should come from the table but from the query. But
somehow need to get all the data entered in a manner that you can see how you
are entering it.
Thanks for the help

 

[Larry Daugherty]

You're welcome for any help I may have provided.

More power to you in finding a way to support yourself doing something
you love. It has been over 30 years since I took all of the kids out
on a charter to get salmon. We all caught out limits. We turned in
most of our catch for equivalent weight in canned salmon and saved a
few to feast on while making our way along the Oregon coast. For 15
years or so ending 6 years back I went out 5 - 10 times a year with a
friend on his boat. We fished off the Massachusetts and New Hampshire
coasts and the Isles of Shoals, mostly for blues. We just caught and
released for the most part.

Back to Access ...

Queries don't hold or generate any independent data. They are based
on tables so the data must reside in tables. Using queries and
Reports you can change how you organize and display the data.

More about marketing ...
My comment about market (ing) research is not so much an Access issue
as a business intelligence issue, similar to that which you already
want to manage better using Access. With astute marketing, businesses
position themselves in the minds of the prospects in their market and
help to create demand. People in your business doing a good job of
marketing will start their revenue season early and end it late.
Probably picking and choosing which of the prospective clients to
engage. If you offer two or more levels of service at correspondingly
different prices, it would behoove you to fill your calendar with
reservations for the more profitable service, requiring suitable
deposits to hold the reservations. You might respond to folks seeking
the less profitable services that you are booked through the season
but if they would like to go on standby for an opening at some range
of dates then you'll be happy to accept their deposit for an opening
for their desired service. You'll guarantee them [days,weeks, ??],
notice of the opening. Lots of other things to consider but all of
this chat about marketing is off topic for this newsgroup. If you'd
like to continue our discussion, just decode my address and send me an
email identifying yourself and continuing the discussion.

HTH

 

[Guest]

spreadsheetly?? rofl

I'm not aware of an Access 2004 version. Besides, I don't think you
mentioned which version you are considering. Careful what links you
follow...

If you have been working in Excel, you may have set up tables in Access that
mirror a spreadsheet. While this is easier for you, it is much harder for
Access. Access is a relational database, so you don't want to feed it
spreadsheetly data.

If you aren't familiar with the terms "normalization" and "relational
database", plan to study up a bit. If you structure your Access tables this
way, you'll get better use of the features and functions Access offers.

Take a look (if you are willing to follow the link <g>) at Jeff Conrad's
list of resources concerning database design:

http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html

(especially Database Design 101)

Good luck!

Jeff Boyce
Microsoft Office/Access MVP