Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Access friert ständig ein (A2010)

Begonnen von DaScAn, September 02, 2017, 21:15:16

⏪ vorheriges - nächstes ⏩

DaScAn

Hallo. Häufig, wenn ich im Formular die Ansicht von Layout zu Entwurf Wechsel (oder umgekehrt) oder ein Unterformular im Formular ist, friert Access ein ("Keine Rückmeldung") und braucht so 10-30 Sekunden, bis ich weiter arbeiten kann. Ich habe das ServicePack2 installiert und die Hotfixes von 2011 auch bereits, da im Pack enthalten.
Ich habe die Office 2010 Professional Version.

Parallel läuft nur Kaspersky Internet Security. Da ich dazu etwas im Internet gelesen habe, habe ich es einmal deaktiviert, aber das einfrieren bleibt.

MzKlMu

Hallo,
erstelle eine neue leere DB und importiere alle Objket aus der alten DB.

Eine DB im Entwicklungszustand muss auch regelmäßig komprimiert/repariert werden (Access Dienstprogramm), weißt Du das ?

Gibt es nur eine Tabelle ?
Wenn nein, sind Beziehungen mit referentieller Integrität angelegt ?

Gruß Klaus

DaScAn

Zitat von: MzKlMu am September 02, 2017, 21:45:57

Eine DB im Entwicklungszustand muss auch regelmäßig komprimiert/repariert werden (Access Dienstprogramm), weißt Du das ?


Nein. Wusste ich noch nicht.

Zitat von: MzKlMu am September 02, 2017, 21:45:57

Gibt es nur eine Tabelle ?

Noch gibt es nur eine Tabelle, korrekt. Sie soll als Ursprungsversion dienen. Wenn die "fertig" ist und funktioniert, kopiere ich diese. Ebenso läuft es mit dem Formular. SIe basieren dann alle auf dem selben Prinzip. Nur dass die Namen dann Tabelle1, Tabelle2, (Formular1 zu tabelle1, formular2 zu tabelle2...) sind.

In meinem Fall dann "Ersatzbeschaffung, Hygienische/PflegeMittel, Bekleidung, Päd.Betr. etc pp

MzKlMu

Hallo,
Du solltest so nicht weiter machen. Das wird nix.
Das geht mit einer Tabelle nicht.
Wenn die "fertig" ist und funktioniert, kopiere ich diese. Das braucht man in einer Datenbank nicht. In einer Datenbank gibt es keine gleichartig aufgebaute Tabellen.
Und Tabellen brauchen Beziehungen mit Schlüsselfeldern (Primärschlüssel, Fremdschlüssel), es müssen Indizes gesetzt werden usw. usw.
Wie bereits in Deinem anderen Thema gesagt, musst Du Dich von der Exceldenkweise lösen, Access geht anders.
Zitat"Ersatzbeschaffung, Hygienische/PflegeMittel, Bekleidung, Päd.Betr. etc pp
Auch solche Tabellen dürften für Access mit ziemlicher Sicherheit der falsche Weg sein.
Du kannst nicht einfach für jede Produktgruppe eine Tabelle machen. Auch Ersatzbeschaffung als Tabelle dürfte so nicht stimmen.
Erkläre mal was die DB machen soll.

Wenn das eine Musterdb werden soll, so muss ich Dich enttäuschen, die Profis die die DB mal machen sollen, werden nichts von Dir übernehmen.
Man kann keine Datenbank entwickeln ohne die Grundlagen zu Access.
Hier kannst Du dazu was finden:
https://www.access-tutorial.de/
Gruß Klaus

DaScAn

Hallo.
In dem Punkt, Basics zu kenne, gebe ich dir recht. Dennoch funktioniert es so.

Das die einzelnen Punkte (Ersatzbeschaffung, Hygiene etc.) verschiedene Konten sind, muss ich es sogar extra anlegen.

So. Wie soll die DB funktionieren?
Geöffnet ist ein Startfenster zu sehen, wie die verschiedenen Konten als Button gelistet sind. Wenn man nun eine Buchung bei Ersatzbeschaffung tätigen will, klickt man auf den Button Ersatzbeschaffung. Dort tätigt man die eingaben, die in der Tabelle für Ersatzbeschaffung abgelegt werden.
Möchte man eine Buchung bei Hygiene tätigen, drückt man auf den Button, Hygiene. Dort werden die Buchungen dann im Formular getätigt (eigenes neues Formular, oder Kopie von einer Funktionierenden, wo die Abhängigkeiten angepasst werden) und wiederrum in der Tabelle für Hygiene gespeichert.

Ich habe mittlerweile bereits eine zweite Tabelle angefertigt, als Kopie, sowie das Formular, und entgegen deiner aussage, funktioniert es.

Du sagst, ein Profi wird nichts von mir übernehmen.
Meine Antwort: Ja, das ist mir so ziemlich egal, soll er ein eigenes Konstrukt bauen. Wenn es funktioniert, dann ist alles gut. Die Chefs müssen nur von meiner "Demo" überzeugt werden und dann geben sie es offizielle in Auftrag. Wenn der Profi also nur eine Tabelle für alles nutzt, dann gerne doch.

Ich gebe ebenfalls recht, dass ich zu sehr das Excel Schema im Kopf habe.

Du fragst dich sicher, warum wir überhaupt alles einzeln ablegen (Ersatzbeschaffung, Hygiene, Päd.Mittel ...) Da wir für jede Einnahme und Ausgabe Buch führen müssen. Unser Träger hat das anhand einer Excel Tabelle vor einem Jahr eingeführt. Aber das schon eher semiprofessionell. (mein Eindruck) Und genau deswegen der Versuch, die Firma davon zu überzeugen, es einmal richtig zu machen. Das nicht Ich dieses Projekt vollführen werde, ist denen dann auch klar.

Und da es vom Träger schon alles auf einzelne Tabellen (Konten) aufgeteilt ist, möchte ich es für die Demo, auch so in der Datenbank so beibehalten.

MzKlMu

Hallo,
Zitatverschiedene Konten sind, muss ich es sogar extra anlegen.
nein, eben nicht. Eine Tabelle mit einem Fremdschlüssel zum Konto, für das auch eine Tabelle benötigt wird.

Alle Buchungen kommen in eine Tabelle. Wenn Du etwas buchst, braucht es doch nur ein Kennzeichen für die Art der Buchung (z.B. als Hygiene). Auch dann kannst Du über Abfragen alles getrennt darstellen.

ZitatIch habe mittlerweile bereits eine zweite Tabelle angefertigt, als Kopie, sowie das Formular, und entgegen deiner aussage, funktioniert es.
Ich habe nicht geschrieben, dass es nicht funktioniert. Es ist nur der falsche Weg für eine Datenbank.
Spätestens bei Auswertungen die mehrere Gruppen einschließt wirst Du das merken.
Von der Performance ganz zu schweigen.
So wie Du das aufbaust kannst Du auch bei Excel bleiben mit einer Datenbank nach dem Muster aufbaust, wirst Du keine Vorteile haben gegenüber Excel.
Gruß Klaus

DaScAn

Gut, du magst recht haben, dass ich ggf einen unkonventionellen weg gehe. Was aber daran liegt, dass ich mich mit Access noch nie so direkt beschäftigt oder sogar gelernt habe. viele Programme gehen ja mittlerweile intuitiv oder per drag & drop. Ein paar Basics im Kopf und es läuft.

Dieses Schema scheint bei Access nicht zu funktionieren.

Ich bin mir dessen bewusst und sage auch bewusst nicht, dass ihr unrecht habt. Ihr mögt recht haben, ich gehe im Moment aber "meinen" weg, da es nur der Anstoß sein soll, dass es dann ein Profi übernimmt und tatsächlich "richtig" und Performance orientiert und optimiert erstellt. Denn dafür wird derjenige ja dann bezahlt von uns, für teures Geld.

Ich bedanke mich dennoch für einen netten und erkenntnisreichen Kommunikativen Austausch  :)

Das Problem, weswegen der Threath eröffnet wurde, ist damit aber noch nicht gelöst. Denn es taucht auch bei einer Nigel nagelneuen Datenbank auf.
Ich kann diese "Denkpause von Access umgehen, wenn ich anstatt die Ansicht zu ändern einfach eine Tabelle aufrufe per Doppelklick und dann per Doppelklick zum Formular zurückkehre, dieses öffnet sich ja dann in der Layout Ansicht. Aber das kann ja nicht die Lösung für die "Denkpause" sein.

Beaker s.a.

Hallo,
Folgende Gründe fallen mir ein:
- unkonventionelle Tabellen-/Abfragenamen (keine Leer- und
Sonderzeichen, nur "_" ist erlaubt
- reservierte Wörter als Feldbezeichner
- DLoopup-Gewitter beim Öffnen des Formulars
- die Datenherkunft des Formulars an sich (Abfrage)

Bezügl. Datenbankstruktur kann ich mich Klaus' Einlassungen nur
anschliessen. Ich glaube aber auch deine Anforderung anders verstanden
zu haben. Du willst die DB gar nicht selbst entwickeln, sondern nur eine
Oberflächendemo für deinen Chef, um ihm zu zeigen, wie einfach das mit
Access gehen könnte; - Kostenstelle angeklickt - Buchung erfassen - fertig.
Für diesen Zweck finde ich kannst du das so machen. Behalte aber im
Hinterkopf, dass es falsch ist, und wenn Cheffe schon bei deiner Demo
nach Auswertungen fragt, du vor der Wand stehst.  ;)
Bei einer professionell entwickelten DB sieht das dann im Prinzip genauso
aus, nur das ein korrektes Datenmodell dahinter steht, und es nicht für jede
Kostenstelle ein eigenes Formular gibt.
gruss ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

DaScAn

Zitat von: Beaker s.a. am September 03, 2017, 13:20:27
[...]Ich glaube aber auch deine Anforderung anders verstanden
zu haben. Du willst die DB gar nicht selbst entwickeln, sondern nur eine
Oberflächendemo für deinen Chef, um ihm zu zeigen, wie einfach das mit
Access gehen könnte; - Kostenstelle angeklickt - Buchung erfassen - fertig.
Für diesen Zweck finde ich kannst du das so machen. Behalte aber im
Hinterkopf, dass es falsch ist, und wenn Cheffe schon bei deiner Demo
nach Auswertungen fragt, du vor der Wand stehst.  ;)
Bei einer professionell entwickelten DB sieht das dann im Prinzip genauso
aus, nur das ein korrektes Datenmodell dahinter steht, und es nicht für jede
Kostenstelle ein eigenes Formular gibt.
gruss ekkehard

Da hast du vollkommen Recht. genauso ist es gedacht. Das eine Auswertung noch nicht vorhanden ist, bzw erst eingebaut werden müsste, steht außer Frage. Mir würde da einfallen. ALso als Bericht (Auswertung)
- Wie hoch waren die Ausgaben im Monat X, WIe hoch die Einnahmen im Monat Y, wie oft wurde zB. Seife gekauft oder im Supermarkt Z. All dies sind dinge, die ich versuche so kurz und knackig wie möglich einzubauen, um die Überzeugung zu schaffen.
Und wenn nicht, dann arbeiten wir halt weiter mit Excel, was zwar geht und funktioniert, aber eher umständlich.

Danke, dass mich jemand verstanden hat. Dachte schon ich hätte mich ungenau ausgedrückt.

MzKlMu

Hallo,
ich hatte Dich auch verstanden, sonst hätte ich Dich ja nicht gewarnt einen solchen Aufbau vorzunehmen.
Zitat- Wie hoch waren die Ausgaben im Monat X, WIe hoch die Einnahmen im Monat Y, wie oft wurde zB. Seife gekauft oder im Supermarkt Z. All dies sind dinge, die ich versuche so kurz und knackig wie möglich einzubauen,
Genau das wird mit getrennten Tabellen nicht gelingen. Und schon gar nicht kurz und knackig. Du denkst immer noch zu sehr in Excel.
In Access lassen sich (im Gegensatz zu Excel) solche tabellenübergreifenden Datenauswertungen nicht so ohne weiteres machen. Du musst Unionabfragen erstellen, die die Performance in die Knie zwingt. Außerdem vereinheitlichen Unionabfragen die Feldnamen.
Du hast also mehrere Tabellen in einer Abfrage zusammengeführt und die Spalten haben die gleichen einheitlichen Namen. Dann kannst Du auch gleich eine Tabelle machen.
Gruß Klaus

PhilS

Auch wenn die zahlreichen Kommentare zum Datenbankentwurf durchaus ihre Berechtigung haben, möchte ich hier auf die ursprüngliche, eigentliche Kernfrage zurückkommen.

Zitat von: DaScAn am September 02, 2017, 21:15:16Häufig, wenn ich im Formular die Ansicht von Layout zu Entwurf Wechsel (oder umgekehrt) oder ein Unterformular im Formular ist, friert Access ein ("Keine Rückmeldung") und braucht so 10-30 Sekunden, bis ich weiter arbeiten kann.

Das Access in dieser Form "einfriert" ist definitiv nicht normal und sollte sich beheben lassen, wenn man die Ursache findet (und abstellt).

Deine eigene Vermutung in Richtung des Virenscanners ist durchaus eine sehr passende Idee. Ich würde empfehlen, dem nochmal genau nachzugehen. Ich kenne mich Kapersky nicht aus, aber oft ist z.B. ein Neustart erforderlich, um einen Virenscanner komplett zu deaktivieren. Du solltest auf jeden Fall genau prüfen, (Task Manager), dass der Virenscanner nicht mehr läuft, bevor du hier zu einer endgültigen Schlussfolgerung kommst.

Wenn es tatsächlich am Virenscanner liegt, ist es vermutlich nicht im Einklang mit deinen Sicherheitsrichtlinien, diesen komplett zu deaktivieren. Ich würde eher empfehlen, ein dediziertes Verzeichnis für deine Access-Entwicklung anzulegen und dieses von der Überwachung durch den Virenscanner auszunehmen.


Weitere mögliche Ursachen für das Einfrier-Problem wäre die Speicherung der Access-Datei auf einem Netzlaufwerk. Insbesondere, wenn auf dieses Netzlaufwerk per WLAN zugegriffen wird. - Ich empfehle immer, eine Access Daten während der Entwicklung auf der lokalen Festplatte abzulegen. Für das Frontend einer Access-Anwendung gilt das gleichermaßen für den Endanwender-Einsatz.

Eine weitere potentielle Ursache sind Online-Storagesysteme wie OneDrive oder DropBox. Ich würde eine Access-DB während der aktiven Entwicklung nicht in einem Verzeichnis speichern, dass direkt mit einen solchen Dienst synchronisiert wird. Es besteht ein gewisses Risiko der Dateikorruption durch OneDrive, Dropbox & Co.

Ganz grundsätzlich ist es empfehlenswert eine Access-DB während der Entwicklung exklusiv zu öffnen (Optionen->Client Settings->Advanced->Default open mode). Dies verhindert, dass andere Prozesse gleichzeitig mit Access auf dieselbe Datei zugreifen.
Neue Videoserie: Windows API in VBA

Klassische CommandBars visuell bearbeiten: Access DevTools CommandBar Editor

Beaker s.a.

Hallo,
Nicht, dass mir noch unterstellt wird ich würde ein falsches Datenmodell propagieren  ;)
Zitat- Wie hoch waren die Ausgaben im Monat X, WIe hoch die Einnahmen im Monat Y, wie oft wurde zB. Seife gekauft oder im Supermarkt Z. All dies sind dinge, die ich versuche so kurz und knackig wie möglich einzubauen,
Da muss ich in die gleiche Kerbe schlagen wie Klaus. Wie bereits geschrieben
Zitatschon bei deiner Demo nach Auswertungen fragt, du vor der Wand stehst
geht das mit diesem, falschem Modell NICHT.
gruss ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)