More efficient code?

  • Thread starter Thread starter Eric G
  • Start date Start date
E

Eric G

I have a checklist form that pops up as a user logs into my database.
They log in via a custom userID/password form.

The checklist pops up four times for each user, to remind them of
several items.

Since I didn't want to add another field to the basic user table I am
keeping track of the count (4) via a query made to the main table.
If the user's ID is found four or more times in the main table, then
the checklist form doesn't pop-up.

Of course this ID checking slows down the loading of the main form
ever-so-slightly.

Is there a better way to keep track of the user's checklist count
apart from adding a count field to the users table?
I suspect even if I did this, the slight delay would still occur.
The user table consists of approx. 60 names.
The main table currently consists of around 400 records and will keep
growing.

Thanks! Eric
 
Eric,

Although it may seem like a lot of work at first, you would save yourself a
lot of hassle if you used the security provided in Access and get your users
to log in that way. Then, it is easier:

i) to find out who is logged in just by using the built in function
CurrentUser()
ii) you would be able to keep track on what is going on easier too.

I think you are answering your own question in some way as you database will
get a lot slower as the records in the main table grow. That slight delay
will get longer and longer until it starts to get noticable and fustrating
for your users. First thing I would od is move the field out of the main
table and into your user table. To go one step further, if the DB is set up
as a multiuser environment then I would suggest splitting the database into
a front end and back end and creating another table in the front end to keep
track of this kind of thing. You would definatly notice the difference as
the main table fills up with records.

Just a few thoughts...

HTH,

Neil.
 
Hi Neil,

Thanks for helping out with suggestions.

Just to fill you in a bit more.
Way back, almost a year ago now, I tried experimenting with Access
security and got the fright of my life when I was locked out of my own
database! And all the other backup copies I had, as well.

That, along with the fact that I can't easily throw an Access security
user's ID into a form as easily as I can with my custom form, made me
shy away from Access security.

I realise that the database isn't nearly as secure this way, but in
our case it's not really an issue.

You should also know that this checklist probably won't be a permanent
part of the db. As the users learn from word-of-mouth or other ways
about the checklist items, I will probably remove it down the road.
First thing I would od is move the field out of the main
table and into your user table.
Click to expand...

Well the UserID field is a mainstay of the main table. I am just
querying the table now to tally up the occurence of UserIDs.
Naturally the User table has an UserID field as well.
It's in this table that I was thinking of adding a count field to keep
track of how many times the checklist has popped up. This way, a table
of some 60 odd records would be checked rather a growing main table of
hundreds of records. But I still wanted to avoid altering that table
if possible.
To go one step further, if the DB is set up
as a multiuser environment then I would suggest splitting the database into
a front end and back end and creating another table in the front end to keep
track of this kind of thing. You would definatly notice the difference as
the main table fills up with records.
Click to expand...

I don't think this would work out at all. I have split the database
into front/backend, but the various users migrate from computer to
computer to make their entries. Therefore a tally on one frontend
computer wouldn't be accurate.

Eric
 
Back
Top