When you open your fe, no connection to the be exists. The connection is not made until you access a linked table. At this time the be db is opened and the .ldb file for it is created. This process takes some amount of time. When you close the open recordset, the be db is closed and its .ldb file is deleted. This process takes some amount of time. The point of the help entry is that you can force the be to open and remain open throughout your user's current session. To do that, it tells you to create a dummy table just for this purpose. Then as part of your startup process, open a recordset of this table and simply leave it open until your db closes. This forces the be db to be permanently open. This is a good solution for a be db that does not get much use and so will probably not be already open when this fe needs data from it. If the be is already opened by another user, the current user is simply added to the active users collection in the be's .ldb.
If you have a very active be that will usually be open when a fe needs data, you absolutely do NOT want to implement this suggestion since it will limit the number of users who can access the be. The in and out method works very well for an open db and is actually the technique used by the big guys like Oracle and DB2 whose db's are technically always open. Any database can support only a limited number of threads at any one time and Access is no exception. Say that number is 10 (the actual number for Jet is 255 but the practical limit reported here runs closer to 25). Assume that you have 25 users who may come and go during the day. At any one time you may have only 10 fe's linked to the be. This will probably not be a problem since a fe requests data, processes it and then closes the recordset freeing the connection. However, if you implement the help entry sugestion, the first 10 users to open the db will lock it up and prevent any of the other 15 users from getting any data even if some of the first 10 are not currently accessing be data.
The process of managing a shared database is VERY complicated and Jet does a pretty good job.
Since you KNOW that your tables will contain large numbers of rows, you should be designing with the idea of minimizing the issues should you need to upsize to SQL Server, etc. Make sure you read all the ODBC optimisation techniques and implement them even though your linked tables are Jet. Make sure that your table and column names won't cause any problems if you need to upsize (get rid of special characters and embedded spaces) and ALWAYS base your forms and reports and combos on queries that include where clauses to limit the number of rows returned. Also create your Select's with specific columns rather than the lazy Select *; that will reduce the number of columns that need to be retrieved and sorted by your queries resulting in a speed improvement.
