On 13 Jul 99, at 10:24, 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?

  Although many modern database systems allow the storage of BLOBs
(Binary Large OBjects, such as graphics) as data fields in records,
I'm not sure whether Access supports this (and in what versions) --
nor am I sure that that's the right way to go.

  Instead of storing the scanned images in the database records, I
would suggest storing the names of .GIF files which contain the
actual images.  It should be relatively easy to invoke any of the
popular .GIF viewer programs (I like LView Pro, which is shareware)
from a couple of lines of Access BASIC code.

  The other design issue is whether to provide one record per job,
with 10 fields to hold .GIF file names (and when some job needs 11,
you've got a problem!), or to split the data into two tables, one
with "job" info -- job #, customer name, job date -- and one with
"ticket" info -- job #, ticket filename.  SQL makes it pretty easy
to select all of the records from the second table whose job #
matches the record you've located in the first table, and whether
there are zero, ten, eleven or a hundred matches, neither the code
nor the database structure needs to change.


David G

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