none
Fehler 2501, seitdem neben Access 2003 Access 2010 installiert ist

    Frage

  • Hallo alle miteinander,

    da ein Großteil meiner Anwender noch Access 2003 anwenden wird, kann ich zunächst auf eine Entwicklung in Access 2003 nicht verzichten. Und da ich aus den verschiedensten Gründen wenig Lust verspüre, auf 2 unterschiedlichen Systemen zu entwickeln, habe ich mich trotz der Erwartung von Problemen dazu entschlossen, Access 2010 auf meinem PC zu installieren, auf dem Access 2003 und darunter eine Anwendung bereits von Beginn an fehlerfrei laufen.

    Seit der Installation von Access 2010, bekomme ich allerdings meine Anwendung unter Access 2003 nicht mehr zum Laufen, da schon das Laden des Eröffnungsformulars mit Fehler 2501 abbricht. Nachdem ich bereits einen ganzen Tag den Fehler selbst und auch im Internet nach Lösungen gesucht und keinen Lösungshinweis gefunden habe, hoffe ich, dass Ihr mir in dieser Angelegenheit einen helfenden Hinweis geben könnt und stelle zunächst meine bisherigen Erkenntnisse wie folgt zusammen:

    1. Installationsumgebung: Windows XP, SP3; Access 2003 Vs. 11.5614.8341; Access 2010 Vs. 14.0.4760.1000

    2. Der Fehler tritt beim Laden eines Formulars in folgender Zeile auf:

        DoCmd.OpenForm NameOfMainMenue, acNormal

    2.a. Der Fehler tritt auch auf, wenn ich den Formularnamen NameOfMainMenue ersetze durch seinen ordentlich zugewiesenen Inhalt ("HauptMenue").

    3. Diese Befehlszeile funktioniert seit Jahren fehlerfrei. Der Fehler tritt erst seit der Installation von Access 2010 in Access 2003, nicht aber in Access 2010 auf.

    4. Es fehlen keine Verweise. Allerdings ist nun die Access 14.0 Object Library MSACC.OLB registriert, die 11.0-Library ist nicht mehr vorhanden, auch die Datei MSACC.OLB selbst nicht und könnte auch nicht mehr referenziert werden, da sie gar nicht zur Auswahl steht und sich die Access 14.0 Object Library ohnehin nicht deaktivieren lässt.

    5. Im Formular selbst ist Cancel nicht auf TRUE gestellt.

    6. Als Datenquelle steht im Formular eine nicht gefilterte, mit einigen 100 Datensätzen gefüllte Tabelle zur Verfügung.

    7. Ein Debuggen bis zum ersten Befehl (InitializeMenuForm Me) in der Routine Form_Open des Formulars ist nicht möglich, da der Fehler bereits vorher auftritt.

    8. Ein Resume Next kommt nicht in Frage, da dann ja das Formular nicht aufgerufen wird.

    9. Das Kompilieren des Programmtextes verläuft fehlerfrei.

    10. Ein Entfernen, Löschen und Wiedereinfügen des gesamten Programmtextes im Modul bringt keine Änderung.

    11. Das Einfügen aller Tabellen, …, Module in eine neue Datenbank bringt keine Änderung.

    12. Der Fehler muss mit der Installation von Access 2010 zusammen hängen. Ich vermute, dass es am fehlenden Verweis auf die alte MSACC.OLB zusammen hängt.

    Ich erbitte dringend helfende Hinweise.

    Mit erwartungsvollen Grüßen

    Werner Mühlmann


    Werner Muehlmann

    Donnerstag, 12. April 2012 08:42

Alle Antworten

  • Hmm, ich weiss nicht wie ich es diplomatischer formulieren soll: Du solltest über deine Gründe ernsthaft nachdenken.

    Allein Aufgrund der Unterschiede der beiden Accessversionen bleibt dir eigenlich keine andere Möglichkeit als den kleinsten gemeinsamen Nenner (2003) zur Entwicklung zu nutzen und dann ggf. in 2010 die Anpassungen einfließen zu lassen.

    Du brauchst keine unterschiedliche Systeme: Der Arbeitsrechner bekommt das aktuelle Office 2010. Alle anderen Versionen laufen in jeweils einer eigenen virtuellen Machschine (VirtualPC 2007 oder was anderes).

    Donnerstag, 12. April 2012 08:59
    Moderator
  • Hallo Stefan,

    danke für Deine tröstenden Worte. Und sicher hast Du nicht ganz unrecht. Es gibt aber leider ausreichend Gründe, zunächst auf eine Parallelinstallation zu bestehen. Ich muss bspw. davon ausgehen, dass es auf Kundensystemen Schwierigkeiten geben wird, wenn ich mit einer A10-Runtime-Lösung komme und auf seinem System bereits A03 installiert ist. Dies muss ich zumindest erst einmal testen.

    Darüber hinaus gibt es weitere Gründe. Wenn es nur nach mir ginge, hätte ich A03 längst deinstalliert. Aber die Praxis....

    Nochmals danke. Vielleicht fällt Dir dennoch etwas anderes ein, bspw. den Konstrukt DoCmd.OpenForm durch etwas anderes zu ersetzen. Da muss es doch etwas geben, vielleicht RunCommand o.ä.?


    Werner Muehlmann

    Donnerstag, 12. April 2012 09:10
  • Hast du den Aufruf schon in der Direkt-Eingabe in der VBA-IDE getestet? Gib dort mal DoCmd.OpenForm "HauptMenue", acNormal ein..

    Ansonsten ist ein 2501 im Normalfall ein Cancel-Ereignis für die Aktion das Auftritt, während du diese Aktion aufrufst. Also, wie du schon gemerkt hast, wenn im Code ein Schließen des Formulars veranlasst wird.

    Hier ist im Grunde erstmal jedes Formularereignis interessant, welches beim Öffnen aufgerufen wird. Auch stellt sich die Frage sind ActiveX Komponenten auf dem betreffenden Formular vorhanden?

    Zuletzt: Ein Komprimieren und Reparieren wirkt manchmal Wunder. Manchmal..

    Donnerstag, 12. April 2012 09:27
    Moderator
  • Haargenau das selbe. Aber immerhin erfolgt die Fehlermeldung nun dreistufig:

    1. Meldung:

    Bei Visual Basic für Applikationen (VBA) ist ein Fehler während dem Zugriff auf eine Eigenschaft oder Methode aufgetreten. Es kann sich um eines der folgenden Probleme handeln:

    Ein Bezug fehlt.

    Informationen zur Wiederherstellung fehlender Verweise finden Sie in der Microsoft Knowledge Base im Artikel 283806.

    Ein Ausdruck ist falsch buchstabiert.

    Überprüfen Sie alle Ausdrücke, die in Ereigniseigenschaften verwendet wurden auf richtige Buchstabierung.

    Eine benutzerdefinierte Funktion wurde als Sub, oder als private Funktion in einem Modul deklariert.

    Ausdrücke können benutzerdefinierte Funktionen nur dann lösen, wenn die Funktion in einer der folgenden Formaten deklariert ist:

    Eine öffentliche Funktion in einem Modul

    Eine öffentliche oder private Funktion ein einem Codemodul des aktuellen Formulars oder Berichts

    Die Sicherheitsstufe ist in Access auf „Mittel“ oder „Hoch“ eingestellt, und die Microsoft Jet 4.0 SP8-Aktualisierung ist nicht installiert.

    Eine neuere Version von Jet 4.0 muß installiert sein, damit Access richtig funktioniert wenn die Sicherheit auf "Mittel" oder "Hoch" einstellt ist. Die aktuelle Version von Microsoft Jet können Sie von Windows Update downloaden.

    2. Meldung:

    Die Aktion OpenForm wurde abgebrochen.  ... in einem Dialogfeld auf 'Abbrechen’ geklickt.

    3. Meldung:

    Laufzeitfehler '2501':  Die Aktion OpenForm wurde abgebrochen. 

    Ich denke nach wie vor, dass die Feststellung "Ein Bezug fehlt." (1. Meldung) den richtigen Weg weist ... und, da wohl nicht erfüllbar, irgendwie umgangen werden müsste. Mir ist so, als wüsste ich, dass ein Formular auch anders als mit DoCmd.OpenForm NameOfMainMenue zu laden wäre. Mir fällt es bloß nicht mehr ein. Man ist eben nicht mehr 20...

    Auf jeden Fall liegt es nicht an der Sicherheitstufe, denn die steht bereits auf "Niedrig". Buchstabierung und private Funktion können auch außer Acht gelassen werden.

    Allerdings ist mir noch folgendes eingefallen:

    13. Der Fehler passiert auch, wenn ich das Formular direkt manuell aufrufe. (Wohl ein Argument, einen alternativen Aufruf des Formulars in VBA nicht mehr in Betracht zu ziehen.)

    14. Es gibt Formulare, wohl ausnahmslos ohne Klassenobjekte, die lassen sich nach wie vor öffnen, und wenn ich im zugehörigen Klassenobjekt alles auskommentiere, lässt sich dieses Formular "HauptMenue" auch wieder laden.

    Die am weitesten führende Entdeckung habe ich aber soeben gemacht:

    15. In einem anderen Programm, welches ebenfalls mit gleichen Startroutinen und diesem Formular identisch startet, läuft alles ohne Probleme.

    Die beiden letzten Punkte sprechen damit wohl auch gegen die MSACC.OLB, was mich ohnehin gewundert hätte.

    Damit bin ich jetzt aber erst recht ratlos. Ich untersuche jetzt, was ein anderer Programmierer als Routine zur Anwendungsinitialisierung eingeschoben (meiner Routine als Argument übergeben) hat, die ich während der Datenbankinitialisierung, vor dem beabsichtigten Aufruf des Formulars, ausführe, denn genau dieses wird in dem anderen Programm nicht gemacht.

    Der Vollständigkeit halber füge ich doch noch den vollständigen Code des Klassenobjekts HauptMenue zu, an dem es wohl, wegen Punkt 15, auch nicht liegen kann:

    Option Compare Database
    Option Explicit

    Private Sub Form_Activate()
        DoCmd.Maximize
    End Sub     ' Form_Activate()

    Private Sub Form_Current()
        NameMenuAndFillOptions Me
    End Sub     ' Form_Current

    Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
        SetAltShiftStrg KeyCode, Shift
    End Sub     ' Form_KeyDown

    Private Sub Form_KeyPress(KeyAscii As Integer)
        If IsKeyToMainOrPreviousMenu(KeyAscii) Then _
           RepointToPreviousOrMainMenu Me, KeyAscii, intShiftPressed  
    End Sub     ' Form_KeyPress

    Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
        ResetAltShiftStrg KeyCode
    End Sub     ' Form_KeyUp

    Private Sub Form_Open(Cancel As Integer)
        InitializeMenuForm Me
    End Sub

    Soweit ich mich entsinnen kann, tritt der Fehler (auch) dann auf, wenn entweder Form_Current() oder Form_Open nicht auskommentiert sind. Die restlichen Subs dürfen ohne Konsequenzen nicht auskommentiert bleiben.

    Wegen 15 wird es wohl aber in der modifizierten, vorausgehenden Datenbankinitialisierung liegen.


    Werner Muehlmann


    Donnerstag, 12. April 2012 11:34
  • So einfach war es dann wohl auch nicht.

    Zunächst:

    16. Komprimieren und Reparieren bringt keinen Effekt.

    Alsdann:

    Die Formulare sind in beiden Programmen identisch, die systemnahen Routinen ebenfalls. Da auch die Versionsnummern der, ohnehin ständig abgeglichenen, Initialisierungsroutinen identisch sind, habe ich mich darauf beschränkt, sicherheitshalber das Formular HauptMenue noch einmal zu laden. Aber

    17. Das Ersetzen des Formulars HauptMenue durch das identische Formular aus dem anderen Programm (siehe 15.) bringt ebenfalls keinen Effekt.

    Und, was das Kraut fett macht, auch

    18. Die Deaktivierung der Anwenderroutinen bei der Datenbankaktualisierung bringt leider keinen Effekt.

    Ich bin nun also so klug als wie zuvor und werde beide Programm schrittweise parallel debuggen.


    Werner Muehlmann

    Donnerstag, 12. April 2012 12:16
  • Was machen denn die Methoden in Current und Open?
    Donnerstag, 12. April 2012 12:27
    Moderator
  • WerMily wrote:
    > ...
    > 1. Installationsumgebung: Windows XP, SP3; Access 2003 Vs.
    > 11.5614.8341; Access 2010 Vs. 14.0.4760.1000
    >
    > 2. Der Fehler tritt beim Laden eines Formulars in folgender Zeile auf:
    >
    >    DoCmd.OpenForm NameOfMainMenue, acNormal
     
    Versuch ein decompile mit A03, s. http://www.donkarl.com?FAQ1.23
     
    > ...
    > 4. Es fehlen keine Verweise. Allerdings ist nun die Access 14.0
    > Object Library MSACC.OLB registriert, die 11.0-Library ist nicht mehr
    > vorhanden, auch die Datei MSACC.OLB selbst nicht und könnte auch
    > nicht mehr referenziert werden, da sie gar nicht zur Auswahl steht
    > und sich die Access 14.0 Object Library ohnehin nicht deaktivieren
    > lässt.
     
    Das ist ein bissel schräg. Normalerweise sollten beim Öffnen
    mit A03 die zu dieser Version passenden Bibliotheken vorhanden
    und automatisch von Access als Verweise genommen werden,
    genauso bei A10.
     
    Ist die MSACC.OLB im Office 2003-Ordner physisch noch
    vorhanden?
     
    --
    Servus
    Karl
    *********
    Access-FAQ: http://www.donkarl.com + SNEK
    SQL Server und .NET-Entwickler-Konferenz, Hannover 28./29.4.
     
     
     
    Donnerstag, 12. April 2012 13:05
  • Hallo Karl,

    auch Dir vielen Dank für's Mitdenken.

    Zunächst:

    Ich muss erst einmal Abstand nehmen und werde morgen bei Zeiten wieder ran gehen.

    Ein Decompile habe ich noch nicht geschafft, weil

    19. Ich hatte zwischenzeitlich bemerkt, dass in der funktionierenden Programmdatei zusätzliche Verweise eingetragen waren. Daher habe ich zunächst in der nicht funktionierenden Datei die Verweise angeglichen, in Inhalt und Reihenfolge. Hat auch nichts gebracht.

    20. Ich habe die funktionierende Datei genommen, alles gelöscht und alles aus der nicht funktionierenden importiert, ggf. Tabellenverweise neu eingerichtet. Hat auch nichts gebracht.

    Jetzt weiß ich aber auch nicht, warum eine funktioniert, die andere nicht mehr. Ein paralleles Debuggen habe ich leider auch noch nicht geschafft und habe mir das für morgen aufgehoben.

    Die MSACC.OLB ist im Office 2003-Ordner physisch nicht mehr vorhanden. Ich habe sie mir zwischenzeitlich besorgt und werde sie morgen reinkopieren.

    Hallo Stefan,

    die Methoden in Current und Open sind in beiden Dateien identisch. Ganz kurz, bevor ich den Verstand verliere:

    NameMenuAndFillOptions(frmMenu As Form)
    ' --> trägt Überschrift und Titel in das aktuelle Menü ein und
    ' --> beschriftet das aktuelle Menü frmMenu mit den in der Tabelle objMenu dafür hinterlegten Menü-
    '     punkten und
    ' --> maximiert das Menüfenster, soweit sich das Programm nicht im Testmodus befindet.

        With frmMenu
             .Ueberschrift = Nz(frmMenu.MenueBeschriftung, "")
             .Caption = ProjectIdentification() & "; Menü " & .Ueberschrift & "; " _
                      & CurrentUser & "; Startzeit " & Format(StartTime, "hh:mm") _
                      & IfString(PathToCurrentData <> "", "; " & PathToCurrentData)
             .Ueberschrift.ControlTipText = Left(Nz(.MenueQuickInfo, ""), 255)
             .Ueberschrift.StatusBarText = Replace(Nz(.MenueQuickInfo, ""), _
                                                   vbCrLf, " ", , , vbTextCompare)
        End With                                            ' frmMenu
        FillMenuOptions frmMenu

    ' InitializeMenuForm(frmMenu As Form, Optional FirstToHideUnterMenue As Integer = 0, _
                                  Optional LastToHideUnterMenue As Integer)

    ' initialisiert das Menüformular frmMenu und führt dazu folgende Aktionen aus:
    ' --> Menümitteilungen werden in das Menü eingetragen und
    ' --> falls die Nummer FirstToHideUnterMenue nicht mit 0 oder 1 übergeben wird, werden für die erste
    '     Menüebene alle Untermenüpunkte von der Nummer FirstToHideUnterMenue bis zur Nummer
    '     LastToHideUnterMenue deaktiviert (MenueState = FALSE), so dass diese Untermenüpunkte nicht
    '     angezeigt werden.

        Dim strSQL                  As String 
        Dim objMenuMessage          As Object   

        If FirstToHideUnterMenue > 1 Then _
           ResetLevel0MenueStateFor FirstToHideUnterMenue, LastToHideUnterMenue
        InitializeFormBasics frmMenu, OwnFormVisible, OwnFormViewAllowed, _
                             OwnKeyPreview, OwnNoMinMaxButtons, OwnNoScrollBars, _
                             "Hauptmenü; " & CurrentUser, "StartMenueLeiste", _
                             "StartMenueLeiste", OwnBasicForm, OwnColorMenueForms, _
                             OwnColorMenueForms, OwnNoDividingLines, _
                             OwnAdditionsNotAllowed, OwnDeletionsNotAllowed, _
                             OwnNoControlBox, OwnNoCloseButton, _
                             OwnDatasheetViewNotAllowed, OwnPivotTableViewNotAllowed, _
                             OwnPivotChartViewNotAllowed, OwnNoRecordSelectors, _
                             OwnNoNavigationButtons, OwnNoAutoResize, OwnNoAutoCenter, _
                             OwnNoWhatsThisButton
        ActualizePictureOfMenueLevel 0, frmMenu
        With frmMenu
            .Filter = fldNameUnterMenue & " = 0 AND MenueArgument = 'Standard' "
            .FilterOn = True
            strSQL = InstructionSelectWithDsFalseFrom("MenueMitteilungen")
            Set objMenuMessage = DBA.OpenRecordset(strSQL, dbOpenSnapshot)
            .MenueMitteilung = objMenuMessage.MenueMitteilung
            objMenuMessage.Close
            Set objMenuMessage = Nothing
            DoCmd.ShowToolbar "Formularansicht", acToolbarNo
        End With
        DoCmd.Maximize
        InitializeMenuButtonCoordinates frmMenu

    Möglicherweise kümmere ich mich morgen mal um DoCmd.ShowToolbar in InitializeMenuForm. Warum dann aber auch eine nicht auskommentierte Routine NameMenuAndFillOptions zum Fehler führt, bliebe mir dennoch schleierhaft.

    Vielleicht sollte man einfach nach Ostern nicht gleich wieder zu arbeiten anfangen....

    Bis morgen.

    Werner


    Werner Muehlmann

    Donnerstag, 12. April 2012 14:42
  • Hallo Werner,

    check doch einmal die Datenquelle Deines Formulares: m.E. liegt der Fehler genau dort.

    Gruß Stefan (Giorgio)

    Donnerstag, 12. April 2012 18:25
  • Am 12.04.2012 schrieb WerMily:

    da ein Großteil meiner Anwender noch Access 2003 anwenden wird, kann ich zunächst auf eine Entwicklung in Access 2003 nicht verzichten. Und da ich aus den verschiedensten Gründen wenig Lust verspüre, auf 2 unterschiedlichen Systemen zu entwickeln, habe ich mich trotz der Erwartung von Problemen dazu entschlossen, Access 2010 auf meinem PC zu installieren, auf dem Access 2003 und darunter eine Anwendung bereits von Beginn an fehlerfrei laufen.

    Solltest Du auf W7 Professional entwickeln, steht dir kostenlos eine virtuelle Maschine mit Windows XP zur Verfügung. XP Mode nennt sich
    das. http://www.microsoft.com/windows/virtual-pc/download.aspx Damit lässt sich wunderbar eine virtuelles XP betreiben. Darin O2003 installiert und schon hast Du ein zweites System zum entwickeln.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 13. April 2012 05:06
  • Einen wunderschönen guten Morgen Euch allen!

    Ich war nicht faul heute Morgen, aber:

    21. Die Tabelle, die als Datenherkunft ohne Filter im zu ladenden Formular verwendet wird, habe ich durch die Tabelle aus dem funktionierenden Programm ersetzt: ohne Erfolg. Womit Dein, Giorgios, Hinweis leider auch nicht weiter geholfen hat.

    22. Ein paralleles Debuggen des funktionierenden und nicht funktionierenden Programms erbringt bei identischem Programmverlauf identische Werte und Entscheidungen. Allerdings wird im nicht funktionierenden Programm das Formular gar nicht erst geladen und der Programmlauf mit Fehler 2501 abgebrochen, während im funktionierenden Programm das Formular fehlerfrei geladen wird und das Programm so normal durchstartet.

    23. Die inzwischen wieder in das Verzeichnis C:\Programme\Microsoft Office\OFFICE11 kopierte Datei MSACC.OLB von Access 2003 lässt sich nicht als Verweis aufnehmen, da ja eine Datei unter gleichem Namen bereits für Access 2010 als Verweis existiert, der sich auch nicht deaktivieren oder überschreiben lässt, da er ja, auch bei zurückgesetztem Programm, „zur  Zeit verwendet“ wird und „daher nicht entfernt werden“ kann.

    Hallo Karl,

    Decompile war eine gute Überlegung, aber, Du wirst es Dir sicher schon denken,:

    24. Decompile brachte auch keine Änderung.

    Warum zum ... wird das Formular nicht wenigstens so geladen, dass am frühest möglichen Debugg-Point gestoppt wird, bevor der Fehlerzustand eintritt?????

    Euch allen einen unkomplizierten Freitag, den 13., und ein bißchen Erleuchtung in dieser Angelegenheit

    wünscht Werner


    Werner Muehlmann

    Freitag, 13. April 2012 06:15
  • Hallo Winfried,

    danke für Deinen Hinweis. Ich werde ihn im Hinterkopf behalten. Da ich auf diesem Entwicklungs-PC aber noch XP habe, wäre zum gegenwärtigen Zeitpunkt der Aufwand der Umstellung zu groß. Ich hoffe immer noch auf eine schnellere Lösung, obwohl ich nun mittlerweile auch schon den dritten Tag arbeitsunfähig bin. Inzwischen will ich es aber auch wissen!!!


    Werner Muehlmann

    Freitag, 13. April 2012 06:31
  • Warum zum ... wird das Formular nicht wenigstens so geladen, dass am frühest möglichen Debugg-Point gestoppt wird, bevor der Fehlerzustand eintritt?????

    Hallo Werner & guten Morgen,
    ich will ja nicht stur/beharrlich wirken, aber genau das deutet darauf hin, daß beim Aufruf des Formulars (und dem Laden der zugrundeliegenden Datensätze) etwas schief läuft und insofern gar kein folgendes Ereignis, beginnend mit dem (on)open-Ereignis, mehr eintritt...

    ...kann man davon ausgehen, daß

    1.) Du die Tabelle in dieser Applikation (ggf. aus der Entwurfsansicht des Formulars) selbst öffnen und Anzeigen kannst...?

    2.) Ggf. benutzerdefinierte Datentypen, Verknüpfungen etc. in dieser und der lauffähigen Applikation eindeutig deiniert sind...?

    Hast Du die Tabelle 'mal als Abfrage/Sql-String im RecordSource eingesetzt...?

    Welche Fehlermeldung kommt bei manuellem Aufruf des Formulars...?

    Gruß Giorgio

    Freitag, 13. April 2012 08:20
  • Hallo Giorgio,

    ich fang' mal hinten an:

    Beim manuellen Aufruf kommt die selbe Fehlermeldung.

    Der Ersatz der Tabelle MenueEintraege im RecordSource

    durch SELECT MenueEintraege.* FROM MenueEintraege;

    bringt keine Änderung.

    Mit 2. kann ich leider nichts anfangen. Das müsstest Du konkretisieren.

    Die Tabelle selbst lässt sich selbstverständlich öffnen. Mit der bzw. so einer arbeite ich auch schon seit 15 Jahren oder länger und, wegen der Menüerweiterungen, beinahe wöchentlich. Außerdem hatte ich sie ja bereits ersetzt (siehe 21) durch die aus dem funktionierenden Programm, die die selbe Struktur und einen großen Teil der selben Einträge hat und mit der ich auch schon seit 15 Jahren oder länger und, wegen der Menüerweiterungen, beinahe wöchentlich arbeite.

    ??????


    Werner Muehlmann

    Freitag, 13. April 2012 09:30
  • Hallo Werner,

    und was passiert, wenn Du das Formular ungebunden, also ohne Datequelle, öffnest...?

    Giorgio

    Freitag, 13. April 2012 09:47
  • Dasselbe. Eigentlich lässt sich gar kein Formular mehr laden.

    Für alle, die es noch interessiert und denen es nicht zu viel wird, füge ich mal im folgenden meine letzte Information an Herrn Jonathan Best vom Microsoft Education Support Centre ein, der mir ebenfalls per E-Mail Tipps gegeben hat und hoffentlich nicht böse ist, wenn ich die letzte Antwort nun hier veröffentliche. Ich denke aber, dass es für alle interessant ist:

    Sehr geehrter Herr Best,

    vielen Dank zunächst für Ihre Rückmeldung. Inzwischen war ich bereits weiter. Der neue Stand war folgender:

     

    (1 bis 24, s.o.)

     

    Ich werde jetzt dennoch Ihren Hinweisen noch einmal folgen. Die Resultate sind/waren diese:

    Bezüglich der Referenzen hatte ich unter 19. schon etwas geschrieben. Allerdings bin ich mir nicht 100%ig sicher, da in dem kleinen und nicht vergößerbaren Verweisfenster nicht jede Referenz komplett dargestellt wird und eingesehen werden kann. Aber ich denke schon, dass die Verweise mit denen des funktionierenden Programms übereinstimmen (siehe auch 15 und 20).

    Sicherheitshalber habe ich MSACC.OLB mit

    regsvr32 "C:\Programme\Microsoft Office\OFFICE11\MSACC.OLB"

    noch einmal registriert. Dass der Hinweis

           ... lässt sich nicht registrieren ...

    kommt, nehme ich nicht ganz so tragisch, da er selbsterklärend ist. Ich habe es trotzdem nochmals versucht mit

    regsvr32 -u "C:\Programme\Microsoft Office\OFFICE11\MSACC.OLB"

    regsvr32 "C:\Programme\Microsoft Office\OFFICE11\MSACC.OLB"

    Wegen 23. hatte ich aber ohnehin nichts erwartet.

     

    25. ADO hatte ich entfernt, weil, zumindest im unter 22. angegebenen und debuggten Programmteil, nicht verwendet und auch vorübergehend die Reihenfolge von ADO/DAO getauscht. Ohne Erfolg. Als DAO ist übrigens 3.6 referenziert.

    26. Die Verweise habe ich auf das Allernotwendigste reduziert: Visual Basic For Applications und Microsoft Access 14.0 Object Library (beide Standard und ohnehin nicht änderbar), Microsoft DAO 3.6 Object Library, Microsoft Office 11.0 Object Library, Microsoft ActiveX Data Objects 2.5 Library, Microsoft Excel 10.0 Object Library und Microsoft Visual Basic for Applications Extensibility 5.3. Ergebnis: ohne Änderung.

    zu [2]:

    Im Normalfall enthält das Klassenobjekt des Formulars folgenden Code, in dem der Übersichtlichkeit wegen der Kommentar entfernt wurde:

     

    Option Compare Database
    Option Explicit

     

    Private Sub Form_Activate()
        DoCmd.Maximize 
    End Sub     ' Form_Activate()

     

    Private Sub Form_Current()
        NameMenuAndFillOptions Me
    End Sub     ' Form_Current

     

    Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
        SetAltShiftStrg KeyCode, Shift
    End Sub     ' Form_KeyDown

     

    Private Sub Form_KeyPress(KeyAscii As Integer)
        If IsKeyToMainOrPreviousMenu(KeyAscii) Then _
           RepointToPreviousOrMainMenu Me, KeyAscii, intShiftPressed   
    End Sub     ' Form_KeyPress

     

    Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
        ResetAltShiftStrg KeyCode
    End Sub     ' Form_KeyUp

     

    Private Sub Form_Open(Cancel As Integer)
        InitializeMenuForm Me
    End Sub

    Was mich verwundert ist, dass ich beim Debuggen nicht einmal bis zur Routine Form_Open und darin zur Codezeile InitializeMenuForm Me, komme, obwohl eine gültige, nicht gefilterte und gefüllte Datenherkunft, als Tabelle oder als SQL-Anweisung SELECT MenueEintraege.* FROM MenueEintraege;, eingetragen ist, existiert und geöffnet werden kann. Der Fehler wird bereits vor diesem Haltepunkt gemeldet.

    Wenn ich nur die Codezeilen in den Routinen Form_Open (InitializeMenuForm Me) und Form_Current (NameMenuAndFillOptions Me) auskommentiere, tritt der Fehler abenfalls auf. Kommentiere ich den gesamten Code im Klassenobjekt aus, tritt der Fehler nicht auf und das Formular wird geladen. Wenn ich dann sukzessive den Kommentar für die Module Form_KeyDown, Form_KeyPress, Form_KeyUp und Form_Activate, jeweils gesondert, erst Kopf- und Fußzeilen, dann den Routinenkörper, entferne, tritt der Fehler ebenfalls nicht auf und das Formular wird geladen. 

    Allerdings bricht das Programm beim Programmlauf in wenigstens der Hälfte der Fälle, jeweils nach dem Entfernen des Kommentars für eine Routine in der oben genannten Reihenfolge, mit der Fehlermeldung

             Microsoft Office Access hat ein Problem festgestellt und muss beendet werden. ... 

    total zusammen. Nach Reaparatur und Komprimieren der Anwendung und Entfernen des nächsten Kommentars oder auch ohne irgendwelche Codeänderungen kann dann das selbe wieder passieren ... oder auch nicht.

    Wenn ich dann von der Kopf- und Fußzeile der Routine Form_Current den Kommentar entferne, wird der anschließende Programmlauf dann mit dem Laufzeitfehler 2004 (Nicht genügend Speicherplatz, um diese Operation durchzuführen. Schließen Sie Anwendungen, die Sie nicht benötigen, und versuchen Sie es noch einmal.) unterbrochen:

    Der verbleibende Code im Klassenobjekt sieht dann, wieder ohne Kommentar, so aus:

    Option Compare Database
    Option Explicit

    Private Sub Form_Activate()
    '    DoCmd.Maximize
    End Sub     ' Form_Activate()

     

    Private Sub Form_Current()
    '    NameMenuAndFillOptions Me
    End Sub     ' Form_Current

     

    Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
        SetAltShiftStrg KeyCode, Shift
    End Sub     ' Form_KeyDown

     

    Private Sub Form_KeyPress(KeyAscii As Integer)
        If IsKeyToMainOrPreviousMenu(KeyAscii) Then _
           RepointToPreviousOrMainMenu Me, KeyAscii, intShiftPressed    End Sub     ' Form_KeyPress

     

    Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
        ResetAltShiftStrg KeyCode
    End Sub     ' Form_KeyUp

     

    'Private Sub Form_Open(Cancel As Integer)
    ''    InitializeMenuForm Me
    'End Sub

    Danach kann ich nicht einmal mehr eine einfache Tabelle öffnen und muss das Programm neu starten, wobei das Formular zwar geladen wird, dabei aber der Fehler

           "Sie haben als Einstellung der Ereigniseigenschaft den Ausdruck Bei Taste Auf eingegeben. ... "

    auftritt. Nachdem ich diesen quittiert habe, kann ich das Formular wieder schließen und weiter testen.

    Der Fehler tritt übrigens nicht immer auf, wenn ich im geladenen Programm das Formular wiederholt starte. Allerdings bricht das Programm öfter mit dem Fehler "Microsoft Office Access hat ein Problem festgestellt und muss beendet werden." (s.o.) ab, so dass ich nicht sicher sagen kann, ob der Fehler nur bei jedem 2. Mal auftritt, was durch einen Wechsel der internen Einstellungen im Programm verursacht und dann auch verstanden werden kann.

    Wegen dem Fehlerhinweis "Bei Taste Auf " habe ich die Routine Form_KeyUp zunächst total und bleibend auskommentiert.

    Der Fehlerhinweis "Bei Taste Auf " tritt dann nicht mehr auf, nach dem dritten oder vierten Test (geladenes Programm zurück setzen und erneut starten, um das Formular laden zu lassen), folgt dann aber wieder der Laufzeitfehler 2004 ("Nicht genügend Speicherplatz...", s.o.) und ich muss das Programm erneut starten, um weiter testen zu können.

    Die unzähligen Zwischenschritte will ich weglassen. Zuletzt habe ich folgenden Code im Klassenobjekt getestet:

     

    Option Compare Database
    Option Explicit

    'Private Sub Form_Activate()
    ''    DoCmd.Maximize

    'End Sub     ' Form_Activate()

     

    Private Sub Form_Current()
        NameMenuAndFillOptions Me
    End Sub     ' Form_Current

     

    'Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    '    SetAltShiftStrg KeyCode, Shift
    'End Sub     ' Form_KeyDown

     

    'Private Sub Form_KeyPress(KeyAscii As Integer)
    '    If IsKeyToMainOrPreviousMenu(KeyAscii) Then _
    '       RepointToPreviousOrMainMenu Me, KeyAscii, intShiftPressed  

    'End Sub     ' Form_KeyPress

     

    'Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
    '    ResetAltShiftStrg KeyCode
    'End Sub     ' Form_KeyUp
    '
    Private Sub Form_Open(Cancel As Integer)
    '    InitializeMenuForm Me
        Debug.Print Me.Name
    End Sub

     

    Die Wegnahme des Kommentars in der Routine Form_Current bleibt ohne Konsequenzen, die Aktivierung des Formulars zwar auch, kann aber andere Ursachen haben. Wichtig ist, dass sich das Formular nicht einmal mit einem solchen Befehl wie "Debug.Print Me.Name" öffnen lässt.

    Ich gelange also zu dem Eindruck, dass es das Formular selbst ist. Allerdings lässt sich auch kein anderes der vorhandenen Formulare laden. Alle brechen mit Fehler 2501 ab, egal ob mit integrierter Initialisierungsroutine (InitializeMenuForm, so.o) oder ohne. Lediglich ein zum Test generiertes Formular ohne Klassenobjekt  wird problemlos geladen.

    Möglicherweise liegt es an der Größe des Programms. 2 Programme mit weniger Programmcode laufen problemlos.

    Von den vergleichbaren Programmen umfasst das nicht funktionierende Programm eine Größe von 49.840 KB, nach Decompile 38.608 KB, das funktionierende 82.400 KB, wobei das funktionierende Tabellen aber wesentlich weniger Code, Formulare und Berichte und das nicht funktionierende hauptsächlich Tabellenverweise aber wesentlich mehr Programmzeilen (einige hunderttausend) enthält.

    Allerdings ist nach einer Entfernung verzichtbaren Codes, Decompile und Komprimieren, bei einer Dateigröße von 35.292 KB, der Reduzierung des Programmcodes damit sicher auf unter 90 %, der Fehler dennoch nicht verschwunden.

    Ich bitte also nochmals dringend um Ihre Hilfe.


    Werner Muehlmann

    Freitag, 13. April 2012 12:12
  • Okay, klingt nach fieser Code Corruption:

    1. Erzeuge eine neue, leere Datenbank. Setzte die Optionen und benötigten Referenzen.
    2. Importiere der Reihe nach alle Objekte nach Type (Tabellen, dann Abfragen, dann Formulare, ...)
    3. Wenn alles ohne Fehlermeldung importiert worden ist, kompiliere die Datenbank in der VBA IDE, ohne vorher ein Objekt in Access geöffnet zu haben.
    4. Wenn das ohne Fehler lief, dann die Datenbank komprimieren und reparieren, sofern es nicht bei dir in den Optionen schon eingestellt ist.
    5. Schließen, neu öffnen, testen.

    Wenn es jetz immer noch nicht geht: Dann hilft nur noch SaveAsText und LoadFromText.

    D.h. im Direktfenster foglgendes ausführen, zwischen dem Speichern und Laden das Formular löschen, Datenbank komprimieren und reparieren:

    Application.SaveAsText acForm, "MyForm", "C:\Temp\MyForm.txt" 
    Application.LoadFromText acForm, "MyForm","C:\Temp\MyForm.txt" 
    

    Freitag, 13. April 2012 13:14
    Moderator
  • Hallo Stefan,

    ich habe es (auch) geahnt, aber als guter Programmierer sucht man ja zunächst den Fehler direkt bei sich... Allerdings habe ich mich auch heute wieder reinverbissen und sehe im Moment wieder nur ein Brett vorm Kopf, so dass ich nach dem Wochenende lechze, in der Hoffnung, mit Abstand wieder klarer zu sehen.

    Gib mir in dieser Situation also noch den Tipp: Was meinst Du mit "kompiliere die Datenbank in der VBA IDE", noch kürzer: "IDE"???

    Ich weiß nämlich heute gar nichts mehr.

    Übrigens, Import in eine völlig neue Datenbank habe ich also tatsächlich in diesem Zusammenhang noch nicht gemacht. Nach den Erfahrungen der letzten Tage sind meine Hoffnungen allerdings im Minusbereich. Wir werden sehen.


    Werner Muehlmann

    Freitag, 13. April 2012 13:29
  • Gib mir in dieser Situation also noch den Tipp: Was meinst Du mit "kompiliere die Datenbank in der VBA IDE", noch kürzer: "IDE"???

    Hallo Werner,

    damit ist das VBA-Fenster (dort wo du mit VBA programmierst) gemeint.

    Falls du das Direktfenster (Direktbereich) nicht offen hast, dann über Menü 'Ansicht' öffnen.

    Servus

    Stefan


    Viele Grüße Stefan

    Freitag, 13. April 2012 14:03
  • Danke, Stefan.

    Der Begriff war/ist mir nicht geläufig. Was bedeutet er denn im Volltext?


    Werner Muehlmann

    Freitag, 13. April 2012 15:19
  • Am 13.04.2012 schrieb WerMily:

    danke für Deinen Hinweis. Ich werde ihn im Hinterkopf behalten. Da ich auf diesem Entwicklungs-PC aber noch XP habe, wäre zum gegenwärtigen Zeitpunkt der Aufwand der Umstellung zu groß. Ich hoffe immer noch auf eine schnellere Lösung, obwohl ich nun mittlerweile auch schon den dritten Tag arbeitsunfähig bin. Inzwischen will ich es aber auch wissen!!!

    Du kannst natürlich auch auf einem XP virtualisieren. VirtualPC2007 SP irgendwas ist Freeware und kann für solche Zwecke benutzt werden.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter


    Freitag, 13. April 2012 16:05
  • Am 13.04.2012 schrieb WerMily:

    Danke, Stefan.

    Der Begriff war/ist mir nicht geläufig. Was bedeutet er denn im Volltext?

    Was genau ist dir nicht geläufig? VBA? IDE? ALT + F11 drücken, schon bist Du in der VBA-IDE. Dort kannst Du die Anwendung kompilieren.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter


    Freitag, 13. April 2012 16:09
  • IDE?

    Was bedeutet das als Volltext? So ein Brett kann ich doch gar nicht vorm Kopf haben. Ich kann mich nicht erinnern, den Begriff schon einmal irgendwo gehört/gelesen zu haben.


    Werner Muehlmann

    Freitag, 13. April 2012 17:54
  • Am 13.04.2012 schrieb WerMily:

    IDE?

    Was bedeutet das als Volltext? So ein Brett kann ich doch gar nicht vorm Kopf haben. Ich kann mich nicht erinnern, den Begriff schon einmal irgendwo gehört/gelesen zu haben.

    Hier gibts die Antwort:
    http://de.wikipedia.org/wiki/Integrierte_Entwicklungsumgebung

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 13. April 2012 17:59
  • Hallo Winfried und danke. Man lernt eben nie aus. Jetzt weiß ich endlich, womit ich die letzten 20 Jahre gearbeitet habe. Und obwohl ich das bisher nicht wusste, hat es dennoch irgendwie funktioniert. Bis auf jetzt. Denn mein Problem ist damit auch nicht gelöst. Aber das mag am Wochenende auch ruhen. Denn die Zeiten als zwanghafter Programmierer habe ich, Gott sei es gedankt, hinter mir.

    Euch allen ein erholsames Wochenende!


    Werner Muehlmann

    Samstag, 14. April 2012 08:45
    1. Erzeuge eine neue, leere Datenbank
    2. ...
    3. ...
    4. ...
    5. Schließen, neu öffnen, testen.

    Wenn es jetz immer noch nicht geht: Dann hilft nur noch SaveAsText und LoadFromText.

    Okay, ich habe beschlossen, dass 4 lange Arbeitstage, 1 doch nicht ganz fern gehaltenes Wochenende und ein paar schlaflose Nächte reichen müssen. Die Entscheidung fiel mir nicht leicht. Nachdem aber o.a. 1. bis 4. weder für die nicht funktionierende noch für die funktionierende Datenbank noch für den Rest der auf das absolute Minimum reduzierten funktionierenden Datenbank (!!!) dazu geführt haben, dass der Fehler 2501 beim Laden des Formulars nicht (mehr) auftritt und meine Hoffnungen diesbezüglich ohnehin im Minusbereich lagen (siehe mein Beitrag vom Freitag, 13. April 2012 13:29), halte ich es für gerechtfertigt, mich mit einem 2. Arbeitsplatz zu belasten. A10 wird auf meinem Standardarbeitsplatz laufen und A03 auf einem zusätzlichen Arbeitsplatz für die Vergangenheit zur Verfügung stehen. Dies ist zwar nicht meine Traumlösung. Von Träumen in solchen Angelegenheiten hatte ich mich aber ohnehin schon vor Jahren verabschiedet.

    SaveAsText habe ich mir geschenkt. Im Laufe der Jahre entwickelt man als Programmierer so ein Bauchgefühl für das was klappt und das was sinnlos ist. Nachdem mir dieses Gefühl bereits nach dem ersten sinnlosen Tag Ausrufezeichen gesendet hat, war ich nun bereit, ihm zu folgen, und nicht noch weitere Zeit zu verschwenden.

    Allen vielen Dank, die bisher mitgedacht haben und bereit waren, dafür to waste time. Ich hoffe, ich kann es mal wieder gut machen, zumindest aber beim nächsten Mal ein, in akzeptablem Zeitumfang, lösbares Problem präsentieren.


    Werner Muehlmann


    Montag, 16. April 2012 14:46
  • Leider mussten wir in unserer Anwendung sehr ähnliches feststellen.

    Wenn wir mde Daten kompilieren auf Systemen auf denen mehr als eine Access Variante installiert ist, kommt es zu mehr als merkwürdigen Fehlern.

    Seitdem wir für jede Office(Access) Version 2002(XP)/2003/2007/2010 ein eigenes System aufgesetzt haben (eigene Festplatte (VM) reicht ja) sind viele unerklärliche Abstürze und Probleme behoben wurden.

    Unser schwerwiegenster gefundener Bug war, dass Codezeilen nachweislich nicht ausgeführt wurden. Erst bei mehrmaligem aufrufen der selben Funktion, wurde immer mal eine Codezeile mehr ausgeführt, bis alles durchlief.

    Soll heißen, ein System ein Access alles andere kann man fast vergessen. (Access 2003 + 2007 vertragen sich scheinbar)

    Decompile oder kompletter reimport aller Objekte hilft immer bei merkwürdigen Kompilierungsfehlern! (OASIS-SVN ist da zu empfehlen)

    PS: (mde's von Access 2007 und Microsoft Office Professinal Access 2007 sind nicht kompatibel, das gleiche mit SP1/2/3's ; Enterprise usw. Versionen)

    Montag, 23. April 2012 13:55