Fejl 3048 "Cannot open any more databases" - TableIDs opbrugt

Har aldrig selv mødt den fejl, men synes at have set, at skift fra 32-bit til 64-bit Office skulle kunne hjælpe.

Ja men 64-bit Access er et totalt andet program og ikke alment anvendeligt.
Fejlen er kendt i store programmer og beskrevet af MS men løsningen er "bare gør det bedre" altså INGEN løsning.
Hvad MS ikke vil indrømme er at Access slet ikke er til større komplekse programmer.
Men der må være en løsning hvor programmet f.eks i en menu stoppes op og TableIDs genetableres. Er der nogen der ved hvordan TableIDs " Nulstilles" / genetableres alternativ DB'en "opfreskes"

Office/Access i 64-bit er skam det samme som i 32-bit, blot i stand til at udnytte et meget større RAM-område. Det er også derfor, 64-bit installeres som standard og efterhånden bruges af det fleste. Access kan også sagtens køre store ting, men som med alt muligt andet, skal man vide, hvad man gør og under hvilke begrænsninger.

Hvis du er i gang med at lave "noget stort", vil jeg nu også anbefale Visual Studio til at programmere det i C#. Det tager længere tid at lave, men til gengælde kan man lave alt.

Hvis du insisterer på at fortsætte med 32-bit, kan du følge med i Karls video og se, om aktivering af LAA (Large Address Aware) kan afhjælpe dit problem:

https://www.youtube.com/watch?v=JTTsyNzY_i8

Jeg kender Karls men det er ved hukommelsesproblemer. Det har jeg ikke. Det er
ressourcerne i TableIDs der er opbrugt. Det sker primært ved store programmer der deles. Linkene til DB trækker dobbelt på TableIDs.
Jeg overvejer derfor Sharepoint. Sharepoint 2013 skulle være gratis. Har i erfaringer med det.

Sharepoint er ikke gratis, men følger med et Microsoft 365 E3 eller E5 abonnement (og måske også andre).

Sharepoint-tabeller skulle fungere fint, bare der ikke er for mange records. Over ca. 5000 begynder det at køre langsomt, siges det - har ikke selv prøvet.

Hvis du holder dig inden for Access har jeg et par fif.
Bare for at slå det fast: Problemet opstår, når du en opdelt database (FrontEnd - BackEnd).
Jeg har oplevet fejlen i en applikation med rigtig mange DropDown bokse - hvor du bruger en TableID både til recordsource og til rowsource - fejlen kommer, når jeg fx åbner en formular eller udskriver en rapport, hvor der i den underliggende forespørgsel er mange - mere end 16  - relationer til én eller flere tabeller.
Jeg har også oplevet det, hvor jeg har brugt eksorbitant mange Dlookups til at hente data til en formular.
Måden jeg undgik problemet var, at jeg, forud for fx en rapport, bruge én eller flere forespørgsler til at parkere data i en temporær tabel, og bruge den som recordsource til rapporten, altså:
Jeg har en rapport som indeholder 76 felter: fx navne på medarbejdere. I hovedtabellen er disse medarbejdere blot repræsenteret med deres ID i medarbejdertabellen.
Jeg har oprettet en tabel med plads til navnene på de 76 medarbejdere. Jeg har lavet tiforespørgsler, der hver kopiérer otte medarbejdere over i den temporære tabel (Hvis de i øvrigt opfylder kriterierne for at komme med i rapporten).
Rapportens recordsource er den temporære tabel.
I Rapportens On Open event køres følgende:
Slet indholdet i den temporære tabel.
Giv brugeren mulighed for at angive udvælgelseskriterier (fx inputbox . . .)
Kør de ti forespørgsler. (For I = 1 to 10 DoCmd.RunSQL . . .)
Lignende metode kan bruges til formularer, der ikke anvendes til indtastning.

Hvis du bruger Recordset som fx:
Set Db = CurrentDb
StrSQL = "SELECT SomeFields FROM SomeTable"
DB:OpenRecordset (StrSQL).

Så husk at rydde op, når du er færdig - det frigiver TableIDs:
RS.Close
DB.Close
Set DB = Nothing
(muligvis dobbeltkonfekt - men så er du sikker)

Meeeen - undervejs har jeg da også overvejet at flytte løsningen til en SQL-database . . .