Error - template LAYOUT-DATA-WRAPPER not found

A configuration error was detected in the CGI script; the LAYOUT-DATA-WRAPPER template could not be found.

Error - template STYLE-SHEET not found

A configuration error was detected in the CGI script; the STYLE-SHEET template could not be found.

Error - template SUB-TOP-BANNER not found

A configuration error was detected in the CGI script; the SUB-TOP-BANNER template could not be found.
Subject:
From:
Jim Meagher <[log in to unmask]>
Reply To:
PCSOFT - Personal Computer software discussion list <[log in to unmask]>
Date:
Tue, 13 Jul 1999 17:14:57 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (123 lines)
Tom,

"...stand alone computer initially" sure sounds like there are plans for a
network eventually.  If so, I STONGLY suggest you design for the future and
not just today.

Several others have already mentioned the pitfalls of Access, so I will
comment on other aspects of Access.

 When it was originally designed, Access was meant to be a user friendly
"front end" for a "main frame" SQL database.  In other words, it was meant
to be a data retrieval and analysis tool rather than an actual database
engine.  But then the marketing guys at MS got involved and suddenly Access
became a "low end" database product (as opposed to Foxpro), but there was
very little change to the internal code of the product.  Therefore, when you
start working with multiple simultaneous users, the performance drops
extremely fast as more users are added.

In my opinion.....
As a pure single user system, Access is a nice and easy to use application
that requires very little training to
As a stand alone database with a half dozen or so users of varying access
levels, Access performs adequately.
As a networked database with 10-15 simultaneous users, Access is marginal at
best.

So.... I think that Access will be okay for your CURRENT needs but as you
grow, you will eventually need something more robust and suited to a
multi-user environment.  Because Access is so popular, any up-to-date
application you purchase (in the future) will be able to import your
database fairly easily AS LONG AS you stick to a plain vanilla type
database.  If you start adding exotic/complicated things, then you will end
up painting yourself into a corner.  For example, Visual Basic modules may
not translate to the new program very well, which could cause further
problems such as crashing reports that depend on the VBA to
extract/manipulate the data.

As far as the graphics are concerned, the image is retained as a separate
discreet file.  Access only records the path&filename to retrieve the image
as needed.  Image compression would be a function of the scanning software
or some other graphics application.  Make sure your scanner can save the
image file as either a JPG (compressable) or GIF.  If you are working with
black & white scans, then use the GIF format.  It is not compressable, but
it will be smaller than a JPG with a high (but unused) color count.

SCSI drives really shine in a network environment.  Again, what are your
future needs, if this will end up as a server on a network, then definitely
get SCSI.  If it will always be stand alone, go with EIDE.   Then again,. as
fast as technology changes.... who knows what will be available next
year.....<grin>

----- Original Message -----
From: Tom Cassidy <[log in to unmask]>


> Thanks for the reply Jim.  I've answered your questions below as well as
added a couple more
> of my own.  Any information you can give me would be appreciated.
>
> >> Any of the current crop of database programs can handle the data
> >> and the scanned images.  Since you used the term "users",
> >> this implies a multi-user setup.  Which adds many other factors into
the decision process.
> >> Is this database to be shared across a network?  What kind of network?
>
> No network, it will be a stand alone computer initially
>
> >>How many users will be accessing the data, in total and at any given
instant?
>
> Only one user at a time.
>
> >> Will the users have different levels of access capability?
>
> Yes, they will logon and most users will only have read access.  There
will be
> one logon for the administrator to add or modify records.
>
> >> Are there estimates to the size of the data file?
>
> There are about 10500 "jobs" to be scanned (96-99) and approximately 250
added per month.
> The plan is that we will eventually start moving data to DVD or some other
storage medium
> once they get x years old (x is yet to be determined but will probably be
about 4 years.
>
> Assuming that we use Access (open to change but that is what we have now)
can I compress and
> decompress the scanned images on the fly?
>
> What is the compression ratio for a scanned image?
>
> If I build a system with a 333MHZ processor, 512MB memory and 80GB drive
space will that
> be sufficent for what I am trying to do?  (Will also have a DVD drive for
backup)
>
> Is there any advantage to using SCSI drives as opposed to EIDE?
>
> Thanks for your help.
> Tom Cassidy
>
> > 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?

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

ATOM RSS1 RSS2

LISTSERV.ICORS.ORG Secured by F-Secure Anti-Virus CataList Email List Search Powered by LISTSERV