OK, I think I am on the right track. All the forms are planned to be
based on queries off the 'current" table, except the 'past guests"
form, which is based off a query of the "archive" table, so I can see
who has stayed with us in the past.
i also have a need to know how many people are in the campground each
day. I would like the databse to run a query every day at maybe 8:00
(it should be the same time every day and should be automated) in the
morning and count the number of camping spaces that were occupied and
then store that number somewhere for later use. At the end of the
month I could run a report that lists that number for each day like:
1 800
2 799
3 811
Something simple like that. Is using a temporary table the way to go?
Something I could erase every month and start the whole thing over
again?
I have also been toying with the idea of using a web page as the
front-end. I think that there is so much more frredom in the design
with a web page and a lot of resources for graphics, etc.... Has
anyone ever done anything like that, or do you know of any utilities
that would make it easier to really make it look nice? Access seems a
littel short in that area. i guess I could design the background for
the forms in Frontpage or Photoshop and then put the fields in the
forground. Basically, I want my users accessing the database through
a browser, even though the whole thing (front-end and back-end) would
stay on my network. Tthanks agian to all you great people for sharing
your knowledge!
On 4 Sep 2006 21:09:41 -0700,
pietlinden@hotmail.com wrote:
Quote:
>If you design your database right and load only the records you need,
>then the 20K records is largely immaterial. As a general rule, don't
>base forms directly off tables. Especially if you're sharing the
>backend across a network. The peformance will be horrible. If I were
>you, I would create a new database and normalize first and then deal
>with archived data. you could move it to an "archive" table, but then
>you could just as easily base your form on a query...
>
>SELECT <field>, <field>...
>FROM <mytable>
>WHERE MyTable.Archive=False
>
>or some such thing that just essentially hides the archived data.
>Otherwise, you have to muck with union queries, and that's not fun.