Liebes Forum,
es ist schon wirklich recht lange her, daß ich eine DB erstellt habe. Mein Problem ist, daß ich echt eingerostet bin :-\
und Eure Hilfe brauche.
Ich soll / will für meine Verein eine DB erstellen, die die Mitgliederdaten enthält, Bankkontodaten, das Inventar etc.
Das ist auch nicht das Problem - Sondern wohl eher ein falscher Gedankengang von mir: über die von mir erstellten Tabellen (und dann die basierende Abfrage) habe ich ein Formular erstellt. Kein Problem.
Mein Problem ist eher, daß ich am 255-limit kratze und ich habe noch so viele Felder, die ich mit einarbeiten sollte.
Den RAhmen sprengt eingentlich nur die Inventarisierung. Die ist allerdings wichtig, denn alle Vorstandsmitglieder sollen auf die Datenbank drauf zugreifen sollen (mit speziellen Rechten): Präsident, Kassier, Schriftführer, Ordensgremium, Festkomitee, Funduswart, Archivar. Entsprechend ist also die Liste der Wünsche lang.
Wie kann ich das am sinvollsten bewerkstelligen?
Es wäre für den Anwender toll, wenn er auf einen Blick sehen kann, was welches Mitglied an Uniformen, Kleidern und Instrumente bei sich hat. Ich stelle mir vor, daß es für jedes Kleidungsstück ein Ausgabedatum, ein Rückgabedatum, die ja/nein-Abfrage für Ausgabe und Rückgabe, ein Bemerkungsfeld (wegen Beschädigung o.ä.), Größe und Inventarnummer.
Momentan steht jedes Kleidungsstück und Instrument etc. im Formular auf einer zweiten Seite mit den oben genannten Kriterien.
Schön wäre es - damit die übersicht einfacher wird (die Übersicht ist vorhanden, ich würde es grafisch lösen können, bzw. über verschiedene Reiter), wenn ich anhand eines Auswahlfelds der Vereinsaktivität (z.b. Musiker, Vorstand, Kinder) ein entsprechendes Formular aufbereitet wird. =====> oder wäre ein Unterformular besser? könnte ich das so dann lösen?
Hochladen kann ich euch nichts, ich habe meinen Entwurf verworfen aus den o.g. Problem wegen dem Limit und dem Formular. Befinde mich also noch im Aufbau.
lieben Dank für Eure Hilfe und Ideen
Grüßle vom Bodensee
Hallo,
wer in einer Tabelle an die Feldzahl von 255 kommt hat drastische Fehler im Aufbau.
Hier ist ein Zerlegung in Teiltabellen unbedingt notwendig. Aber nicht einfach die Felder in weitere Tabellen, sondern nach dem Prinzip einer relationalen Datenbank.
ZitatDen RAhmen sprengt eingentlich nur die Inventarisierung
wieso, das Inventar sollte als Datensätze vorliegen und nicht als Felder bzw. Feldnamen.
Kannst Du das mit dem Inventar mal erläutern, warum benötigst Du da so viele Felder?
Es wäre trotzdem nicht schlecht gewesen, die bisherige DB mal hochzuladen, damit man sieht, wie die Tabelle nach den Normalisierungsregeln aufzuteilen ist.
Erstelle die DB (die für das Forum) bitte unbedingt in der Version 2003, die neueren Versionen sind immer noch nicht so stark verbreitet.
Hallo,
danke für deine Antwort. Ich muß dich berichtigen: nicht die Tabelle hat 255 Felder, sondern schlußendlich die Abfrage, die mir die Daten von den zugrundeliegenden Tabellen für das Hauptformular aufbereitet.
Von der Version her habe ich mich direkt von A97 auf A10 erneuert. Die alte Version A97 ist nicht mehr vorhanden, würde uns also nix bringen. Die 2010 ist nicht stabil? Da wie schon erwähnt der erste Versuch daran scheiterte, daß die Abfrage am Limit kratzt, habe ich es verständlicherweise verworfen. Ich weiß nicht, wo ich noch normalisieren könnte...bin wirklich ratlos.
Das Inventar erfasst alle Kleidung die vorhanden oder ausgegeben wurde. Jedes Hemd erhält eine Nummer, soll vom Zustand her beschrieben werden und die Größe angeben. So verhält es sich mit den Hüten, den Uniformen etc. gleich. Dazu soll es Tabellen geben. Auch für den Lagerort.
Aber: für jedes Inventar möchte ich im Hauptformular dann ein Feld für das Ausgabedatum, die Ja/nein-Abfrage für den Erhalt, das Rückgabedatum und auch wieder die Abfrage der Rückgabe erstellen. Und das ist eigentlich dann das Problem, daß es mir dann mit den Feldern nicht mehr reicht.
Warum soll das angezeigt werden? Ich will den Verantwortlichen die Möglichkeit geben, alles über eine einzige Eingabemaske eintragen (und schließlih auch sehen) zu können. Über die ja/nein-Abfragen steuere ich dann die Berichte.
danke
Hallo,
da fehlt noch viel, zur Normalisierung. Auch wenn eine Abfrage mehr als 255 Felder benötigt ist das Datenmodell mit ziemlicher Sicherheit falsch.
Zitatfür jedes Inventar möchte ich im Hauptformular dann ein Feld für das Ausgabedatum, die Ja/nein-Abfrage für den Erhalt, das Rückgabedatum und auch wieder die Abfrage der Rückgabe erstellen.
Dazu benötigst Du 4 Felder (5 mit ID), ein Fremdschlüssel zum Inventar, ein Fremdschlüssel zur Person, ein Feld für die Vorgangsart (Ausgabe/Rückgabe) und ein Datumsfeld (Vorgangsdatum). Die Ja/Nein Felder sind überflüssig. Ausgabedatum eingetragen = ausgegeben, wozu denn noch Ja/Nein?
Für das Inventar (alles) ist eine eigene Tabelle zu erstellen, aus der dann ausgewählt wird.
ZitatDie 2010 ist nicht stabil?
wer hat das geschrieben? Ich (und andere auch) haben kein Access2010. Du kannst auch mit Access2010 eine Access2003 (MDB) erstellen.
Deine Angaben sind wenig hilfreich, weil aus der Beschreibung nur wenige Zusammenhänge erkennbar sind.
hallo,
hmm, so habe ich es ja versucht aufzubauen - muß aber wohl nochmals richtig darüber nachdenken, wie ich das dann alles zusammenfassen kann. ich habe für das inventar verschiedene tabellen, die ich nach den jeweiligen gruppen sortiert habe. daß nur wenig zusammenhänge erkennbar sind, verstehe ich nicht. habe ich zuwenig informationen gegeben? oder bin ich auf die fragen nicht richtig eingegangen?? - sorry, wenn es so ist.
mit den ja/nein felder wollte ich die berichte steuern. du meinst, dass das nicht nötig ist? gut, den steuercode über das datum kenne ich so nicht, aber lerne gerne dazu. dadurch reduziert sich ja auf jeden fall die anzahl der felder für die hauptabfrage...
das mit a10 habe ich falsch interpretiert von dir. es ist nicht viel verbreitet. habe aber trotzdem auch gelesen, daß es nicht so stabil sei. anyway, das soll aber ja jetzt nicht unser problem sein. ich mach mich jetzt nochmals ans werk und schaue, wie weit ich komme.
Hallo,
Zitatich habe für das inventar verschiedene tabellen,
das ist bereits der 1. grundsätzliche Fehler, das Inventar gehört in eine Tabelle, mit einem Schlüsselfeld für die Gruppen.
Hallo,
Du musst Dir in aller erster Linie um die Datenzusammenhänge im Klaren werden, die dann strukturiert und über Beziehungen miteinander in Verbindung gebracht werden (müssen). --> Normalisierung. Siehe dazu u. st. Links 1 und 1a.
Bevor Gedanken an Abfragen, Formulare und Berichte verschwendet werden, MUSS dieses Daten- (Tabellen-) Gerüst konsistent stehen....
An der (scheinbaren) Instabilität von A2010 ist in aller Regel der Entwickler schuld, der entweder schludrig gearbeitet hat oder sich nicht an die Access-Spezifikationen und auch die neuen "Features" gehalten hat.
Dass gilt aber für alle Versionen..
Hallo,
Zitatwer in einer Tabelle an die Feldzahl von 255 kommt hat drastische Fehler im Aufbau
ich benötige in meiner Problematik öfters mehr als 255 Felder in einer Tabelle ; arbeite also häufiger mit diesen "drastischen Fehler" aber zum Glück trotzdem erfolgreich, da eine Aufteilung in mehreren Tabellen und damit zu arbeiten, möglich ist.
Gruß Oma
Hallo,
mal abgesehen davon, dass die Hinweise und Ratschläge von MzKlMu und DF6GL einer unbedingten Beachtung wert sind ...
ZitatIch will den Verantwortlichen die Möglichkeit geben, alles über eine einzige Eingabemaske eintragen (und schließlih auch sehen) zu können
Kann mir eigentlich nicht vorstellen, dass 255 Felder auf einem Formular in irgend einer Form der Übersichtlichkeit dienlich sein könnten.
Du hast ja schon mal daran gedacht die Informationen in Registern auf einem Hauptformular anzubieten.
Genauso kann der Ausgabebestand für eine bestimmte Person in einem UFo zusammengefasst werden (richtiger DB-Aufbau vorausgesetzt) ohne 255 Felder anzubieten von denen dann 230 leer sind.
hallo an alle,
danke für die infos. ihr seid super
ZitatKann mir eigentlich nicht vorstellen, dass 255 Felder auf einem Formular in irgend einer Form der Übersichtlichkeit dienlich sein könnten.
Du hast ja schon mal daran gedacht die Informationen in Registern auf einem Hauptformular anzubieten.
hatte ich weiter oben schon erwähnt, ich benutze register, das ist wohl auch der grund, warum es dann am limit kratzt.
ZitatGenauso kann der Ausgabebestand für eine bestimmte Person in einem UFo zusammengefasst werden (richtiger DB-Aufbau vorausgesetzt) ohne 255 Felder anzubieten von denen dann 230 leer sind
genau das schwebt mir vor. allerdings nicht nach dem benutzer der davor sitzt, sondern nach der gruppenzugehörigkeit des mitglieds.
wie kann ich das umsetzten, hast du ideen?
@oma,
ich arbeite nicht mit 255feldern pro tabelle, sondern die tabellenfelder insgesamt in der darauf basierenden abfrage ergeben dann die 255 felder. wie hast du das gelöst?
@franz,
genau. darum die überschrift. nich fehlt mir komplett der durchblick aufgrund der langen pause. ich habe mir insoweit die gedanken gemacht, daß ich sofort alle für mich wichtigen felder (also die abfragefelder ja/nein für die berichte) einbeziehe. im nachhinein macht das wenig spaß und alle würde mich fragen, warum ich denn nicht gleich dran gedacht habe. :( denke aber schon, daß ich noch hier und da ein gedankenfehler habe. noch steht alles auf dem papier und ich schieb das hin und her.
Zitatdas ist bereits der 1. grundsätzliche Fehler, das Inventar gehört in eine Tabelle, mit einem Schlüsselfeld für die Gruppen
hast recht, das ist mir heute mittag auch so durch den kopf gegangen und arbeite schon daran....
Hallo,
Zitatnicht nach dem benutzer der davor sitzt, sondern nach der gruppenzugehörigkeit des mitglieds
Ja natürlich habe ich Ideen dazu - sonst wäre es ja fad. ;)
Ein richtiger Datenbankaufbau ermöglicht, die Gruppenzugehörigkeit eines Mitglieds zu ermitteln,
Das Kennzeichen - der Fremdschlüssel - der Gruppe ist dann Bestandteil eines Mitgliederdatensatzes oder bei einem anderen Aufbau
Bestandteil eines Datensatzes in einer Zwischentabelle (wir in jedem Fall benötigt, wenn ein Mitglied in mehreren Gruppen vorhanden sein kann).
So ist es dann möglich jedes Mitglied einer Gruppe aufzulisten und/oder festzustellen in welcher Gruppe ein bestimmtes Mitglied Mitglied ist.
Da in der Datenbank die Ausgaben mit dem Mitglied in Verbindung stehen ist somit möglich die Ausgaben auf die Gruppenmitgliedschaft zu beziehen.
Passende HaFo / UFo Kostrukte oder Formulare mit Möglichkeit von 'Vorauswahlen' durch abhängige Kombifelder mit Unterformular bzw. entsprechend aufbereitete Berichte lassen hier kaum einen Auswertungswunsch offen.
Hallo zusammen,
ich habe mich jetzt mal hingesetz und nach meinem minimalen verständis versucht eine DB zu erstellen. ich bin sicher noch nicht fertig, aber evtl. kann schon das ein oder andere von euch herausgelesen werden und ihr mir noch weitere ratschläge zur verbesserung und hinweise auf fehler mitteilen??
ich habe die idee, alles gleich in einer inventarliste zu speichern wieder verworfen. ich müßte so 100x saalhemd eingeben. oder auch hut oder uniform. da war ich jetzt doch viel zu faul dazu - und sinn macht das ja auch nicht. ich muß allerdings diese dinge definitiv aufführen und dann auch noch durchnummerieren, damit ich die eindeutige identifikation habe.
hättet ihr eine bessere idee?
danke und grüße
Hallo,
sieht nicht so schlecht aus - bis auf ein paar Kleinigkeiten:
Sämtliche Orden-Bezüge müssen aus der tb_Ausgabe raus
Ordentyp_key hat in der tb_Inventar nichts zu suchen
Postenvergabe_key hat in der tb_Mitglieder nichts zu suchen
Orden_key muss ebenfalls aus der tb_Mitglieder raus
Der Werdegang, so wie du ihn in der Feldbeschreibung schilderst muss in eine eigene Tabelle!
Die Zahlungsart kannst du in der Tabelle nicht als Optionsfeld darstellen - ebenfalls eine eigene Tabelle und den Zahlungsart_key dann in die tb_Mitglieder.
Dann gibt es in der tb_Mitglieder beim Feld 'Inventar_key' eine ganz interessante Feldbeschreibung:
ZitatWas hat das M wann wieviel gekauft? (Für Kassier wegen Rechnung....
Das solltest du auf jeden Fall in einer eigenen Tabelle festhalten - Verkäufe an Mitglieder lassen sich nur so auswerten.
Für die Speicherung von Daten rund um verliehene Orden an Mitglieder
erstellst du eine neue Tabelle ... z.B. tb_MitgliederOrden
Felder:
Mitglieder_key ---- Zahl, Long
Orden_key ------- Zahl, Long
OrdenVerliehen ------ Datum
OrdenUeberreicht --- Datum
VerleihBemerkung --- Text
Keine Leerzeichen/Sonderzeichen, keine Umlaute in Feldbezeichnungen, etc.
Benötigst du für die Bemerkungsfelder in den Tabellen wirklich mehr als 255 Zeichen (Memofeld)?
Zitatich habe die idee, alles gleich in einer inventarliste zu speichern wieder verworfen....
Was meinst du damit?
Du musst sowieso deine tb_Inventar befüllen, ob dir das gefällt oder nicht ;)
Über ein geeignetes Formular geht das schon ...
Du brauchst natürlich nicht 100x Hemd eingeben, das wählst du AM FORMULAR aus einer Dropdownlisteaus, das seine Daten aus der tb_InventarTyp bezieht ...
Zitatund sinn macht das ja auch nicht
... doch, doch, so schon! ;)
Na dann - an die Arbeit und die obigen Änderungen einmal einarbeiten
Hallo Peter,
danke für die Übersicht und Hilfe.
Ja, die von dir angesprochenen überflüssigen Felder in der tb_Mitglieder habe ich auch schon entdeckt und entfernt.
Bei der Inventarisierung habe ich mich nicht recht ausgedrückt und du hast nochmals das bestätigt, was ich meine. Mir ging's darum, daß ich nicht händisch die 100 verschiedenen, aber gleichnamigen Artikel eintragen wollte (die Tabelle hast du ja entdeckt). Meine Lösung gefällt dir ja. :) Danke.
ZitatBenötigst du für die Bemerkungsfelder in den Tabellen wirklich mehr als 255 Zeichen (Memofeld)?
Hmmmm. War es nicht so, daß ein Memofeld nur dann Speicherplatz benutzt, wenn es befüllt wird? Und nur soviel, wie es wirklich benötigt? Irre ich mich? Was hast du "gegen" das Memofeld? (damit ich den Gedankengang verstehe) Wenn das mittlerweile nicht mehr zutrifft, kann ich as wieder ändern.
Jetzt zu dem, was ich nicht kapiere, ich evtl. nochmals Deine Idee bzw. Vorschlag zum Aufbau brauche:
Wenn ich den Werdegang in eine eigene Tabelle verlagere, welche Felder machen Sinn? Es soll da ja nicht nur die Beurlaubungszeit rein, der Aktivitätsstatus, oder wann das Mitglied welchen Posten (davon evtl auch mehrere) hat(te), sondern auch persönliche Dinge: Hilft gerne mit beim Standaufbau, muß vom Alkohol ferngehalten werden, kann gut trommeln, hat die Vereinskasse geleert und wird darum ausgeschlossen.... Und wie Verknüpfe ich am sinnvollsten?
Darum habe ich das wegen der vielen Möglichkeiten so lösen wollen. Wobei aber gerade der Zeitverlauf extrem viel Sinn macht, auf das du wohl anspielst....Grübel
ZitatDas solltest du auf jeden Fall in einer eigenen Tabelle festhalten - Verkäufe an Mitglieder lassen sich nur so auswerten.
kann ich das nicht über die schon erstellte tb_Ausgabe realisieren? Dafür war sie eigentlich gedacht. Oder macht es Sinn, wenn ich den Verkauf vom Verleih trenne?
Danke für die Hilfe und Geduld. Bin grad dran und versuche mich wieder einzulesen in die dicken Wälzer und im Forum, damit ich bald nicht mehr fragen muß. :-[
Hallo,
ich habe nix gegen ein Memofeld, nur als Datenspeicher für eine 'Bemerkung' scheint's mir einfach zu groß.
Bezüglich Werdegang - nun ja eine Werdegang_ID und ein Textfeld für die Aufnahme der Beschreibenden Texte sowie ein Datumsfeld um den Zeitpunkt der Dateneingabe zu speichern sollte eigentlich genügen. Da mehrere Einträge für ein bestimmtes Mitglied möglich sind/sein müssen, ist das ganze dann über eine Zwischentabelle mit der tb_Mitglieder in Beziehung zu setzen.
Anzeige in HaFo / UFo- Konstrukt ist danach realisierbar.
zu den Verkäufen:
Zitatkann ich das nicht über die schon erstellte tb_Ausgabe realisieren?
Nein, das ist nicht richtig - Verkäufe sind im eigentlichen Sinn zwar auch Materialausgeben, haben aber eine Besonderheit - sie kosten oder bringen was.
Die Datensätze der Verkäufe lassen sich per Abfrage auch mit den Ausleihen kombinieren, sodass ersichtlich wird was ein Mitglied geliehen UND gekauft hat.
Selbstverständlich kann auch dieses in HaFo / UFo Technik getrennt dargestellt werden (Ausleihen und Verkäufe in jeweils eigenen UFos am gleichen HaFo.
Warte aber noch mit der Formularsache - stell mal die Tabellen alle richtig und lade das fertige DB-Modell nochmal hoch
Guten Morgen,
habe heute Nacht die Ärmel hochgekrempelt und gewerkelt. Allerdings wird es jetzt etwas unübersichtlich. Kannst du dir den Anhang bitte nochmal anschauen und - speziell bei den Rechnungen - die Verknüpfungen kontrollieren? Ich sehe vor lauter Wald die Bäume nicht mehr...
Danke
Hallo,
Zitathabe heute Nacht die Ärmel hochgekrempelt und gewerkelt
Sehr löblich!
Die Sache mit den Orden und dem Werdegang hast du richtig gelöst.
Bei den Rechnungen bist aber dann leider wieder ins alte Schema verfallen ... ;)
Ich habe das berichtigt - die Tabelle 'tb_InventarRechnung' wird nicht benötigt, die kannst löschen.
In die tb_MitgliederRechnung habe ich das Feld Mitglieder_key aufgenommen - sonst weiß man ja nicht für wen die Rechnung erstellt wurde.
Weiter habe ich die Tabelle tb_RechnungDetails erstellt, in der befindet sich der Inventar_key (was wurde gekauft?) , die Anzahl (wieviel wurde gekauft?) und der Einzelpreis (was wurde dafür bezahlt?)
Bei einigen anderen Tabellen habe ich noch Umlaute und Leerzeichen aus den Feldnamen genommen.
OK, so schaut's recht gut aus!
Die geänderte Version findest du im Anhang.
danke fürs helfen.
dachte ich mir doch mit den Rechnungen. aber irgendwie habe ich nicht mehr Durchgeblickt. ich hatte es erst über die Mitglieder_ID verknüft, dann aber wieder verworfen, weil ich dachte: woher weiß man denn, wer welche rechnung erhalten hat....?
Hoppla, da kommt mir schon das nächste Problem: Wenn ich eine Rechnung habe, gründet die doch auf einer Anfrage des Mitglieds (also einem Auftrag) :-X....ups das wird immer mehr und unübersichtlicher.
Ich werde beide Versionen mal nebeneinander halten, und schauen, wo du noch die Umlaut und die Leerzeichenfehler gefunden hast. Ich dachte, dass ich das von vornherein unterbunden hätte.
Edit: ja, habe die Fehler gefunden (sogar ohne Gegenüberstellung), aber die wären mir NIE aufgefallen. Aber habe dazu den Fokus auch verloren. Sorry, wenn ich nicht gleich alle deine Anweisungen vollständig ausgeführt habe.
Hallo,
ZitatWenn ich eine Rechnung habe, gründet die doch auf einer Anfrage des Mitglieds (also einem Auftrag)
Langsam, langsam, ... arbeitest du dabei mit Auftragsnummern oder würde da nicht nur ein Auftragsdatum-Feld in der tb_MitgliederRechnung genügen?
ZitatSorry, wenn ich nicht gleich alle deine Anweisungen vollständig ausgefüllt habe
Na, na, na, das hier ist ein Selbshilfe-orientiertes Forum und kein sibirisches Straflager .... ::) ;D ;)
Zitat von: database am März 09, 2014, 10:55:03
Hallo,
ZitatWenn ich eine Rechnung habe, gründet die doch auf einer Anfrage des Mitglieds (also einem Auftrag)
Langsam, langsam, ... arbeitest du dabei mit Auftragsnummern oder würde da nicht nur ein Auftragsdatum-Feld in der tb_MitgliederRechnung genügen?
Keine Ahnung. Damit habe ich mich noch gar nicht beschäftigt. Die zweite Lösung hört sich einfacher und schneller an - die muß genügen.
Wie ich gesehen habe, hast du noch eine tb-Mitglieder_1 erstellt für die Frage des Paten. War meine Lösung nicht gut? Ab wann hätte sie Ärger gemacht?
Hi,
dann lass die Geschichte mit den Aufträgen und nimm einfach nur ein 'Antragsdatum' in die Rechnungsdatei auf - so kann auch festgestellt werden, wann ein Antrag gestellt wurde.
Ich habe keine extra Tabelle erstellt, dabei handelt es sich nur um ein Alias, das entsteht, wenn eine Tabelle ein weiteres mal in das Fenster geholt wird. Ich habe das gemacht um die Patenschaft in Beziehung zu setzen. 8)
so,
jetzt hast du mich total verwirrt: du hast eie tb_RechnungsDetails erstellt. die hat keinen primärschlüssel. trotzdem ist sie verknüpft mit anderen Tabellen. Ist das Absicht -und wenn ja warum?
p.s. das Auftragsdatum wurde hinzugefügt.
Hallo,
Zitat...tb_RechnungsDetails erstellt. die hat keinen primärschlüssel ...
Das ist die n-Seite der 1:n Beziehung zur tb_MitgliederRechnung, die braucht nicht zwingend einen Primärschlüssel.
Jeder Datensatz in dieser Tabelle steht mit genau EINEM Datensatz der tb_MitgliederRechnung in Beziehung.
Die Beziehung zur tb_Inventar wird benötigt um den Fremdschlüssel zum Inventar zu erfassen.
Es kann nur Inventar in der tb_RechnungsDetails erfasst werden, das eine Entsprechung in der tb_Inventar hat - daher die 1:n Beziehung zwischen diesen beiden Tabellen.
Hoffe das war verständlich :)
Zitat von: database am März 09, 2014, 21:23:59
Hallo,
Zitat...tb_RechnungsDetails erstellt. die hat keinen primärschlüssel ...
Das ist die n-Seite der 1:n Beziehung zur tb_MitgliederRechnung, die braucht [bold]nicht zwingend[/bold] einen Primärschlüssel.
Jeder Datensatz in dieser Tabelle steht mit genau EINEM Datensatz der tb_MitgliederRechnung in Beziehung.
....
Hoffe das war verständlich :)
ja, teilweise. Durch die beiden Fremdschlüssel sind also Indizes vorhanden, und darin werden die Details der Rechnung, also was und wieviel dargestellt.
Wenn ich jetzt aber ein "1-click" Formular erstelle, dann erhalte ich jetzt nicht wie angenommen ein Formular Rechnung mit den Rechnungdetails, sondern eines ohne diese Verknüpfung. Fehlt mir noch ein Schritt?
Das mit den Unterformularen ist mir noch nicht so ganz klar. Die Struktur insoweit ja, aber wie ich das dann entsprechend dargestellt bekomme noch nicht....Ich muß noch etwas mehr lesen und begreifen.
Eine Kleinigkeit ist mir noch aufgefallen, die noch nicht vorhanden war und die ich ergänzt habe. Es fehlte die Mengenangabe im Inventar, sonst kann ja am Schluß nicht gerechnet werden bzw. ein Überblick stattfinden.
Nächstes Problem beim Durchspielen auch noch erkannt: Gebe ich einen Artikel an ein Mitglied aus dem Lagerbestand "F1" aus, befindet er sich ja nicht mehr am gleichen Ort, also beim Mitglied. Somit muß ich also auch die einzelnen Mitlgieder als Lagerstätte führen....(werde mal anfangen zu bauen)
Mir schwebt vor, daß Artikel, die nicht mehr am Lager, sondern ausgeliehen sind, im Formular dann nicht mehr auf der linken Seite (der Ausgabeseite), sondern z.b. in einer Spalte auf der rechten Seite steht. Würde das gehen? z.b. über das Eintragen des Ausgabedatums, nach verlasen des Formularfeldes, soll die Anzeige aktualisiert werden.
Das soll aber nur für die Artikel stattfinden (über die anderen bekommen die Leute ja eine Rechnung), die ausleihbar sind. Das Attribut in der Inventartabelle habe ich schon erstellt.
Hallo,
ZitatWenn ich jetzt aber ein "1-click" Formular erstelle, dann erhalte ich jetzt nicht wie angenommen ein Formular Rechnung mit den Rechnungdetails, sondern eines ohne diese Verknüpfung. Fehlt mir noch ein Schritt?
Du benötigst ein HaFo / UFo Konstrukt dafür - also ein Formular, an dem beide Tabellen beteiligt sind.
ZitatSomit muß ich also auch die einzelnen Mitlgieder als Lagerstätte führen
Nein, das nicht, ich habe zwar die DB derzeit nicht zur Verfügung aber die Ausgabe sollte in einer Zwischentabelle gespeichert sein - damit solltest du das Mitglied und dessen Ausgaben bestimmen/ermitteln können.
ZitatMir schwebt vor, daß Artikel, die nicht mehr am Lager, sondern ausgeliehen sind....
Mit VBA lässt sich ein Bestand auch hinter den Mond schreiben - soll heißen - alles ist möglich ;)
hallo,
die Idee mit der Zwischentabelle hatte ich. Leider konnte ich bei der Verknüpfung keine ref. Integr. herstellen, MSA verwies auf eine Fehlerhafte Struktur in der tb_Inventar...somit verwarf ich das jetzt wieder. :-\
Zur eigentlichen Idee wie ich sie umsetzen wollte: tb_LagerStelle, darin ein Primärschlüssel LagerStelle_ID, Mitglieder_key, LagerOrt_key und Bemerkung. die Verknüpfung zu tb_Mitglieder via Mitglieder_ID und Mitglieder_key klappte. Auch LagerORt_ID zu LagerOrt_key. Aber nicht die Verknüpfung von tb_Lagerstelle zu tb_Inventar.
Zitat
Zitat
Wenn ich jetzt aber ein "1-click" Formular erstelle, dann erhalte ich jetzt nicht wie angenommen ein Formular Rechnung mit den Rechnungdetails, sondern eines ohne diese Verknüpfung. Fehlt mir noch ein Schritt?
Du benötigst ein HaFo / UFo Konstrukt dafür - also ein Formular, an dem beide Tabellen beteiligt sind.
damit habe ich null ahnung. wie mache ich so was? Kleine Hilfestruktur?
danke
habs mal hochgeladen
Habe jetzt leider keine Zeit, ich muss gleich weg.
Ich habe dir in der Schnelle ein ganz einfaches HaFo/UFo erstellt ... schau dir das mal an.
hi,
Unterformular erstellen klappt. habs gerade erlernt. Nehem aber trotz allem Dein Anhang gerne an.
merci
Hallo,
bitte vergiss nicht, dass mein Vorschlag zum Design von Rechnungen / Rechnungsdetails nur ein einfacher Vorschlag war.
Du musst diese Tabellen deinen tatsächlichen Bedürfnissen noch anpassen und Felder aufnehmen, die du zu DEINEN Informationszwecken benötigst.
Aber ACHTUNG - keine berechneten Werte speichern!
Hi,
danke für den Tipp. So weit bin ich noch gar nicht. Ich habe festgestellt, dass du bei deinem Muster des UFO nicht einen Wert aus der cmb-Liste genommen hast, sondern in der tb_Inventar auf das neu erstellte Feld Inventar_Name zugreifst. Da ich ja für das die tb_inventar schon ein Formular erstellt habe, indem ich ein cmb auf das Feld InventarTyp_key erstellte und dann auf die "Sammelnamen" zugreifen kann (damit ich jetzt genauer differenzieren und die Attribute hinzufügen kann), wollte ich das mal "schnell" ändern. ..... uff.
Das ist leider nicht so einfach mit einem UFO zu bewältigen, wie bei einem normalen Formular. Noch bin ich an der Suche, wie ich den zweiten Listeneintrag so reingestellt bekomme, daß es für den user leserlich bleibt. Der Umweg über ein neu erstelltes Feld bzw. über die Abfrage bringt nicht den Erfolg. Hast du eine Idee?
danke und grüße
EDIT:
Habe doch den Umweg gefunden, damit ich es wie gewünscht ansprechen kann:
durch die Funktion [Ereignisprozedur]im Eigenschaftsfeld "Nach Aktualisierung" gab ich in den Editor das ein:
Private Sub InventarTyp_key_AfterUpdate()
Me!Inventar_Name = Me!InventarTyp_key.Column(1)
End Sub
so langsam kommt's wieder
Hallo Alex,
wenn du keine Fragen mehr zum Tabellenaufbau deiner DB hast, solltest du dieses Thema abschließen um den Thread nicht unnötig in die Länge zu ziehen.
Selbstverständlich sind wir weiter gerne bereit Fragen, die sich in der Folge bei der Erstellung und Gestaltung von Formularen usw. ergeben, in neuen Threads zu beantworten.
LG
Lieber Peter,
soweit mal herzlichen Dank.
Ich bräuchte nur nur noch einmal Deinen Überblick über die Beziehungen, denn in den vorigen Posts berichtete ich ja von dieser Fehlermeldung, die es mir nicht zuläßt eine refernzielle integritive Verbindung zu erstellen. Könntest Du mir da bitte auf die Schliche helfen?
vielen lieben Dank.
Zitat von: bluewalk am März 10, 2014, 15:52:07
hallo,
...Leider konnte ich bei der Verknüpfung keine ref. Integr. herstellen, MSA verwies auf eine Fehlerhafte Struktur in der tb_Inventar...
..... Verknüpfung von tb_Lagerstelle zu tb_Inventar.
danke
Ich poste es jetzt extra so rein, damit es erkenntlich wird (zumindest für mich):
Das Problem habe ich gelöst, mit der tb_Inventar. Darin mußte ich den Schlüssel LagerOrt_key löschen. Dann konnte ich wie gewünscht die Zwischentabelle mit einbeziehen.
Meine Lektüre ist ebenfalls zur Hand und ich lese mich grade in die Neuerungen der versch. Versionen ein.
Danke für Eure Unterstützung.
Den Thema kann geschlossen werden.