Office: (Office 2010) Laufzeitfehler 3027

Was bedeutet "mit bewusster Unterbrechung"

Ist das Backend Access?

Hast du für den Test auch schon einen Haltepunkt eingefügt um nachzusehen, wie die Eigenschaften des Recordsets im Fehlerfall sind? Debug sozusagen.

Grundsätzlich wäre ein Insert - statt dem öffnen eines Recordsets - viel Effizienter, aber es sollte natürlich trotzdem funktionieren.

Hast du selbst einen Verdacht womit es zu tun haben könnte?

LG M

 

Hallo
Frage ist das eine FE (Frontend) BE (Backend) Lösung ?
hast Du schon Reparieren / Komprimieren gemacht ?
oder evtl. ein Compiler

kannst Du Kompilieren ?

wenn Du möchtest kannstDu mir die accdb auch an meine email-adresse senden

 

Weiter oben hatte ich beschrieben, wie ich den Fehler erzeugen kann, das meine ich mit bewusster Unterbrechung.

Ja ... es ist FE-BE ... ich bin gerade dabei, eine weitere Testumgebung zu generieren, in der sich die Tabellen in einer ACCDB befinden. Dort ist die Verarbeitung der 5000 Sätze allerdings so schnell, dass ich auf 50000 erhöht habe. Mit dem von Dir vorgeschlagenen

Code:

tritt der Laufzeitfehler 3027 nicht auf ... werde das jetzt nochmal testen mit meinem ursprünglichen currentdb.

Ja, mit Haltepunkten habe ich auch schon gearbeitet. Als ich noch mit INSERT gearbeitet habe (ein anderer Access-Spezie hat mir geraten, einen RecordSet zu verwenden ... so unterschiedlich scheinen die Meinungen zu sein) und den aufgebauten str_SQL in einer Abfrage laufen ließ, funktionierte das ohne Probleme.

Meine 42 Jahre generelle EDV/IT-Erfahrung , davon 22 Jahre mit Access reichen nicht aus, um einen Verdacht äußern zu können. Aber ich darf nochmals meinem Gefühl Ausdruck geben: Es darf nicht sein, dass durch Auslösung einer Funktion in einem InterNet-Screen (Start/Stop-Funktion während eines YouTube's) das Access-Programm mit dieser Fehlermeldung 3027 zum Absturz gebracht wird ... und das sporadisch, ohne dass eine Regelmäßigkeit zu erkennen ist. Wenn das (nämlich der Fehler reprouzierbar) der Fall wäre, würde ich mich nicht in's Forum begeben ... ich bin es durchaus gewohnt, meine Situationen selbst zu meistern.

 

Frage ist das eine FE (Frontend) BE (Backend) Lösung ?

... ja ...

hast Du schon Reparieren / Komprimieren gemacht ?

... ja ...

oder evtl. ein Compiler

kannst Du Kompilieren ?

... wenn Du den Parameter /COMPILE meinst ... ja ... habe ich ...

wenn Du möchtest kannst Du mir die accdb auch an meine email-adresse senden

... sorry ... ich bin nicht sehr oft in einem solchen Forum ... wo finde ich Deine eMail-Adresse ?

 

Und was ist deine Meinung dazu nach 22 Jahren?
Ein Recordset erzeugt einen riesigen Overhead. Alleine das die ganzen Eigenschaften der Felder und des RS in die Objekte geladen werden müssen. Da sind (wegen der Strings) 100derte Speicherreservierungen (C Programmierer wissen was das heißt) nötig. Das alles fällt bei dem Insert nicht an.

Das Recordset hat im Vergleich zu eine Aktionsabfrage natürlich auch Vorteile, aber in diesem Kontext nutzt du keine davon. Also bleiben nur die Nachteile des Overhaeads. Genauso bei currentdb. Da werden wie schon Eberhard angedeutet hat völlig unnötig Unmengen an Daten geladen um dann den Speicher sofort wieder freizugeben. Alles sinnlose Beschäftigungstherapie für den Rechner. Das summiert sich dann bei einer TS Anwendung.

Was setzt du jetzt für ein Backend ein?
Auf Access umsteigen würde ich eher nicht.

LG Markus

 

Hallo Markus,

... als BE läuft bei mir Access (ACCDB) ...

... sorry, ich verstehe diesen Hinweis nicht ... ???

 

Ich dachte du hast aktuell kein Access BE.
In einer Unternehmensumgebung würde ich eher kein Access Backend einsetzen. Diskussion darüber musst du da mit anderen führen, da ich Access eher untypisch programmiere.

LG M

 

Sorry ... da hatte ich mich missverständlich ausgedrückt ...

Code:

Beim Kunden läuft das FE (ACCDB) mit 6 BE (ACCDB)

In meiner Testumgebung (siehe obigen Bemerkung meinerseits) habe ich die Tabellen des BE in EINE ACCDB (FE) übertragen, um näher an die Auflösung heranzukommen, ob es mit FE-BE zu tun hat.

 

Hallo!

Tritt das Problem auch auf, wenn du eine explizite Transaktion einsetzt?

Ich verwende schon zu lange kein Access-Backend mehr, daher habe ich nicht mehr viel aus Erfahrung mit einem Dateibackend.
Eventuell spielt es vielleicht eine Rollen, dass Access Datensätze seitenweise sperrt.
Vielleicht spielt auch einmal mit DBEngine.Idle dbRefreshCache experimentieren.
Der Zusammenhang mit der Youtube-Videosteuerung könnte am Dateizugriff oder vielleicht auch am Virenscanner liegen, der dann vielleicht irgendetwas bremst.
Wenn du eine Beispiel-Datenbank bereitstellen kannst, mir der das Problem nachgestellt werden kann, könnte man testen und eventuell mögliche Fehlerquellen finden.


Zur Insert-Recordset-Schleife für ein Access-Backend:
Bei vielen anzufügenden Datensätzen, deren Daten nicht aus anderen DB-Tabellen erzeugt werden, sondern z. B. aus einer verknüpften Excel-Datei o. ä. abgerufen werden, kann eine Recordset-Schleife sogar besser als eine Insert-Anweisung laufen, wenn man zwischendurch (alle x-tausend Datensätze) die Transaktion abschließt und wieder neu öffnet. (Ab welcher Datensatzanzahl sich das lohnt, ist zum Ausprobieren.)

mfg
Josef

 

Habe ich noch nicht benutzt, werde diesen Gedanken mit einbeziehen.

Ja ... in diese Richtung geht meine Vermutung auch.

Auch das habe ich noch nicht benutzt.
Der Fehler tritt ursprünglich bei der Abarbeitung eines einzigen Datensatzes auf. In meiner Testumgebung habe ich den Ablauf in eine Schleife eingebaut, um den Fehler reproduzieren und eingrenzen zu können.

Ja ... der (irgendwie gemeinsam durchgeführte) Dateizugriff von mehr als einem (in diesem Fall Access und Internet Explorer) Clienten kann zu diesem Fehlverhalten führen. Den Virenscanner würde ich als Ursache ausschließen wollen, da der Fehler auf zwei unterschiedlichen Plattformen (beim Kunden auf dem Terminalserver und bei mir lokal in meiner Entwicklungsumgebung) auftritt.

Habe Dir eben eine Mail an Deine geschäftliche Adresse geschickt.

 

... sorry ... ich meinte /DECOMPILE ...

 

Mehrfache Testläufe mit dem Status, dass sich die zu beschreibende Tabelle direkt im FE befindet, scheinen darauf hinzudeuten, dass der Fehler hier nicht auftritt (es ist schwer, zu beweisen, dass es keinen schwarzen Hund gibt), sondern nur in der Konstellation FE-BE.

 

Hast du schon probiert, ob es einen Unterschied bezüglich Fehlerentstehung macht, ob das BE lokal im FE-Verzeichnis oder auf einem Netzwerk-Share liegt?

 

FE liegt auf C:ServerFoldersLZFACCE0
BE liegt auf C:ServerFoldersLZFACCE0DATA

Ist das die richtige Antwort auf Deine Frage?

 

FE liegt auf C:.ServerFolders.LZF.ACCE0
BE liegt auf C:.ServerFolders.LZF.ACCE0.DATA

... Punkte bitte tauschen gegen BackSlashes ...