G
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
D
Douglas J. Steele
You might try putting your question in the big white space, so that we know
what you're looking for.
It would probably help to indicate what version of Access you're using (and
maybe even the version of Windows)
what you're looking for.
It would probably help to indicate what version of Access you're using (and
maybe even the version of Windows)
G
gregory.hickmott
sorry
using 2003
trying to arcive some records in the backend to help with speed would like
to have a button to switch back and forth form the old records or the
current records
using 2003
trying to arcive some records in the backend to help with speed would like
to have a button to switch back and forth form the old records or the
current records
T
Tom Wickerath
Hi Greg,
You might try using Jeff Conrad's sample to see if you can accomplish what
you want to do:
http://www.access.qbuilt.com/html/custom_login.html
In particular, see the section that reads:
A Custom Login Form Can Provide Multiple Solutions
1. I needed a way to log into not only the main program, but a sample
database as well. A simple checkbox on my custom login screen accomplishes
that. If the user ticks the checkbox on the form, then my code opens a
different MDB file that is a mirror image of my main application. This
sample database is used for training purposes so users can become comfortable
with using the application before using live data.
There is a downloadable sample database with this article. For other issues
that may help with speed, see my article:
Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html
Unless your database size is getting rather large (ie. >= 1 GB), you might
be able to achieve acceptable performance by simply adding a boolean (Yes/No
data type) field to the table named something like blnArchived. Index this
field. Then add this field as a criteria (False) for queries that use this
table.
Tom
http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
:
sorry
using 2003
trying to arcive some records in the backend to help with speed would like
to have a button to switch back and forth form the old records or the
current records
You might try using Jeff Conrad's sample to see if you can accomplish what
you want to do:
http://www.access.qbuilt.com/html/custom_login.html
In particular, see the section that reads:
A Custom Login Form Can Provide Multiple Solutions
1. I needed a way to log into not only the main program, but a sample
database as well. A simple checkbox on my custom login screen accomplishes
that. If the user ticks the checkbox on the form, then my code opens a
different MDB file that is a mirror image of my main application. This
sample database is used for training purposes so users can become comfortable
with using the application before using live data.
There is a downloadable sample database with this article. For other issues
that may help with speed, see my article:
Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html
Unless your database size is getting rather large (ie. >= 1 GB), you might
be able to achieve acceptable performance by simply adding a boolean (Yes/No
data type) field to the table named something like blnArchived. Index this
field. Then add this field as a criteria (False) for queries that use this
table.
Tom
http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
:
sorry
using 2003
trying to arcive some records in the backend to help with speed would like
to have a button to switch back and forth form the old records or the
current records
T
TC
If the # of records is affecting your speed, you almost certainly have
a problem in the design of you tables and/or SQL. Access will happily
deal with a million records (for exmple) with almost undiminished
speed, if everthing is designed properly. This is due to the indexing
process that occurs in any database product. A great big phone book is
not much slower to use than a wee small one, even though the bigger
book has many times the # of entries.
I suggest that you show us some of your tables. For each one, list the
main fields (just the names will do, we do not need the types &
lengths), and clearly show which field(s) are the primary key in each
table. Maybe somehing will be obvious there.
HTH,
TC
a problem in the design of you tables and/or SQL. Access will happily
deal with a million records (for exmple) with almost undiminished
speed, if everthing is designed properly. This is due to the indexing
process that occurs in any database product. A great big phone book is
not much slower to use than a wee small one, even though the bigger
book has many times the # of entries.
I suggest that you show us some of your tables. For each one, list the
main fields (just the names will do, we do not need the types &
lengths), and clearly show which field(s) are the primary key in each
table. Maybe somehing will be obvious there.
HTH,
TC