Formationsformular?

[database]

Grüß dich,

In den Formularen steht bei einigen Feldern: "#Name?"

Das kommt dadurch, dass sich die Datenherkunft, also die zu Grunde liegende Tabelle der Formulare geändert hat.
Richtig, die grüne Markierung zeigt an, dass es Fehlerinformationen dazuu gibt. Rechtsklick und dann auf die Raute mit dem Rufzeichen klicken zeigt dir die zugehörigen Fehler an.

Du wirst m.E. nicht umhin kommen den Fomularaufbau ganz neu zu machen und somit den neuen Gegebenheiten anzupassen.
Lass dir damit aber noch ein wenig Zeit - vielleicht hat oma noch den einen oder anderen Vorschlag zum Datenmodell - der sollte
dann für die Formular-Neugestaltung schon umgesetzt sein um nicht nacharbeiten zu müssen.

p.s.,
Frage noch ... du arbeitest mit Access 2003? (Ist für die Formulargestaltung wichtig - damit's keine Brösel gibt, wenn ich dir aus Acc2007 was zukommen lasse)

EDIT:
Zur Veranschaulichung habe ich nochmals die DB reingestellt - mit einem neuen Erfassungsformular für Spieler.

[Anhang gelöscht durch Administrator]

[LeoMessi10]

Hi

OK Danke für die Infos.

Ja ich hab Access 2003.


Servus

[oma]

Hallo,

habe gar nicht bemerkt, dass schon eine weitere Version vorliegt; aber egal - du wirst sicher aus beiden Versionen etwas "mitnehmen" können!

anbei einige Bemerkungen:

Feldaufbau tbl_Spieler:
zu den einzelnen Tabellen ist noch sorgfältig bzw. vom Auswertungsbedürfnis ausgehend, die Anzahl der Felder zu überlegen:
- In tbl_Spieler ist Position zu durchdenken, ich würde das nicht erfassen.
Manche Spieler spielen ständig variabel (Olic bein Bayern ist Stürmer oder Mittelfeldspieler) oder andere werden im Laufe der Zeit von Mittelfeldspieler zu Verteidiger umfunktioniert! Man könnte das dann ständig aktualisieren, macht aber beim flexiblen Einsatz der Spieler auch wenig sinn. D.h. Position gehört nur in Aufstellung!

- ich würde DatumBeginn und DatumEnde für Vertragsbeginn und Vertragsende einfügen; alle Spieler mit Datum in DatumEnde sind dann ehemalige Spieler des Vereins; ist doch auch interessant: eine Auswertung aller Spieler mit Vertragsdauer usw.

- weitere Felder: DatumGeburt, Fuß(links, rechts, beidbeinig), Nickname, Größe, .......

Zum Tabellenaufbau:

Zur Aufstellung ist zu bemerken, dass diese immer zu einem Zeitpunkt gilt. Nun ist zu überlegen, ob man eine Aufstellung mit einem Datum erstellt und diese dann immer überschreibt oder eine Hierarchie anlegt. So liegen zu einer Mannschaft verschiedene Aufstellungen zu verschiedenen Zeitpunkten vor. Man könnte also für eine Mannschaft die gesamten Saison verfolgen u. entsprechen auswerten (Häufigkeiten der Einsätze und Spielzeiten eines Spielers usw.

Zu überlegen dann noch die Felder: SpielzeitBeginn, SpielzeitEnde (für Berechnung der Auswechslung) ; Gegner, Spielart (Freundschaftsspiel, Meisterschaft, Pokal, CL...), Punkte, Tabellenstand....

Zum Beispiel:
Beispiel geht von Speicherung aller Aufstellungen für verschiedene Mannschaften aus!

Du kannst Spieler in frmSpieler  oder in frmTeam ansehen/eingeben.
In frmTeam kannst du Mannschaften eingeben und/oder auch gleich die Spieler eingebn oder nur ansehen(muss dann noch eingestellt werden)

In frmAuf kannst du in einer Aufstellung immer nur Spieler aus der Mannschaft eingeben (Siehe Code);  gleichzeitig  werden im Kombifeld nur Spieler angeboten, die aktuell in Mannschaft sind (DatumEnde =NULL)

In einer Aufstellung kann ein Spieler nicht 2mal stehen (siehe Tabellenentwurf tbl_AufDetail bei Indizes)


Soweit erst einmal von mir, wollte nur einige Anregungen bzw. Vorschläge machen, da man das Ding entweder einfach oder auch sehr anspruchsvoll gestalten kann.

Wichtig ist, was du alles bezwecken, d.h.  / erfassen / auswerten willst!!?

Gruß Oma


[Anhang gelöscht durch Administrator]

[LeoMessi10]

Hi

Danke auch an dich Oma ich werd mich mit euren beiden Vorschlägen mal auseinandersetzen und mich dann wieder melden.

[database]

Hallöchen,

habe gar nicht bemerkt, dass schon eine weitere Version vorliegt;

@oma  ... uuuppsss
Ich habe ein wenig Zeit gefunden und habe daher das Beispiel von LeoMessi erstmalig umgegraben
Mein Vorschlag beruht auf dem Grundkonzept, der Grundidee des TO.
Die Anpassung / Änderung  / Erweiterung der Tabellen stelt im Grunde einen Versuch/ein Muster für die Umsetzung dieser Grundidee ohne großartige Planung dar.
Normalisierung wurde in groben Zügen umgesetzt, wobei sicher noch die eine oder andere Sache zu diskutieren wäre. Leider fehlen hierzu aber auch die notwendigen Bedarfsbeschreibungen.

@LeoMessi
Du siehst wie rasch sich die Grundvoraussetzungen ändern können ein Formular zu erstellen ! !
Wichtig ist VOR jeder physischen Arbeit (also Tabellenerstellung, Abfragendefinition, Formular/Berichtsgestaltung) eine durchgehende, genaue und klar abgegrenzte Bedarfsanalyse zu machen.
Das Ergebnis dieser Analyse kann man dann in eine Art Szenario umlegen aus dem hervorgeht, was die DB bzw. die fertige Applikation zu leisten hat.
Mit den Inhalten des Szenarios erstellt man dann ein ERM und wandelt dieses -  nach eingehender Prüfung auf Vollständigkeit, Widerspruchsfreiheit und Nachvollziehbarkeit der Datenflüsse - in
ein Relationenmodell um, an dem dann die Regeln der Normalisierung angewendet werden (Bestimmung der Primär und Fremdschlüssel, Verlegung von Feldern in andere Tabellen sowie Erstellung von etwaigen Zwischentabellen im Zuge der Anpassung dieses Datenmodells) bis zur Wahrung 3. Normalform. Im Zuge dieser Vorgänge werden auch die Feldnamen und die Tabellennamen bestimmt - hoffentlich kurz und bündig

Erst dann sollte man die gewonnen Ergebnisse in den physikalischen DB-Entwurf umlegen, also die Tabellen in einer DB anlegen.
Der nächste Schritt ist dann die Beziehungen zwischen den Tabellen herzustellen (und im Fall von Access die Beziehungen auf Wahrung der referenziellen Integrität einzustellen)
Nach der Eingabe von einigen Datensätzen zu Testzwecken können die wichtigsten Abfragen definiert, getestet und gespeichert wrden.
als Nächstes können nun die Formulare erstellt und zum Schluß etwaige notwendige Berichte erstellt werden.

Klingt alles ein wenig umständlich und fad, weil man eine relativ lange Zeit im Access noch gar nichts sieht. Aber eine ausführliche und gut durchdachte Planungsphase erspart eine Unmenge an vergeudeter Entwicklungszeit, wenn im Nachhinein Änderungen an den Tabellen, dem Fundament einer Applikation, vorzunehmen sind.

In diesem Sinne

Grüße

Perter