Tom,

The short answer to this question is YES, you can use access. After
reading the below, Write back to PC-SOFT with more exact stuff on what
you need, there's a lot of good people out here.

The one thing you didn't mention was how many customers/job# we're
talking about here. There's a big difference in the database needs of
say, a small part-time computer builder doing a dozen boxes a year; and
say, all General Motors' parts suppliers. A more useful answer would
deal with, among other stuff, of projected realistic growth of said
business. i.e. differences between a fairly "saturated market" and a new
"start-up."

First, keep database design in mind from the very start of a project.
You'll spend hours/days/years tearing your hair otherwise. Personally, I
like to spend at least a few hours with pencil and paper doing a layout
of fields -- If you're unfamiliar with the term "field", you'll need one
of any number of good database design primers at your local bookstore.
What I try to do is figure out the ways, current and future, that an end
user will try to get info into and out of said database. What do you
want an end user to be able to change, and what not. Trust me, the WHAT
NOT will save time and aggravation on all concerned. Even the best data
on computer is useless if folks can't use it. You use your paper and
pencil time to brain storm.

If you're unfamiliar with the Access database program, there is a quite
comprehensive beginner's guide to what Access can do in the sample
database called "Northwind Traders;" a fictional small food
import-export business. There's a whole tutorial on this stuff in a
complete install of Access. The problem is many corporate IS folks don't
load this tutorial on installation. Likewise, some computer builders
don't put all the tutorials on installed systems. Or the end user may
have elected to not install tutorials; they do take up a lot of space.

Lastly, when you're fairly familiar with whatever database program
involved -- and PC-SOFT can help you get here too -- it's time to start
asking questions of your end users: precisely what do you want your
database to do. You'll need to keep in mind security also. Disgruntled
former employees with a proprietary customer list and more could put
someone out of business, literally. With that in mind, talk to the folks
who will be using the data base hands on. They'll generally be real good
guides to stuff you haven't thought of.

Now is the time to start documenting everything involved. Nothing's more
annoying that to design a custom proprietary database and then forget at
a later date all the in's and out's of why/how you designed something.
Documentation also protects you: when a frustrated customer years later
asks about some design "flaw", you can say truthfully, "Back when you
said you wanted to be able to do ABC. I said back when that your
database demands will change with time; sounds like we need to do XYZ,
which we'll have to figure out what I'll have to charge you to do."
Helps you keep customers over the long haul.

Best regards,
Jim Griffin



Tom Cassidy wrote:
>
> I need to create a database that will contain the following information:
> Job #
> Customer Name
> Job Date
> Scanned images of job tickets (could be as many as 10 scanned 8 1/2 x 11
> pages per job)
>
> The users need to be able to do a lookup based on customer name, a range of
> job numbers or a range of dates and view the scanned images as appropriate.
>
> The user currently has MS Access.  Is this a good choice for this type of
> database?

--
Prometheus was the first Beta Tester.
Sisyphus was the Corinthian Systems Administrator.

                Curious about the people moderating your
                   messages? Visit our staff web site:
                     http://nospin.com/pc/staff.html