Count open databases in MS Access
An application I have created at work continues to grow (using tabbed rather than overlapping windows) as I expand its functionality and now I am running into the "Cannot open any more databases" message which I understand is because I am touching the limit of 2048 connections with my open forms. So as to know which forms are the major offenders, is there any way I can count the connections by form? If MS Access knows when I am touching that limit then I would have thought there would be a way for me to know.
ASKER
What a blow! Just for clarification, if I create a complex query but only SELECT a few records from it, is it one connection per SELECTED field or does it count each field in each query?
Also, what is the general approach in a situation like this? Should I just create a second application? Every part of this app is used by all users regularly during the day so if I create a second app it will chew up more resources by having a second instance of MS Access loaded in memory, Or am I better off just changing to overlapping forms and forcing users to close forms as and when they finish with each?
Also, what is the general approach in a situation like this? Should I just create a second application? Every part of this app is used by all users regularly during the day so if I create a second app it will chew up more resources by having a second instance of MS Access loaded in memory, Or am I better off just changing to overlapping forms and forcing users to close forms as and when they finish with each?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Regretably I am guilty all counts. I was hoping there was an easy way to quickly identify the main offender. Unfortunately this is the first system I have built in a long time that evolved instead of being designed due to time constraints. Thanks again for your kind assistance
<<Regretably I am guilty all counts. >>
Well as a start, look at the queries. Any place where you have SELECT * is an easy fix and can give you a drastic reduction of table ID's being used. Just that may get you by for now.
I'd then tackle queries where nesting is heavy; anything more than a couple of levels is too much really and anything beyond four is way to much and should be re-done. And this is so easy to creep into. "I did that here and will just roll it in". Then when you stand back and look, it's amazing how much gets repeated in some places.
While this takes time and analysis because it's easy to break things, it's still one of the simpler fixes overall.
I'd then move onto the UI and break up complex forms along major functional points. Popup's can work well here. Present info to the user in a simplified form, then popup another form with the detail when they want to add/update. Think about process flow and what the user does.
Maybe right now everything is on tabs within a single form, where you could take a couple of tabs and split them off to another form.
Jim.
Well as a start, look at the queries. Any place where you have SELECT * is an easy fix and can give you a drastic reduction of table ID's being used. Just that may get you by for now.
I'd then tackle queries where nesting is heavy; anything more than a couple of levels is too much really and anything beyond four is way to much and should be re-done. And this is so easy to creep into. "I did that here and will just roll it in". Then when you stand back and look, it's amazing how much gets repeated in some places.
While this takes time and analysis because it's easy to break things, it's still one of the simpler fixes overall.
I'd then move onto the UI and break up complex forms along major functional points. Popup's can work well here. Present info to the user in a simplified form, then popup another form with the detail when they want to add/update. Think about process flow and what the user does.
Maybe right now everything is on tabs within a single form, where you could take a couple of tabs and split them off to another form.
Jim.
BTW on this
<< I'd then tackle queries where nesting is heavy; >>
The way to approach this is to create a query for each object (form, combo, list box, etc) and tailor it specifically for that job.
When you try and re-use query objects for a lot of different things, that's when you start getting extra overhead. i.e. I need these fields for this, but not for this, and then before you know it, your adding in every field possible.
Like I said, it's so easy to fall into this.
You'll end up with a lot more objects in the DB, but it will be fast and efficient that way with the least amount of overhead.
Jim.
<< I'd then tackle queries where nesting is heavy; >>
The way to approach this is to create a query for each object (form, combo, list box, etc) and tailor it specifically for that job.
When you try and re-use query objects for a lot of different things, that's when you start getting extra overhead. i.e. I need these fields for this, but not for this, and then before you know it, your adding in every field possible.
Like I said, it's so easy to fall into this.
You'll end up with a lot more objects in the DB, but it will be fast and efficient that way with the least amount of overhead.
Jim.
ASKER
Thanks for the suggestions. I will start work on it in the order you said first thing in the morning. Thanks again
Believe it or not, no. And it's not connections, but references to tables.
Every field, control, etc is a reference to table, so they can add up quickly.
Jim.