Error 3048 Too Many Databases

do the users who are encountering this keep lots of tabs open simultaneously?

Do some of your forms have multiple subforms which are all open at the same time.

Do you have more indices on your tables than you really need?

Hi Dale,
Thanks for your reply. The main form contains 6 tabs which users press depending upon the situation. Some of the forms  on the tabs do have multiple subforms & this is where I've used late binding so that the datasets are not loaded until the data is required. I haven't checked the indices on the tables but will have a look at that. Thanks again for your help

<<1) Forms that use queries as the RecordSource - would there be less overhead if I were to use SQL statements rather than queries?>>

No

<<2) Would a SQL back-end running on the local PC solve this problem?>>

No.

 This error is not "too many tables" per say.

 Access has an internal limit of 2048 Table ID's and a table ID is used for every field that is currently active.  So in short, it's the complexity you have with forms.

 Are you using SELECT * FROM <table> in your queries?   That's a big culprit.

 and by the way, I've never found that having a lot of indices causing this.   It's simply the number of fields referenced at one time in all the open forms, reports, queries, etc.

 You are going to need to re-factor the app.

Jim.

Hi Jim, Thanks for your reply. I think I'm starting to get a bigger picture now & that I need to look at the number of fields & I'll also check the queries & SQL

JIm,

I thought that the indexes also contributed to the table ID count.

I cannot say that I've run into this very often over the years, but in the cases I have, I do recall having to replace SELECT * with SELECT Fieldlist, and that pruning unnecessary indices also seemed to help.  But that may have simply been about reducing the number of columns selected, not about the indices.

Dale

Have busy is the form and subforms?  When I see this issue it is usually due to to many connections (forms/subforms, combo boxes, listboxes, ...) and you need to lighten the load.  One way to do this is to use dynamic loading in which you only load tab content when the tab is actually clicked, you only load combo boxes when they receive focus, ...

Here is one article on the subject, Google and you can find more
https://www.databasejournal.com/features/msaccess/article.php/3599781/MSAccess-Load-Subforms-Dynamically.htm

Thanks for the link Daniel, very interesting - I'll see what I can apply to my application

OK, so having read through the article link supplied by Daniel (https://www.databasejournal.com/features/msaccess/article.php/3599781/MSAccess-Load-Subforms-Dynamically.htm) this seems to be suggesting loading the subforms as/when the relevant tab is clicked on by setting the sorceobject of the subform.
The basic structure of my data is as follow:
Level 1: Group Holidays
Level 2: Clients signed up for that Group Holiday
Level 3: Client Contact Details, Quotations/Bookings for Clients, Flight Info for Clients, Client Payments, Client Notes
So, when the user selects a Group Holiday the associated list of Clients is displayed and there are tabs for each of the the Level 3 categories.
At the moment I'm using "late binding" on some of the Level 3 subforms so that the recordsource is set up dynamically when the relevant tab is clicked but the article is suggesting setting the sourceobject when the tab is clicked. So my questions about this are:
1) is there any advantage to setting up the sourceobject rather than the recordsource?
2) Does this just happen once after the application is started so that when the next Group Holiday is selected the sourceobject or recordsource for the tabs is already set up (assuming they've been clicked previously)?
3) If it just happens once, could I clear the sourceobject or recordsource when a new Group Holiday is selected?
4) the article also refers to Master/Child Links for the subforms, suggesting that these could also be set up dynamically but I'm wondering whether it's necessary to set these up at all - they could be linked by setting up criteria in the subform query to select data associated with the parent form. Would that be a good approach?
Again, thanks for everyone's help, much appreciated

Hi,

What do you mean by ""late binding" ?
To my knowledge, this is a VBA technic to prevent references nightmare, it has nothing to do with forms / subforms.

<<What do you mean by ""late binding" ?>>

 The term applies to a lot of things and just means setting things at run time rather than at design time.

 Typically one binds a form or report to a record source at design time.  But if you do it at run time, you don't get hit on the table ID's until you do.

 Personally I don't like that approach.   If I'm that close to the edge, I'd refactor the interface and then you don't have to jump through hoops when working on the app.

Jim.

Jim - Thanks for your comments - I have to agree: maintaining the app becomes a bit of a nightmare. So I think I'll just have to bite the bullet & do some re-design to cut down on the amount of data being loaded

Thank you all for your comments, it's helped me to clarify what I need to do to fix this