Office: (Office 2000) ACCESS VBA stürzt ab

Hallo Zusammen,

habe seit gestern Abend ein nicht lösbares und auch sehr eigenartiges Problem. Bin dabei Ein Modul zu programmieren (code erstma egal) das über 600 Zeilen Code enthält. mit jeder neuen Zeile wird Access immer lahmer und geht soweit das Access mit einem White-Screen abstürzt und aus der Sanduhr nicht mehr rauskommt. Der Code wird aber nur geschrieben, noch gar nicht ausgeführt.

Kann es sein dass VBA während des schreibens bereits Verknüpfungen kontrolliert oder warum um Gottes Willen stürzt Access bei einem solchen Zeitpunkt ab. Bin verzweifelt weil ich nicht weitermachen kann

Seltsam ist, dass in den ersten Hundert Zeilen des Moduls keine Probleme auftreten doch die letzten 100 machen Probleme. Da reicht stellenweise schon das Setzen des Cursors um das Programm zum Absturz zu bringen.

Kann mir jemand weiterhelfen?

Gruß
Ulrich

:)

 

Hi,

erste unspezifische Maßnahmen, die man da unternimmt ist
- reparieren & komprimieren
- Kompilieren
- Import in ein neues Datenbank-Objekt
- hilft das nichts, sollte man sich wohl den Code näher anschauen.

Was ist damit gemeint? Während der Ausführung bzw. im Verwenden der DB ?

Dass Access einfach so in die Knie geht, kenn ich persönlich zur Genüge. Da kann es schon genügen ein simples Steuerelement in den Formular-Entwurf zu ziehen. Das würde ich weitestgehend als "Bug" beschreiben.

 

Ergänzend zu den treffenden Hinweisen von FredFred.

Ein Decompile der Datenbank wäre auch eine gute Idee.

Hast du irgendwelche Add-Ins für den VBA-Editor installiert? Wenn ja würde ich diese deaktivieren, um auszuschließen, dass diese an dem Problem beteiligt sind.

Hast du alle Service Packs und Updates für Access 2000 installiert? Ohne Service Pack ist Access 2000 generell nahezu unbrauchbar, weil sehr instabil.

 

Ich würde zusätzlich noch in den VBA-Optionen dafür sorgen, dass keine ungewollte Kompilierung nebenbei läuft.

 

Danke für die Infos ... hier die Ergebnisse:

Komprimieren und Rep.
Keine Äderung. Access stürzt weiterhin bei der Bearbeitung des Codes ab

Kompilieren
Führt bei mir zu massiven Problemen. Danach konnten angeblich Ereignisse beim Öffnen von Formularen nicht ausführt werden. Habe diese Änderungen wieder rückgängig gemacht

Importieren in ein neues DB Objekt
Keine Äderung. Access stürzt weiterhin bei der Bearbeitung des Codes ab

Daraufhin habe ich folgendes versucht:

Aufteilung der 600 Codezeilen in zwei verschiedene Module
Problem gelöst. Code lässt sich jetzt wieder bearbeiten.

Wer soll das verstehen?

Gruß
Ulrich

 

Ohne die DB zu sehen, sicherlich im Höchstfall nur Du! *grins

 

Äh...? Kompilieren oder Dekompilieren?
Ich würde vermuten, dass hier die Wurzel des Übels liegen könnte.
Eine Anwendung, die du nicht kompilieren kannst, hat grundlegende Fehler, die du beheben solltest. Ignorieren solcher Problem ist nicht wirklich eine Option, denn dein Code muss ja kompiliert werden, um ausgeführt werden zu können.

Mir ist aber völlig unklar, von welchen Änderungen du hier sprichst. (De-)Kompilieren sollte keine Änderungen an deinem Code vornehmen, sondern nur an dessen kompilierter Fassung, die aber in der Access/VBA-Oberfläche niemals irgendwo sichtbar ist.

 

Ich muss gestehen ich habe bisher noch nie einen lauffähigen Code kompiliert ... von daher treten jetzt ein paar Fehler beim kompilieren auf, die den Ablauf aber nicht beeinflussen. z.B:

Me.Text_ABC (fehlerhaft)
Me!Text_ABC (richtig)

Hier muss ich wohl erstmal ein paar Altlasten bereinigen bevor ich meinen Code kompilieren kann. Ich muss dazusagen dass ich von der Funktion bei VBA gar nichts wusste ... bei Delphi ist das Kompilieren nicht so versteckt.

 

Das ist absolut korrekt und nicht fehlerhaft !

Ich verwende nur die "." Version.
Dadurch steht mir IntelliSense zur Verfügung und kann so nur Objekte/Methoden/Eigenschaften auswählen, die auch zur Verfügung stehen.

Das hast du bei der ! Version nicht.
Das führt auch nicht zum Kompilierungsfehler.

 

Das ist übrigens eine bemerkenswerte Richtung des Programmierens. Nicht das Erreichen einer Funktionalität, sondern Codezeilen sind das Ziel? Wirst Du danach bezahlt?

 

\@fred
das kapier ich jetzt nicht. warum sagt mir VBA das es falsch ist, wenn es dann doch nicht falsch ist??? Ist "IntelliSense" ein PlugIn?

@ebs
darauf geh ich jetzt mal nicht ein, da die Codezeilen ja funktionieren

 

Dann solltest du uns zeigen was VBA "sagt".

QUELLE:Wikipedia

Allmählich werde ich neugierig auf deine 600 Zeilen Code ...
Sind die am Stück, oder alle Prozeduren im Modul zusammengenommen.

 

Hallo
Instaliere einmal die 3 Add-In von Thomas Möller
Für alle Access Versionen ab 2000
Willkommen bei Team-Moeller.de - Add-Ins:
TM-TablePerformance

Auch die weiteren Add-In von Thomas Möller
Sind sehr Empfeles wert !

Willkommen bei Team-Moeller.de - TM-RebuildDatabase
Hilft bei bestimten Fehle in der DB
z.b wenn die Datenbank beschädigt ist.
Kann Beschädigte Objekte retten !

Willkommen bei Team-Moeller.de - TM VBA-Inspector
hilft z.b einem sauberen VBACode zu erhalten

und lass sie laufen
mach die vorgschlagene Korekturen *Smilie

 

Code:

Es handelt sich hierbei um Textfelder. Die Fehlermeldung lautet: "Methode oder Datenobjekt nicht gefunden"
Der Code funktioniert sowohl mit einem Me.Text_ sowie mit Me!Text_ ... nur das kompilieren macht probleme.

Bei den 600 Zeilen Code verwende ich jede Menge Case of Schleifen , die man auch alle in einer verpacken könnte. Ich möchte mir aber die "Lesbarkeit" des Codes in der Entwicklungsphase nicht kaputt machen und dementsprechend kommen solche Dinge zur Stande:

Code:

 

Das ist absolut korrekt und nicht fehlerhaft !

Das kannst du beim besten Willen nicht wissen!
Dieser Code ist korrekt, wenn Me eine Instanz einer Klasse referenziert, die eine Property oder Methode Text_ABC besitzt.

Häufigster Kontext für solche Fehler ist es, wenn man ein Formular erstellt und mit einem solchen Ausdruck ein Feld in der Datenherkunft referenziert. Das funktioniert manchmal für eine Weile, solange Access diese Referenz auflösen kann. Eigentlich ist es aber nicht korrekt, weil das Feld aus der Datenherkunft eben nicht eine (permanente) Eigenschaft des Formulars ist.
Korrekt wäre:
Code:

anstelle von
Code: