14. september 2018 - 16:30 Der er 24 kommentarer og
1 løsning

Run-time error '3048': Der kan ikke åbnes flere databaser

Jeg har et Accessprogram, som får denne fejlmeddelelse. Det sker, når jeg kører "DoCmd.RunSQL".
(Jeg har selvfølgelig ledt efter svar på dette problem på nettet uden at have fundet andet svar end, at jeg må have en uendelig løkke - hvilket jeg ikke har)

Jeg kører programmet fra en DOS-bat, og det lukkes således ned, når det er færdigt. Jeg kører 'komprimér', hver gang jeg lukker.

Jeg har reboot'et, men fejlen kommer igen. Jeg har sprunget linjen over i debug, og fejlen kommer ved næste "DoCmd.RunSQL". Jeg har netop 'repareret'.

Fejlen kommer i et loop over et par hundrede rækker, hvor de ca. 107 første er gået igennem.

Denne del af programmet har fungeret siden 2000 og har overlevet alle windows/access-opgraderinger siden da. Den har fungeret med flere tusind rækker.

Any clues?
terry Ekspert
16. september 2018 - 15:13 #1
A similar question was up recently although I dont think we found a solution, it might give you some ideas though.
https://www.computerworld.dk/eksperten/spm/1024692
18. september 2018 - 17:51 #2
Desværre, no clues. Jeg prøver at lave en accdb, hvor jeg så sletter data, irrelevante for løsningen af dette problem, og ser om det hjælper. Ultimativt må jeg flytte hele tjavsen over i en helt frisk accdb.
terry Ekspert
18. september 2018 - 17:59 #3
"Ultimativt må jeg flytte hele tjavsen over i en helt frisk accdb"
Cant you just run a compact repair? Or maybe a decompile .. http://www.fmsinc.com/microsoftaccess/performance/decompile.asp
18. september 2018 - 18:47 #4
compact/repair har jeg kørt. Jeg kendte ikke til /decompile, så det har jeg nu gjort. Der går desværre ca. 1 times tid, før den har fået fejlmeddelelsen, så det skal jeg nok vente igen. Jeg så iøvrigt, at accdb'en var blevet meget større! Fra knap 4MB til 27MB.

Jeg komprimerer, når jeg exit'ter, så jeg så det kun, fordi jeg var gået ned. Kan dét være relateret? De tabeller, jeg indsætter rækker i, er alle eksterne som i BackEnd.

En anden ting: Kunne man ikke køre fast med /decompile? Jeg har nemlig ikke kørt "compile", og det ser ud til at virke fint!
18. september 2018 - 18:50 #5
Okay, det gik lidt hurtigere denne gang. Jeg har netop fået den igen.
terry Ekspert
18. september 2018 - 19:25 #6
If I understand you correctly, your looping and inserting records into your tables. Your front-end is going to grow too but  the back-end will grow even more and thats what you should be compacting.


I
terry Ekspert
18. september 2018 - 19:26 #7
It shouldnt be necessary to decompile instead of compact/repair ..
18. september 2018 - 20:00 #8
Okay, så misforstod jeg dit link, hvor der stod, at jeg skulle decompile, og nu kan jeg ikke lave det tilbage - alle moduler for timestamp i dag på dét tidspunkt, hvor jeg logger på. Det er ikke så godt fsa vedligeholdelse.
18. september 2018 - 20:07 #9
På vej ind for at se på nogle af mine backend-accdb-ere, fandt jeg, at der var sikkerhedsadvarsel! De skulle aktiveres. Det er mig fuldstændig uforståeligt! "Aktiveringen" har så ikke hjulpet, jeg får den igen. Jeg har kørt med kopier af data fra juli, hvor jeg ved, at de har kørt upåklageligt. Nu prøver jeg så på en anden platform.
18. september 2018 - 20:23 #10
..og her kører det uden problemer! Jeg prøver ny at flytte alle objekterne ind i en helt tom accdb.
18. september 2018 - 20:43 #11
Dette gav en fejl under compile, som lugter lidt af fisk:
"Expected user-defined type, not project"
Den kommer ved
"Dim dbs as Database" i et modul. Omdøbning til ddbs hjalp ikke.
Help gav ikke noget.
18. september 2018 - 20:45 #12
Undskyld, jeg glemte at google det først. Jeg har fundet noget interessant.
18. september 2018 - 20:48 #13
18. september 2018 - 21:26 #14
Og det virker på min pc, men ikke på min remote-pc.
terry Ekspert
19. september 2018 - 08:29 #15
"Okay, så misforstod jeg dit link, hvor der stod, at jeg skulle decompile, og nu kan jeg ikke lave det tilbage - alle moduler for timestamp i dag på dét tidspunkt, hvor jeg logger på. Det er ikke så godt fsa vedligeholdelse."

? No idea what your trying to tell me here, you have to realise that I have no idea what your program does, or anything else about it for that matter.

If you get an error when you compile then you have to correct those errors to ensure your code runs correctly.

"Og det virker på min pc, men ikke på min remote-pc."

What works/doesnt  work?
19. september 2018 - 20:42 #16
Øh, jeg prøver sådan set ikke at fortælle dig noget, det var bare en situationsrapport. Jeg kunne køre tingene accdb'em på min private pc, men ikke på den jeg havde remote. Kort efter gik den så ned på pc'en også!
I mellemtiden har jeg fundet ud af, at jeg ikke altid har lavet en .close efter opefilrecores, så det har jeg nu gjort, men det virker stadig ikke. Det er meeeget mystisk.
terry Ekspert
19. september 2018 - 22:30 #17
Is it possible to see the dB, or at least the part which is causing the problem?
ekspertenATsanthell.dk
AT = @
If you send it I'll take a look tomorrow.
20. september 2018 - 01:53 #18
Tak for dit tilbud.
Jeg er nu der, hvor jeg har lavet errorhandling på ALLE databasekald. Når den så går ned, lukker accdb'en og lader dos om at starte den igen på ny, indtil den er stoppet på normal vis. Længere historie med passende beskrivelse af, hvor langt den er nået osv osv. Der er desværre forretningshemmligheder i accdb'en, som det vil tage forholdsvis lang tid at rydde ud i.
terry Ekspert
20. september 2018 - 08:45 #19
Når den så går ned, lukker accdb'en og lader dos om at starte den igen på ny, indtil den er stoppet på normal vis.

Not sure I understand, can you give a bit more information?

Is there "forretningshemmligheder " in your code?

And maybe its possible to replace the data with anything ...
20. september 2018 - 13:43 #20
Jeg er ret glat for, at du tilbyder at se det igennem, men det er faktisk koden med tilhørende løsninger, som er det hemmelige.

Programmet kører fra Schedularen via en DOS-bat-fil. Nu har jeg ændret bat'en:

:loop
KØRACCESSDATABASEN
if exist Continue.txt goto loop

accdb'en starter med at se, om Conintue.txt findes, og så fortsætter den, hvor den slap (hvilket jeg ved, hvor er). Hvis continue.txt ikke findes, dannes den.

Når accdb'en er færdig uden nedbrud, sletter den Continue.txt.

Clumpsy. Jeg ved, at det er at kurere forkølelse ved at putte en spand under næsen, men jeg skal videre og har ikke mulighed for at fejlsøge, når kunderne mangler data. Jeg håbede på, at der var en simplere løsning. Jeg skal køre over 3.000 rækker, og der er pt kun ca. 100 pr. minut! Tunge sager, og ja, det kunne i al fald optimeres!
terry Ekspert
20. september 2018 - 16:20 #21
Well good luck ;-)
20. september 2018 - 19:26 #22
Terry, ikke en egentlig løsning, men mange godt hints undervejs!
terry Ekspert
21. september 2018 - 10:01 #23
Thanks
"og ja, det kunne i al fald optimeres!" ;-)
terry Ekspert
21. september 2018 - 10:05 #24
Oh, another idea. I'm getting the impression that your looping through a recordset and then inserting into other tables.

When you get around to optimising the code then maybe you could consider using an INSERT INTO SELECT which will use fewer connections.

https://www.w3schools.com/sql/sql_insert_into_select.asp
25. september 2018 - 18:56 #25
Jeg vil ikke sige, at jeg fandt fejlen, men jeg fandt en løsning!

Jeg har mange tabeller linket på på txt-filer og xslx-filer. Jeg tænkte efter døgntests på det ene og det andet, at det måske havde noget med det at gøre. Jeg kopierede derefter alle til interne, og wupti, så var fejlen væk! De SKAL nu være eksterne, for mange er ret store osv -det er gennemtænkt.

Det viste sig efter adskillige kombinationer af at kopiere tabellerne intern (med 1-4 timer pr. test), at jeg fandt en enkelt, som den ikke kunne lidt. Jeg kopierede den så internt, og alle var glade. Det er en fil, som ændres hver nat, så jeg er nu nødt til at kopiere den ind ved hver kørsel. Det var i øvrigt en excel-fil med 4000 rækker.

Og nu jeg var i gang, gjorde jeg det med 3-4 andre, og det har øget hastigheden væsentligt.

terry: Jeg er sikker på, at jeg brugte dit clue med at have læsning af én database (tabel) sammen med skrivning i en anden ikke var så godt. Det var nu ikke tilfældet, men det fik mig til at se på koden på en anden måde - ud fra tabellerne -, og dét gav et break through. Kopieringen i starten tager ca 5-10 ekstra minutter og sletning i slutningen ca 2-3, men resten kører nu på 10 minutter. Lidt af en optimering fra tidligere flere timer. Omvendt skal jeg så administrere lidt mere, for koden er bestemt ikke blevet simplere. Samtidig bliver databasefilen gigantstor, så jeg må slette de interne tabeller igen og komprimere ved hver exit.
Nu skal dette modnes, og så snupper jeg de sidste eksterne kald fra programmet ud af brødkoden og hen til initialisering.
Tak igen.
Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links

Opret Preview

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester





Premium
"Det kan godt være, at du tjener flere penge i det private, men du har ikke det samme fokus på faglighed, sammenhold og netværk som i det offentlige."
"Når først noget fungerer i det offentlige, så går man all in, og det kan man også mærke for tiden i forhold til ny teknologi og digitalisering i kommunerne."
CIO
Tech fra Toppen: Tim Vang får hastigheden op og de rigtige idéer frem med Googles pretotyping
Tech fra Toppen: Tim Vang får ideerne frem og hastigheden op ved konstant at tænke små overskuelige eksperimenter ind idéprocessen. Metoden hedder pretotyping og stammer fra Google. Lær meget mere om, hvordan du kan bruge værktøjet her.
Job & Karriere
Efter blodrødt regnskab: Nu fyrer Atea 20 medarbejdere i Danmark
Atea fyrer nu 20 medarbejdere. Det sker som en direkte konsekvens af, at den danske forretning er under pres, oplyser selskabets direktør.
White paper
Vil du snydes når du skal vælge printløsning?
Svaret er forhåbentlig/naturligvis nej, men sandheden er at det er et reelt problem for mange virksomheder. I langt de fleste tilfælde skrives der under på kontrakter, der binder virksomheder til unødigt kostbare og langvarige leasing og lejeforløb, og underskriften er desværre bindende. Derfor – der er mange penge at spare ved at få den rigtige rådgivning og sætte sig ind i aftalerne, og vi har samlet 5 gode råd i dette whitepaper.