Office: (Office 2010) Fehlermeldung

Guten Abend,
kann jemand etwas zu dieser Meldung etwas sagen?
Hintergrund ist:
Habe von einer 100% funktionierenden DB mit dem Windows-Explorer eine Kopie erzeugt.
Das Original funktioniert jetzt nicht mehr, die Kopie aber 100%.

Das kann doch nur mit dem kopieren zusammenhängen.
Oder spinnt Access manchmal?

:)

 

Manchmal schon, so nach Updates und so, aber insgesamt eher weniger als anderes.

Die Datenbank war hoffentlich geschlossen, als sie kopiert wurde?
Was fand rundherum um das Kopieren statt? Bei Löschungen, Rechnerwechsel usw. können Verweisprobleme auftreten, die dann etwas missverständlich in der Meldung sind, aber zur Unausführbarkeit führen können.

Die in der Meldung genannten Befehle Return und GoSub kommen in üblichen heutigen Programmierungen nicht mehr vor. Falls also die Meldung keinen Unsinn, sondern Realbezug vermeldet, würde ich an das "funktionierend" einige Abstriche machen wollen.

 

\@Eberhard
Die DB war natürlich geschlossen.
Eine 100% Kopie sollte doch korrekt sein, meine ich.
Das hab ich schon 1000 mal so gemacht.- Sicherheitskopien eben, vor Änderungen z.B.
Ich hatte das vor kurzem schon einmal, mit einer anderen DB. Ursache - unbekannt.
Meine Vermutung ist das Access manchmal mit allzu vielen VBA Codes nicht klar kommt.

Access als solches schmiert schon mal. Dann finde ich eine "Backup" Datei, die muss aber Access selbst erzeugt haben.

Habe jetzt die Kopie in Nutzung. Keine Ahnung was der Fehler soll.

 

Die Spezifikationen (Grenzen) werden recht selten ausgereizt.
Probleme entstehen eher über unsaubere Programmierung, fehlende Kompilierung, fehlende Fehlerbehandlung, undefinierte Zustände während der Programmierung - also beeinflussbare menschliche Tätigkeit.

Wenn man an höhere Mächte glaubt: Das Hassen von Codes könnte Rückwirkungen erzeugen (selbsterfüllende Prophezeiung).

 

\@Eberhard:

Wie meinst Du das, Eberhard? Gelegentlich nutze ich es schon - i.d.R. um Wiederholungen innerhalb einer Prozedur zu vermeiden.

 

Dein Sarkasmus ist in diesem Fall eher unseriös. Warum?
Weil die Datenbank absolut saubere Codes enthält, (fast alle hier aus den Hilfestellungen) keine Code Leichen etc.
Da achte ich sehr genau auf Details.
Ausserdem läuft die Kopie einwandfrei. Das Original und die Kopie wurden innerhalb von 1 Minute gespeichert und
sind normal als 100 % deckungsgleich anzusehen.

Die Datenmenge als solches dürfte für das Programm ein "Klacks" sein. (1700 DS)

Mein Verdacht hat sich aber bestätigt. Ich habe einen Code aus dem Ereignis Privat Sub Form:Load einfach mal kopiert, dann gelöscht, und genauso wieder eingefügt.....siehe da .....Fehlermeldung ist weg.
Dieses Verhalten hatte ich schon mal, wie gesagt, andere DB, anderer Code.

Es kommt vor, da findet Access nicht die Stelle wo der Code steht.
Die Folge der Fehlermeldung ist: der Code wird nicht geladen, die Funktion ist nicht verfügbar.

Hat jemand das schon mal gehabt und wenn ja, was habt ihr unternommen?*entsetzt

 

Die Access VBE ist leider etwas fehlerbehaftet.

Was man versuchen kann:
Komprimieren & reparieren.
Decompile - falls unbekannt googeln.
Wenn das nicht hilft, dann Objekte so fern möglich in andere DB exportieren.

Das Thema gibts hier gar nicht so selten.

Was sicher hilft: Nicht mit Access arbeiten *grins

Ich weiß nicht wie es anderen geht.
Aber solche Probleme sind mir bei anderen Entwicklungsumgebungen noch nie begegnet. Insofern ist Access was die Entwicklungsumgebung betrifft eher unsicher.
Codeverwaltungen können das Problem entschärfen.

 

Ja, kam bei mir schon mal vor. Die Lösung war genau das, was Du unternommen hast.

 

Das deutet eher darauf hin, dass das Wort [Ereignisprozedur] in den Eigenschaften beim betreffenden Ereignis gefehlt hat (vielleicht irrtümlich manuell gelöscht). Der VBA-Code bleibt dabei bestehen, beim Eintritt des Ereignisses wird aber dieser Ereigniscode deshalb nicht ausgeführt. Abhilfe schafft dabei, in den Eigenschaften beim betreffenden Ereignis das Wort [Ereignisprozedur] wieder einzutragen bzw. auszuwählen und das Formular zu speichern.

Das ist kein Fehler. Man kann das auch per VBA-Code - Stichwort [Event Procedure] - löschen, um z. B. den Aufruf eines Ereigniscodes bei einem Ereignis kurzzeitig zu unterbinden.

 

Wenn jetzt das Bild einer brutal unsicheren Geschichte von Access gezeichnet wird, wären das Forum hier und andere eher Notfallkliniken statt Hilfegeber zur Bedienung und Steuerung.

In meiner persönlichen Wahrnehmung passieren die meisten Probleme durch Windows- und Office-Updates und Hotfixes sowie durch Versionenwechsel, insbesondere durch Wechsel auf die neuesten Versionen.
Ich habe da eine Aussage, die ich mal aufgegriffen hatte, nach wie vor im Kopf und in bestmöglicher Anwendung: Verwende eine Accessversion zum Arbeiten, die mindestens das erste ServicePack hinter sich hat, die also aus dem "erweiterten" Betatest heraus ist. Wenn man das auch auf die Verwender eigener Entwicklungen übertragen kann, ist das Fahrwasser deutlich ruhiger.

Bei einem systemischen Problem würde man eine Fehlerquote in Richtung 100 Prozent erwarten. Ist das so?

So etwas kann manchmal passieren, wenn per Einstellung eine DB sich beim Schließen selber komprimieren soll. In der guten Praxis hat man für die Anwendung aber eine Trennung in Frontend und Backend. Das Backend würde per Anweisung komprimiert, wenn man sichergestellt hat, dass es keine weiteren Zugriffe darauf gibt und es selbstredend nicht geöffnet ist. Im Frontend gibt es eigentlich wenig Gründe für ein Komprimieren (von Daten!). Sauberer Code schließt auch die Objekte, die man geöffnet und verwendet hat. Wer ein regelmäßiges zusätzliches Reparieren benötigt, sollte da Überlegungen anstellen.

Was ich hier ausdrücken möchte: Auch durch seine Arbeitsweise kann man Fehler haben oder erst gar nicht dazu kommen. Bei aller Kritik nach außen sollte man nie ein Schlückchen Selbstkritikfähigkeit vergessen.

@Frank200:
In gängigen mir geläufigen Codes gibt es Sprungmarken und deren Verwendung nur noch im Rahmen von Fehlerbehandlungen.
Codewiederholungen kann man praktisch vermeiden, indem man solche Passagen in eine Extraprozedur/-funktion auslagert und diese dann über die sprechende Bezeichnung aufruft. Das verkürzt eigene Codes und führt zu besserer Pflegbarkeit. Stichworte dazu: Refactoring, Clean Code.

 

Hast du beim Schließen standardmäßig Komprimieren und Reparieren eingestellt?
Das kann manchmal ein solches Verhalten auslösen.
maike

 

\@Eberhard: Danke für den Link.

 

Darf ich dazu als Normal User etwas anmerken?
Zuerst meine Antwort.- ja ich hatte bisher "beim Schließen komprimieren" eingestellt, weil ich gelesen hatte, das dies wohl besser sein soll als nicht. Hab es aber wieder geändert.

Bei Nutzung jeglicher MS Produkte habe ich es mir abgewöhnt mich mich zu wundern und über solche Dinge aufzuregen.
Oft sind solche Fehler ja selbst herbeigeführt, aus Unkenntnis usw.

Den Post 10 habe ich mit mehrfachem Kopfnicken gelesen, dem kann ich nur beipflichten.
Andererseits ist es nervig wenn man sich mit viel Zeit und Energie eine tolle Datenbank erstellt hat und diese aus heiterem Himmel völlig grundlos plötzlich abschmiert.
Was #9 betrifft, da ist und war nichts dergleichen im Code. Da fehlt auch nix. Der stammt aus einer Quelle die über jedn Zweifel erhaben sein dürfte.
Diesen GoSub Fehler kann man nicht ergünden geschweige denn 100% ausschliessen, so lese ich das jetzt.

Aber deswegen zu sagen Access sei unbrauchbar, nein - das wäre übertrieben.

Was Fehler allgemein betrifft, - wenn ich nach Tagen so in meine Daten schaue, finde ich hin und wieder merkwürdige Fehler, nichts gravierendes, aber halt Fehler. Menschlich halt.