Office: (Office 2003) Probleme mit der Formularsteuerung

Hallo Gemeinde,

ich habe nun die erste Runde mit meiner DB recht gut hin bekommen nun tun sich aber doch weitere Schierigkeiten auf und ich tappe, auch nach Zahlreichen Versuchen, immer noch im Dunkeln.

Ich habe ein FRM MAIN womit ich starte, dann kann ich auswählen und zwar erst das Projekt an dem ich arbeiten möchte und danach dann den Bereich, hier fängt es schon an zu Haken, zwar erstmal NUR bei den Kandidaten die auf TEST enden, aber selbst die sollten funktionieren.

Wenn ich jetzt bei Main starte dann Klubhaus und danach Bundessekreteriat wähle komme ich auch nicht weiter, obwohl gerade bei letzterem in der abfrage XXX_qry_Exportversuch_1 alle Daten richtig angezeigt werden.

Vielleicht kann ja hier mal jemand drüber schauen und mir erklären was ich hier falsch gemacht habe, bevor ich jetzt hier weitere Details einbaue. Ich habe diese DB hier weitestgehend Anonym gehalten.

:)

 

Servus Kröste,
mein Vorschlag ist:
Optimiere Dein Tabellenmodell, indem Du auf jeden Fall die Primär- und Fremdschlüsselfeldernamen so benennst, dass man die Zugehörigkeit
sofort im Beziehungsfester erkenn kann, ohne dass da Beziehungslinien schon vorhanden sind.
Alles andere macht Deine späteren Arbeiten sehr, sehr kompliziert.
Wenns Probleme gibt, dann lösche Deine Daten aus den Tabellen und fange von vorne an.
Der einzig richtige Rat, den ich geben kann.

 

Vielen Dank für Deine ehrliche Antwort, ich erde mich da mal dran setzen und die Schlüsselbezeichnungen so ändern wie Du es angedeutet hast und wenn alle Stricke reissen, dann doch einen NEUSTART in betracht ziehen.
Vieleicht besteht ja doch die Möglichkeit menerseits mit den geänderten Schlüsselnamen, vor allem der Fremdschlüssel, wird ein wenig dauern, aber ich melde mich dann hier in diesem Thread noch mal ...

 

\@Kröste:
Den grössten Fehler, den man macht, ist, dass man beim Entwickeln schon hofft, echte Daten dabei bewahren zu können.
Vergiss diese Methode.
Kopiere Deine bisherige DB, um sie später mit Mitleid anschauen zu können.
Das passiert jedem Anfänger und auch Fortgeschrittenem.
Lösche alle Daten aus Deiner DB dann. Leider auch Deine Abfragen.
Du hast aber ja das Backup der DB, um da mal nachschauen zu können.
Optimiere das Tabellenmodell und dann die Abfragen.
Checke die Abfragen, bevor es an die Formulare geht.
Frage jederzeit hier, wenn Du ein optimiertes Tabellenmodell vorweisen kannst. Natürlich auch, wenn es Probleme beim Erstellen des Tabellenmodells geben sollte.

 

OK, dann muss es wohl so sein, ich habe jetzt nur eine Frage noch zu dem Grundsätzlichen Modell. Du hast es Dir ja angeschaut, kann ich kann ich zwei von meinen Tabellen verwenden ( tbl_Komponenten und tbl_pruefdaten ) oder auch die besser ganz neu bauen.
Es beruhigt mich ungemein dass es auch erfahrenen Leuten so geht dass schon mla ganz neu angefangen wird ....

 

\@Kröste:
Es gibt ein Procedere, wie man eine Datenbank entwickelt.
Das erste ist die allgemeine Aufgabenbeschreibung, damit sich Datenspezialisten an ein Datenbankmodell inkl. Tabellenmodelle machen kann.
Du solltest also auch mal mit freien Worten beschreiben, was das Ziel Deiner DB sein soll.
Dann können viele hier darauf gerne reagieren.
Ich schaue ja nicht allein hier zu.

 

Werd ich tun wenn ich mit dem Schritt der Neugestaltung meiner Tabellen durch bin. Habe jetzt schon einiges Anders gemacht als vorher und mir dadurch, so hoffe ich, eine höhere Flexibilität erreicht. Habe das hier vorher schon alles einmal angesprochen und werde das aus den vorangegangen Threads hier mit einflißen lassen und selbstverständlich alles nnochmals erläutern, aber ich bin guter Dinge .....

Danke für die Info ....

 

Ich habe mir jetzt erst einml Gedanken um die Tabellen und deren Struktur gemacht und habe alles neu und Hoffentlich auch Wartungsfreundlicher gestaltet.
Ganz wichtig, jetzt im Format 2010
Zum Zweck der DB:

Ich arbeite seit ca einem Jahr bei einem mittelständigen Unternehmen welches sich mit Wartungs - und Instandhaltungsarbeiten bei unseren Kunden beschäftigt. Zu diesen Aufgaben gehört unter anderem auch eine Lückenlose Dokumentation. Bis jetzt haben wir für diese Dokumentation immer Listen verwendet, welche ich als sehr unübersichtlich empfinde, verwendet. Ich habe dann vorgeschlagen das alle Listen für jegliche Art von Dingen die wir WARTEN in eine DB umgeandelt werden, wodurch jeder bei jeder Wartung die Möglichkeit erhält, alles für das Bauteil relevante über einen Längeren Zeitraum sofort vor Ort zu sehen.
Jetzt gibt es für mich ein paar Dinge zu lösen
erstens ein DB Model zu entwickeln, welches alle Daten die anfallen aufnehmen kann ( ich hoffe das im Ansatz mit der Tabellenstruktur diesmal besser gemacht zu haben )
zweitens Formulare so zu erstellen, dass sie Narrensicher sind und nicht schon vorhandene Daten manipuliert werden können
drittens die DB in Frontend und Backend so gestalten das der Mitarbeiter draußen nur den Teil der Daten mitbekommt der für Ihn relvant ist
und viertens die Berichte so gestalten das sie dem ALTEN STANDART sehr nahe sind, bei Bedarf lege ich gern mal so einen alten Bericht bei ...

Ich hoffe das ich ein wenig verdeutlichen konnte in welche Richtung meine DB hier gehen soll.

 

Hallo Matthias,

ein paar Anmerkungen:

accdbs reduzieren im Forum die Anzahl der Helfenden

Wo ist die Aufgabenstellung? Ohne eine detailierte(!) Beschreibung dessen, was die Anwendung leisten soll, ist es schwer bis unmöglich ein Datenmodell zu beurteilen.

Formulare haben eine Eigenschaft Bearbeiten zulassen, durch die die letztere Anforderung erfüllt werden kann.

Wenn Außendienstmitarbeiter auf das Backend (BE) zugreifen sollen, muss man überlegen, ob ein Access-BE
tatsächlich geeignet (hoher Datentransfer) ist. Auf welche Art stellst du dir die Verbindung zum BE vor?

Wo ist hier das konkrete Problem, für das du Hilfe benötigst?

BTW: Die Gesamtdarstellung liest sich für mich eher wie ein Fall für die Jobbörse oder professionell 'Betreutes Programmieren'. *wink.gif*

 

Nochmal zur Aufgabenstellung

wir führen eine Wartung Durch bei der Messungen durchgeführt werden und Beurteilungen erfolgen, diese tragen wir bis jetzt in Listen ein ( bei größeren Projekten sind das schon mal schnell 500 Bauteile, verteilet auf 70 Listen ). Diese Wartungsarbeiten fallen turnusmäßig an, von alle 3 Monate bis Jährlich. Jetzt kann ich natürlich hingehen und mir die Listen der letzten 3 Jahre mitnehmen, als Datei oder in Papier, und da durchblättern wie das Bauteil bei den letzten Wartungen ausgesehen hat, schöner wäre es das sofort auf einem Blick, auf dem Bildschirm sehen zu können. Diese DB soll lediglich als sehr große Datensammlung mit der wir keine Berechnungen durchführen wollen, außer den Termin für die nächste Wartung zu ermitteln. Und bevor ich jetzt hier im wesentlichen weitermache habe ich den Wunsch das mal jemand jetzt drüber schaut und mir sagt ob das Grundmodel meinen Anforderungen genügt, vor allem aber brauche ich die Möglichkeit noch weitere Komponentenarten säter mit einfließen zu lassen.

Zu den Formularen daß ich verhindern kann daß schon vorhandene Daten geändert werden, weiß ich das es geht, hab es im ersten Beispiel ja schon so gelößt

Und zu Frontend und Backend hab ich mir gedacht daß das nur ein Mitarbeiter in der Firma regelt und zum einen dem Außendienstmitarbeiter die Daten die er benötigt mitgibt, auf einem Datenträger und derselbe Mitarbeiter der die Daten mitgibt die vom Außendienstler erhaltenen Daten dann einplegt, über anfügeabfragen, sonst kommt es bestimmt zu abstürzen wegen der ID

Mit den Berichten weiß ich ist sehr viel tüftelei nachher noch, wenn erstmal die ersten 3 Punkte soweit funktionieren ....

Ich hoffe das nun vielleich etwas Licht in die Sache gebracht hab.

 

Um die Zahl der HELFENDEN zu erhöhen muß ich das denn wohl irgendwie konvertieren, gibt es da einen Weg der mir sofort angeboten wird, oder muß ich alles manuell kopieren in eine neue leere DB und die im Format 2003 bearbeiten??

 

Menu Datei...Speichern unter...

 

\@Kröste:
hier mal als Access 2003 Version.
Bitte ändere die Namen der Primärschlüssel so, dass sie den zugehörigen
Fremdschlüsseln entsprechen.
in tbl_Hersteller also nicht ID, sondern HerstID, da Du in einer anderen Tabelle den Fremdschlüssel HerstID_fkey verwendest. Als Fremdschlüssel reicht auch HerstID_f, da man lange Namen vermeiden sollte.
Dann erstelle mal ref. Integrität im Beziehungsfenster und ordne die Tabellen darin sinnvoll an.

 

Soweit so gut, habe die Namen geändert und Beziehungen hergestellt, möchte da später noch weitere verschiedene Komponenten hinzufügen können, denke das dies so machbar sein müsste. Habe eine Tabelle aus der Alten struktur so übernommen ie sie vorher auch war.

@ Ohrkester vielen Dank für das umstellen, bei mir bietet der mir das leider nicht an.

Ich hoffe das ich ausführlich genug beschrieben habe was ich genau vorhabe und das mir vielleicht hier jemand sagen kann ob ich auf dem richtigen Weg bin. Ich erwarte nicht das ich hier eine Komplettlösung bekomme, jedoch erhoffe ich mir ein wenig Hilfe.
Macht es Sinn in den Tabellen Nachschlageassistenten zu verwenden??

 

\@Kröste:

Eins solltest Du vermeiden.: Den Nachschlageassistenten. Einfach nicht darüber weiter nachdenken.
Was bietet man Dir nicht an ?
Ich hab Deine DB runtergeladen.
Du kapierst Folgendes nicht.
Primärschlüssel und die zugehörigen Fremdschlüssel müssen denselben Namen haben. ***
Primärschlüssel bekommen den Appendix "ID"
Die Fremdschlüssel bekommen den Namen des zugehörigen Primärschlüsselnamens und
den Appendix "_f"
Heisst also der Primärschlüssel "DeinpmID", dann muss der Fremdschlüssel heissen: DeinpmID_f
Nur so werden später notwendige VBA-Codes übersichtlich bleiben.

***: Dieses Prinzip muss nicht eingehalten werden. Jeder kann da machen, was er will.
Ich will bei meinen Hilfestellungen, dass meine Ordnung eingehalten wird.