Access-o-Mania

Hallo zusammen,
bei mir ist Access jetzt 2 mal kurz nacheinander ausgestiegen. Mit was arbeitet man am besten weiter mit der von Access erstellten Backup Datei oder  mit der Original mdb ? Einen Grund für das Aussteigen konnte ich nicht erkennen.

Gruß Dieter

Hallo,

die Datei mit dem Anhang '_Backup' stellt die Version dar, die vor dem Crash aktiv war.
Die ohne Anhang ist jene Datei, die fehlerhaft ist.

Wahrscheinlich hast du an irgend einem Code etwas geändert, das dann einen kapitalen Fehler ausgelöst hat.
In der '_Backup' sollte diese Änderung (noch) nicht vorhanden sein.

Überprüfe das mal - dann kannst du die ohne Anhang löschen und die '_Backup' auf den Originalnamen umbenennen.

HTH
Peter

Hallo Peter,
ich musste ein paar Tage weg deshalb erst jetzt die Antwort.

Ok das habe ich verstanden, ich habe jetzt allerdings mit der Original mdb weitergemacht. Beim nächsten mal werden ich mit dem Backup weitermachen, wenn dies sicherer ist.

Inzwischen weis ich was passiert ist:
Bei einer Fehlersuche muss Access einen Fehler bei einer Feldbezeichnung auf die ich per VBA Zugriff nicht erkannt haben und hat erstmal ohne zu murren damit weitergearbeitet. Dann kams es irgendwie zu diesem Crash und Acces stürtze ohne Vorwanrung ab. Danach lief die Original mdb wieder bis es wieder zu Absturtz kam bei Routinen die ich schon Wochen zuvor geschrieben und bis dato nichts mehr geändert hatte. Ich habe mir nun folgendermaßen geholfen. Neue Mdb erstellt alle Module Formulare Tabellen importiert, danach Kompiliert und siehe da bei ersten Test der Routine die ich zu dem Zeitpunkt des Absturzes testen wollte erkannte er die falsche Feldbezeichnung und gab den entsprechenden Fehler aus. Zeit dem läuft die Datenbank wieder ohne Probleme. Scheinbar hat Access manchmal Probleme mit den Feldnamen in den Tabellen, wenn auf diese per VBA zugegriffen wird, da er die Feldnamen zum Zeitpunkt der Kompilierung nicht kennt weil die Tabellen nicht geöffnet ist.

Gruß Dieter

Hallo Dieter,

Zitat... einen Fehler bei einer Feldbezeichnung auf die ich per VBA Zugriff nicht erkannt haben ...

Dazu muss ich sagen, dass ich mir das so nicht ganz vorstellen kann.
Ich glaube viel eher, dass die Kompilierung schon durchgeführt war, BEVOR die oder eine Änderung an einem Feldnamen erfolgt ist.
Ähnliches passiert auch immer wieder, wenn erstmalig Codes gelaufen sind und dann Formularfelder umbenannt werden - meist völlig unbewußt.

ZitatScheinbar hat Access manchmal Probleme mit den Feldnamen in den Tabellen

Diese Art Problematik wäre ein fataler Fehler in der Grundsubstanz, der Access eigentlich unbrauchbar machen würde...  :'(
...schließe ich jedoch aus!

Hallo Database,
sorry dass ich dir erst jetzt antworte.

Zitat
Ich glaube viel eher, dass die Kompilierung schon durchgeführt war, BEVOR die oder eine Änderung an einem Feldnamen erfolgt ist.
Ähnliches passiert auch immer wieder, wenn erstmalig Codes gelaufen sind und dann Formularfelder umbenannt werden - meist völlig unbewußt.

Das was du schreibst kann natürlich stimmen, da ich ständig in der Datenbank arbeite kann das natürlich passiert sein. Was auf jeden fall passiert ist, dass sich Access ohne Fehlermeldung verabschiedet hat und ein Backup erstellt hat. Und dies geschah immer mal wieder, auch bei Routinen die schon seit Wochen liefen und bei denen ich mit Sicherheit nichts mehr verändert habe. Es kommt scheinbar bei den falschen oder umbenannten Feldnamen immer wieder zu Fehlern, wenn die Kompilierung schon durchgeführt wurde. Letzens hatte Fehler (ich glaube) 41 falscher Zugriff auf Dll, auch hier war ein falscher Feldname im VBA-Code Schuld für diese Fehlermeldung. Bei Formularfeldern hat Acces auch Probleme überhaupt wenn man Zahlen an die Endungen der Namen schreibt oder die Schreibweise in GroßKlein ändert (z.B. test in Test), da kann es passieren, dass Access den Namen überhaupt nicht abändert.Was ich in Access vermisse ist, dass man die Datenbank komplett neu durchkompilieren kann, den scheinbar kompiliert Access nur den Teil, der neu eingegeben bzw geändert wurde.

Frohe Weihnnachten und Gruß
Dieter

Hallo,

danke, auch dir schöne Festtage!

Zitat...Schreibweise in GroßKlein ändert (z.B. test in Test), ...

Die Sache mit der Benamsung ist eine Never-Ending-Story, KEINE reservierten Wörter, KEINE Sonerzeichen, KEINE Umlaute und Leerzeichen in Feldnamen, Variablen-, Tabellen- und Objektbezeichungen verwenden.
Die Benennung von Formularfeldern mit Zahlen, egal ob vorne oder hinten am Namen macht meiner persönliche Einschätzung nach keinen Sinn - obwohl Access von sich aus Felder, die nachträglich in Formulare eingebracht werden, mit Text1 .... nummeriert einfügt. Ist m.E. eine Unart aber zum Zeitpunkt des Einfügens hat Access keine bessere Information über Inhalt oder Funktion des Feldes.
Wobei ich bis dato noch NIE feststellen konnte, dass Access mit der eigenen Namensgebungsart Probleme hätte.
Dann scheinen aus deiner Schilderung heraus auch Probleme mit dem Datenmodell irgendwie ins Spiel zu kommen.

Zitat... da kann es passieren, dass Access den Namen überhaupt nicht abändert ...

Da es sich bei VBA-Code und Tabellen um 2 grundverschiedene Datenbankobjekte handelt muss beim Erstellen von Code darauf geachtet werden,
dass Feldnamen, die im Code eingebracht werde, dem entsprechen, wie sie in der Tabelle benannt wurden.
Ich kenne keine Entwicklungsumgebung und keine Programmiersprache, die SELBSSTÄNDIG auf die Änderung von Feldnamen durch den Entwickler (zumindest mir ist das nicht anders bekannt) reagiert!
Dass es in dem Fall dann zu ordentlichen Probleme kommt ist nicht weites verwunderlich.

Zu Groß-/Kleinschreibung: Mir wäre nicht bekannt, dass VBA so wie z.B. Java oder C# ausser bei API-Geschichten case sensitiv reagiert.

Zitat...dass sich Access ohne Fehlermeldung verabschiedet hat...

Wie schon erwähnt - ein kapitaler Fehler, der u.U. die gesamte DB ruinieren KÖNNTE wird auf die Art und Weise 'lahmgelegt'.
Eine ausgeklügelte Fehlerbehandlung kann manchmal viel Ärger und Problem sparen, jedoch mit Sicherheit nicht alles abfangen und regeln.

Wobei ich dann auch noch dringendst davon abraten MUSS, Tabellenfelder oder Tabellenkonstrukte im Zuge von Formularentwicklungen zu ändern!
Die nächsten Probleme tauchen dann hierbei gleich mal bei Datenherkünften, Abfragen und / oder SQL-Codes auf.
Es kann und darf nicht sein, dass die Gestaltung des Formulars auf die Konstruktion einer Tabelle Einfluß nimmt - egal mit welchem Entwicklungswerkzeug auf eine Datenbank zugearbeitet wird!

Wenn du 'alte' Prozeduren als Fehlerquellen ansprichst - auch hier kann ich nur vermuten, dass es sich innerhelb des VBA-Projekts um einen 'hausgemachten' Fehler handelt,
der dann in solchen Routinen hervorbricht, hervorgerufen durch Kapitalabstürze, nicht ordnungsgemäße Programmbeendigungen etc aus oben angesprochenen Fehlerquellen.

Die von dir verwendete Methode mit der neuen DB und dem Importieren der alten Objekte ist ein durchaus gangbarer und bekannter Weg 'zerschossene' Datenbankdateien wieder funktionstüchtig zu machen.
Vorsicht aber auch hier - das gelingt oft aber nicht immer!

In diesem Sinne - viel Erfolg weiterhin!

Hallo Optiplex Hallo Peter

Ich kan das eigendlich nur Optiplex beipflichten. Habe Win XP und Office 2003, dort habe ich es schon mehrfach gehabt das nach dem die Datenbank Funktion reparieren ausgeführt habe, sich ohne das eine Tabelle geöffnet war, nach ausführen der Funktion Autowerte von Interger auf Zufall geändert wurden. Habe eine neue Datenbank erstellt auch dort ist es aufgetaucht. Zum zweiten ist ein Formular nicht in der Entwurfsansicht geöffnet und es wird an dem VBA Code für das Formular gearbeitet führt das bei mir zum extremen aufblähen der Datenbank oder zum Absturz mit der anschließenden Meldung zu wenig Speicher. Die Datenbank ist dann für die Tonne und arbeite dann an der Sicherung weiter. Alle Update Win sind installiert da kann es eigendlich auch nicht dran liegen.
Das geschieht auf zwei Rechner, wo mir niemand eine erklärung für geben kann.

Gruß Stefan

Hallo,

ich hoffe, das ist KEIN Weihnachtswunder -

Zitatnach ausführen der Funktion Autowerte von Interger auf Zufall geändert wurden

was meinst du mit  -  von Integer auf Zufall  -  entschuldige bitte aber das kenn ich nicht.

Ich habe noch keine Datenbank gesehen, in der Autowerte nach dem Zufallsprinzip vergeben werden  ;D
EDIT: Ich habe noch keine Datenbank gesehen, in der Autowerte nach dem Zufallsprinzip vergeben werden ohne selbst die Einstellungen hierzu zu verändern ...
Das musste ich berichtigen - war wohl ein wenig zu schnell beim Schreiben .  ;)

ZitatZum zweiten ist ein Formular nicht in der Entwurfsansicht geöffnet und es wird an dem VBA Code für das Formular gearbeitet

Das kommt dann irgendwie in der Richtung 'Radwechsel bei fahrendem Auto' gleich - sollte man NICHT tun  ;)

Zu den Geschichten mit dem Speichermangel gibt diverse Hinweise von MS selbst und auch von anderer Seite - so z.B.
http://www.donkarl.com?FAQ7.13 (http://www.donkarl.com?FAQ7.13) + den darin zitierten weiterführenden Links

Schönen Feiertag !

Hallo Database,
hör doch auf immer die Fehler auf das Datenbankmodel zu schieben, oder die Fehler als Hausgemacht abzutun, wenn ich hergehe und einem Textfeld einen Namen gebe dann hat das Access normalerweise zu akzeptieren egal ob ich das nun Groß oder Kleinschreibe, das hat auch was mit der Textübersichtlichkeit zu tun, wenn ich vorne was ändere  muss es in VBA übernommen werden egal ob es nun ein anderes Objekt ist oder nicht, wenn ich ein Feld in einer Tabelle hinzufüge dann hat dieses Feld auch in VBA zu erscheinen und nicht erst wenn ich im Formular die Tabelle neu setzte. Die Benamsung mit Zahlen macht dann einen Sinn wenn ich mehrere Felder auf einmal ändern möchte.(Kann man natürlich auch über die Tag-Eigenschaft machen.)

Ich habe z.Zeit wieder mal einen tollen Laufzeitfehler und zwar Nr 49 -> Falsche DLL Aufrufkonvention obwohl ich keinen einzigen API Aufruf in meinem VBA-Code habe. Ich weis wirklich nicht wie dieser Fehler zustande kommt, ich habe den Code schon rauf und runter durchsucht einen Fehler konnte ich diesmal nicht entdecken. Auch habe ich weder Felder in Formularen noch Felder in Tabellen umbenennt oder hinzugefügt. Weist du wie ein solcher Fehler zustande kommt.

Also Access läßt da noch sehr viel offen.

Gruß Dieter

Hallo,

ich 'schiebe' nichts auf ein Datenmodell - es kann der Auslöser für die Entstehung eines Fehlers sein.
Mit dem 'hausgemachten' Fehler in einer alten Prozedur wollte ich zu verstehen geben, dass sich ein früherer Fehler im VBA Projekt selbst festgesetzt haben könnte,
der unter bestimmten Voraussetzungen wie Kapitalabstürze und der Gleichen aktiv werden KANN.

Die Sache mit den nummerierten Feldnamen sehe ich persönlich deshalb als nicht gut gewählt an, weil bei 'Text23' beispielsweise die Aussagekraft darüber, welchen Inhalt das Feld hat, verloren geht.
Wenn du aber deine Felder durchnummerieren willst - OK, du wirst deine Gründe dafür haben - bitte das aber auch nicht als Kritik meinerseits zu verstehen.

Laufzeitfehler 49 ...
Ich glaube, dass es nicht unbedingt ein API-Aufruf sein muss, der diesen Fehler generiert - Stichwort Verweisbibliotheken

Sieh mal da rein:
http://www.fmsinc.com/microsoftaccess/Errors/Bad_DLL_Calling_Convention.asp (http://www.fmsinc.com/microsoftaccess/Errors/Bad_DLL_Calling_Convention.asp)

Hallo Database,

Zunächst mal danke für den Link, dort wird wieder auf den Decompile Schalter verwiesen. Ich bin gerade mit DF6GL in einem anderen Post der nicht von mir ist, am diskutieren über diesen undokumentierten Schalter. Vielleicht weist du mehr über diesen Schalter ? Überall steht, dass man sehr sparsam damit umgehen soll, da es auch zu Fehlern kommen kann. OK wenn gar nichts mehr geht dann ist es besser als nichts. Ich bin allerdings der Meinung, dass das Importieren aller Objekte in eine neue Datenbank den gleichen Effekt hat, da die Objekte dann neu kompiliert werden und wenn danach noch ein Kompilieren/Reparieren folgt sollte sich die MDB wieder in einem guten Zustand befinden. Oder ist das nicht so? Ich bin für jeden Tip Dankbar oder gibt es noch andere Möglichkeiten?

Den Fehler 49: Alle Verweise waren noch da. Ich nehme an da ich an diesem Tag einen Ablauffehler mit Haltepunkten gesucht habe, und dort auch noch vereinzelt Programmerweiterungen eingefügt habe, dass da irgenwas in einem Modul hängengeblieben ist, genau kann ich das nicht sagen.
Ich habe den Fehler auf die oben beschriebene Art (importieren aller Objekte) wegbekommen.

Gruß
Dieter

Hallo,

Diskussionen über diesen Befehlszeilenschalter Decompile weiche ich ganz gerne aus - ich will da nichts empfehlen und auch niemanden abraten.
Leider finden sich nicht viele wirklich brauchbare Informationen dazu aber vielleicht bringt ja der Link in dieser Antwortr ein bisschen mehr Licht.

http://www.trigeminal.com/usenet/usenet004.asp (http://www.trigeminal.com/usenet/usenet004.asp)

Hallo,
genau das meinte ich, wie es in dem Artikel steht, sparsam anwenden. Wenn nichts mehr geht OK, ansonsten werde ich persönlich das importieren vorziehen und erst dann wenn das nicht den Erfolg bringt mit dem Decompile Schalter arbeiten.

Danke und Gruß Dieter

Hallo,

es ist prinzipiell so wie DF6GL schon im anderen Artikel geantwortet hat - wirkt nur auf den Code.

Fehler die durch andere Dinge als vermurxten VBA-Code hervorgerufen wurden, werden dabei nicht repariert.

Hallo Peter

Ob du es glaubst oder nicht ein Tabellen Feld mit Felddatentype "Autowert" und der Feldgröße "Interger" verändert sich mit Access Version 2003 nach Ausführen der Funktion Komprimieren und reparieren in die Feldgröße "Zufall" ohne das von meiner Seite ein eine Änderung vor genommen worden ist.

Die Sache mit dem ändern von dem VBA Code ohne das daß Formular in der Enwurfansicht geöffnet war, hab ich mir sicherlich auch nicht ausgedacht. Die Datenbank bläht sich dann ohne ersichtlichen Grund um ein paar MB auf. Nach dem ich die Sicherungskopie mit den geänderten Sachen ergänzt hatte lief die Datenbank Einwand frei, ohne Speicher Fehler.

Bei der Datenbank handelt es sich um den Desingmaster in einer Replika Gruppe.

Gruß Stefan

Hallo Stefan,

dem darf ich beifügen, dass Autowerte eigentlich vom Datentyp LongInteger und nicht Integer sind (das wäre ein bissl knapp bemessen)!

ZitatDesingmaster in einer Replika Gruppe

im Umfeld der Replikation ist das Verhalten der Autowert PKs etwas anders gelagert.
Nähere Infos dazu findest du hier:
http://www.donkarl.com?FAQ1.30 (http://www.donkarl.com?FAQ1.30)

Wobei bis jetzt nie von Replikaten und Designmastern gesprochen wurde!
Darf ich dann mein Argument nochmal in Erinnerung rufen?

ZitatIch habe noch keine Datenbank gesehen, in der Autowerte nach dem Zufallsprinzip vergeben werden ohne selbst die Einstellungen hierzu zu verändern

Zitat...  hab ich mir sicherlich auch nicht ausgedacht ...

Davon habe ich nicht gesprochen sondern dieses Vorgehen mit dem Radwechsel bei fahrendem Auto verglichen - sowas macht man einfach nicht!

Des Weiteren gibt es unzählige Artikel im Netz, welche sich mit (scheinbar) unerklärlichen Fehlern bei Access beschäftigen.
Sehr seriös werden sie hier behandelt:

http://www.donkarl.com?FAQ1.27 (http://www.donkarl.com?FAQ1.27)
http://www.donkarl.com?FAQ1.22 (http://www.donkarl.com?FAQ1.22)

Insgesamt ist es halt immer sehr schwierig 100%-ig zutreffende Statements zu solchen Problematiken abzugeben.
Insbesondere dann, wenn ein Teil der Informationen nicht bekannt sind oder bekannt gegeben werden!

EOF

Hallo Peter

Danke für die Links.

Da ich im Netz auch schon gesucht habe sind einige Links mir bekannt, aber die dort aufgeführten Probleme treffen leider bei mir nicht zu, somit bleibt mein Problem noch offen was nicht heißt das ich aufgebe. Ich weiß im Moment nur damit um zu gehen.

Sicher du hast recht LongInterger!! Fehler beim Abschreiben.

Gruß Stefan

Hallo Stefan,

du hast ursprünglich von 2 Rechnern gesprochen, die Probleme machen.

Nun, was unterscheidet die 2 Maschinen vom Rest?
Sind sie von unterschiedlicher Marke und beinhalten unterschiedliche Komponenten?
Welche Software ist installiert, die es auf den restlichen, funktionierenden nicht gibt?

...sind in solchen Fällen immer wieder MÖGLICHE Fehlerquellen oder besser Auslöser für Fehler.

Schwierige Angelegenheit

Hallo Stapi,
ich glaub dir das, geh mal her und gibt einem Tabellenfeld den Namen Nr und speichere die Tabelle ab und schon hat dein Feld einen Index obwohl du den nicht angegeben hast.

Gruß Dieter

Hallo,


siehe Bild.. um die Mystik noch ein bisschen zu verstärken   ;)


[Anhang gelöscht durch Administrator]

Hallo,

tja manchmal geht's knapp an Zauberei heran...  :o :D

Hallo Peter

Es sind zwei Rechner unterschiedliche Marken beide haben WIN XP und Office 2003 mit richtiger Lizens auf den ich den Desingmaster bearbeiten kann. Bei beiden tritt diese Phänomen auf, egal ob es sich um eine Replika Gruppe handel oder nicht.
In der Replika Gruppe der anderen Rechner habe ich die Funktion gesperrt so das sie es nicht ausführen können.

Alle Verweise sind richtig und Vollständig gesetzt, alle Win Update sind Installiert hab auch Access neu Installiert es tritt immer wieder auf. Aus diesem Forum weiß ich das es nicht nur bei mir auf tritt, scheint an Win XP und Office 2003 zu liegen.

Gruß Stefan

Hallo Stefan,

Proit 2011!

Wenn es sich bei dem, von dir im letzten Posting angesprochenem Problem um die Sache mit dem Autowert handelt - damit sind wir nun schon einige Zeit OT!

Ich darf dich aber dennoch in dem Zusammenhang daran erinnern, dass bei Replikationen Autowert-Felder OHNE dein Zutun in 16-stellige zufallsgenerierte Feldinhalte umgewandelt werden.
Dieses ist ein Sicherheitmechanismus von Access um zu verhindern, dass irgendwann im Replikationszyklus doppelte Primärschlüssel vorkommen.

Haben bezgl des Aufblähens der DB die Links von donkarl.com nicht geholfen?

Absturzprobleme und desolate VBA-Projekte KÖNNEN neben vielen anderen Gründen auch durch besondere Gerätetreiber
(meist 3rd Party Produkte) hervorgerufen werden - daher meine Frage danach ob es idente Rechner sind.
Auch installierte Zusatzsoftware, die ihrerseits Probleme mit Treibern hat, KÖNNTE so negativ einwirken.