Hallo zusammen,
ich habe mal wieder ein Problem. Ich habe ein Hauptformular ,,frm_Main" und mehrere Unterformulare ,,Ufo1;Ufo2"nun muss ich zum Teil die Tabellen in den Unterformularen bzw. die Unterformulare komplett wechseln.
1 ) Was für Ereignisse werden bei einem Tabellenwechsel im Unterformular bzw. Hauptformular ausgelöst?
2 ) Wie wechselt man Unterformulare im Hauptformular und was für Ereignisse werden dabei ausgelöst(Unter und Hauptformular)
Ich hoffe jemand weis darüber Bescheid
Danke und Gruß Dieter
Hallo,
jedes UFO-Steuerelement hat u. a. die Eigenschaften
Herkunftsobjekt
Verknüpfen von
Verknüpfen nach
Die VBA-Namen (mit Beschreibung) erhältst Du , wenn Du die Schreibmarke im Form-Entwurf in die Eigenschaftenzeile setzt und F1 drückst.
Diese kannst Du per VBA nach Deinen Wünschen einstellen.
Wird ein Form-Name der Eigenschaft SourceObject zugewiesen, dann treten alle Ereignisse im (Unter)Form auf, die auch auftreten, wenn das Form einzeln für sich geöffnet/geladen wird.
Der Zugriff auf das Unterform erfolgt über die Eigenschaft "Formular" ("Form") des UFO-Steuerelementes.
siehe auch:
www.donkarl.com/?FAQ4.8
Hallo DF6GL,
der Hintergrund ist folgender, in meiner Turnierdatenbank werden mehrere Turniere gleichzeitig gespielt, diese Turniere sind in Tabellen, der Ablauf soll in den Unterformularen per VBA programmiert werden. Bei einem Turnierwechsel um Z.B. ein Ergebnis einzutragen, müsste jetzt nur die tabelle gewechselt werden, aber es sind auch noch Variablen aus anderen Tabellen zu erneuern usw. deshalb müste ich wissen ob auch noch Ereignisse bei einem Tabellenwechsel im Unterformular/Hauptformular auftreten. Oder wie man solche Ereignisse erzwingt. Sobald sich das Turniersystem (KO-Systen; SchweizerSystem) ändert muss das Unterformular gewechselt werden, da dort ein anderer Turnierablauf programmiert werden muss.
Beim Unterformularwechsel (Sourceobjekt) im Control des Hauptformulars das neue Unterformular angeben. Da dieses dann geöffnet wird, treten alle Ereignisse (im Unterformular) wie beim normalen Öffen des Formulars auf. (ist eigentlich logisch).
Treten aber auch im Hauptformular dabei Ereignisse auf? und was für Ereignisse werden bei einem Tabellenwechsel im Unterformular bzw. Hauptformular ausgelöst? oder wie kann man welche erzwingen damit ich im Programm darauf reagieren kann.
Danke und Gruß Dieter
Hallo,
mir ist nicht ganz klar, was Du damit vorhast....
Du(!) steuerst doch keine Ereignisse, die dann irgendwelchen Code von Dir ausführen...
Du reagierst auf Ereignisse, die auftreten, wenn Du mit einem Objekt interagierst. Wenn Du ein UFO (wie auch immer ) umstellst und es wird dabei eine bestimmte Reaktion auch im HF benötigt, dann kannst Du doch diese Reaktion (Prozedur) gleich "ausführen" und nicht erst ein Ereignis provozieren, das dann diese Reaktion (Ereignisprozedur) veranlasst...
(Beim Umstellen der ObjectSource-Eigenschaft des UFOs könnte (!) allenfalls das Ereignis "Beim Anzeigen" des Hauptforms auftreten, da bin ich aber jetzt überhaupt nicht sicher, habe das nicht getestet.... und auch noch nie gebraucht.)
Hallo,
es kann sein, dass ich über das Ziel hinaus denke bzw. den Wald vor lauter Bäumen nicht sehe aber die Idee war, dass ich den ganzen Turnierablauf im Unterformular schreibe. Also habe ich gewisse Ereignisse ausgenutzt um Reaktionen hervorzurufen. Da ich die Reaktionen im Ufo schon habe dachte ich mir, dass wenn ein Ereignis beim Tabellenwechsel ausgelöst wird, ich auf den bestehenden Code verweisen kann. Natürlich hast du recht, dass man schon bei dem Ereignis welches den Tabellenwechsel auslöst auf diese Reaktionen verweisen kann, aber dann muss ich die Funktionen nochmals umschreiben und in Module auslagern, oder kann man von einem Ufo den Code des anderen Ufos aufrufen?
wie ich hier schon öfters gesagt habe bin ich Anfänger was VBA bzw. Access betrifft und für jede Hilfe und Tip dankbar
Gruß Dieter
Hallo,
wenn Du alles in den Unterformularen schreibst, ist es egal. ob die Formulare einzeln oder als UFO aufgerufen werden....Voraussetzung, Du hältst die Kapselung ein, d. h. keine Referenzen auf andere Formularnamen verwendest.
"kann man von einem Ufo den Code des anderen Ufos aufrufen"
Wenn ein Formular zur bestimmten Zeit nur einmal geladen ist, also nur als UForm, dann könnte gehen:
Form_Formularname.Prozedurname
und wenn diese Prozedur als Public deklariert ist.
Trotzdem verläßt/umgehst Du die Kapselung von Formularen, und das Ganze wird sehr fehlerträchtig werden.
"wie ich hier schon öfters gesagt habe bin ich Anfänger was VBA bzw. Access betrifft "
man hat aber sicher auch schon gesagt, dass Dein DB-Konzept (was ich nicht kenne) vermutlich nicht ganz astrein ist....Ob Du nun Änfänger bist oder nicht, Access kümmert sich dadrum nicht..
Hallo Franz,
Sorry dass ich mich erst heute wieder melde.
Ja das Datenbank-Konzept ist so eine Sache, ich versuche immer keine Doppelte Datenhaltung in den Tabellen. Zur Zeit habe ich 4 Tabellen die sich nicht berühren das sind je 1 Tabelle Für die Spielfelder, Teilnehmer(alle), Turniere und allgemeine Angaben zum Event, wenn nun ein Turnier erstellt wird werden zwei weiter Tabellen generiert und zwar eine Tabelle Spieler (hier können nur Personen ausgewählt werden die in der Tabelle Teilnehmer vorhanden sind und eine tabelle Spielplan die wiederum auf die tabelle Spieler zurückgreift. Da mehrere Turniere gleichzeitig möglich sein sollen(auch mit gleichen Teilnehmern) werden für jedes Turnier diese beiden Tabellen erzeugt. Ach ja ich habe noch Hilftsabellen (sind eigenständige Tabellen die nicht verändert werden) z.B. Freilos Verteilung hier greifen die Spielplantabellen zurück um die fehlenden Spieler durch freilose zu ersetzen.Also bis jetzt geht sich das ganze recht gut an.
Aber scheinbar kann mir keiner auf meine Frage mit den Ereignissen bei Tabellenwechsel im Unterformularen einen Tip geben. Wenn das so ist muss ich die einige Funktionen umschreiben und in Module verschieben.
Gruß Dieter
Hallo,
ohne Kommentar zu den Tabellen, nur zu den Ereignissen:
Habe es Dir alles schon gesagt.
Um festzustellen, welche Ereignisse bei einem bestimmten Vorgang feueren , könntest(!) Du für jedes Ereignis (der Formulare und der UFP-Steuerelemente) jeweils eine Prozedur einbauen, z. B. für das Form-Ereignis "Beim Anzeigen:
Sub Form_Current()
Msgbox "Ereignis 'Beim Anzeigen' aufgetreten"
End Sub
oder auch mal hier lesen:
http://office.microsoft.com/de-ch/access-help/reihenfolge-von-ereignissen-fur-datenbankobjekte-HP005186761.aspx
Hallo,
sorry, wenn ich da eine Meldung absetze...
ZitatZur Zeit habe ich 4 Tabellen die sich nicht berühren
Was verstehst du denn darunter? Willst du damit andeuten, dass die Tabellen nicht in Beziehung gesetzt sind?
Zitatwerden für jedes Turnier diese beiden Tabellen erzeugt
Nachdem mehrere Turniere gleichzeitig statfinden können, nehme ich an, dass du für 5 gleichzeitige Turniere dann insgesamt 10 Tabellen zur Laufzeit erzeugst?
Wenn das so ist, nenne ich es einen interessanten Ansatz.
Was machst du denn dann mit den Tabellen die zuviel in der DB stehen? Schmeißt du die dann raus (löschst du die einfach wieder) wenn statt 5 Turnieren nur 3 stattfinden?
Mannomann - entschuldige bitte, aber mit dem Konzept wirst du auf Dauer nicht glücklich werden!
Hmmm... warum legst du denn die UFos nicht mit fix definierter Dateherkunft gleich richtig an und platzierst sie in einem Registersteuerelement
dann ersparst du dir dieses unseelige Gewürge mit dem ständigen Umschreiben der Datenherkunft.
Insgesamt fällt mir auf, dass du da einige Begrifflichkeiten wahllos zusammenwüfelst ... z.B. " aber es sind auch noch Variablen aus anderen Tabellen zu erneuern "
Es ist ja absolut nichts Verwerfliches dran, wenn man Anfänger ist - jeder fängt irgendwann mal an - dein Vorhaben scheint mir aber dann schon etwas komplexeres zu sein,
weshalb ich dir ganz ganz warm ans Herz legen möchte, die Linkliste in der Signatur von DF6GL rauf und runter INTENSIV durchzuackern!
Hallo Database
Genau so ist es diese 4 Tabellen stehen in keiner Beziehung zueinander, und du hast recht dass bei 5 Turnieren 10 Tabellen erzeugt werden, die nachdem der Event beendet ist wieder gelöscht werden, für was soll man diese noch weiter verwalten. Der Spielplan mit den Ergebnissen wird Ausgedruckt falls noch Rückfragen sind. Im Prinzip verwalte ich nur diesen Event das löschen könnte ich mir auch sparen und für jedes Großturnier einfach eine Kopie der Originaldatenbank machen.
Das mit dem Registersteuerelement habe ich mir am Anfang auch überlegt (Ein Turnier = eine Registerseite) aber wieder verworfen, da ich ja für jedes Turnier noch mal ein Objekt Unterformular erzeugen müsste. oder geht das, dass ich ein und dasselbe Unterformular(Objekt) in zwei Registern platziere mit verschiedener Datenherkunft?
Mit den Begrifflichkeiten hast du völlig recht, da muss ich noch einiges tun.
In deinem Beispiel meinte ich natürlich, dass ich ungebundene Felder mit dem Inhalt von Tabellenfelder füllen muss.
Sorry für meine Unwissenheit ich hoffen dass das mit der Zeit besser wird.
Gruß Dieter
Hallo,
wenn ich deinen Ausführungen so folge, kommt mir der leise Verdacht, dass du diese Turnierverwaltung schon mal mit Excel versucht hast.
Zitateinfach eine Kopie der Originaldatenbank machen
Man kann aber auch Daten löschen, die man nicht mehr benötigt ohne die ganze Datenbank zu kopieren.
Du besorgst dir ja auch sicher kein neues Auto, wenn beim aktuellen der Tank leer ist. :D ;D 8)
Zitatfür was soll man diese noch weiter verwalten
Du brauchst dich eigentlich nicht um die Tabellenverwaltung kümmern, das macht Access alleine, deine Aufgabe besteht darin, vernünftige und schlüssige Daten in geeigneten Tabellen mit Hilfe von gut durchdachten Formularen zu sammeln. Wobei genau dieses oftmals schwierig wird, wenn das Tabellenkonzept nicht stimmt. Daher auch der dringliche Hinweis auf die Linkliste von DF6GL!
Zitat...da ich ja für jedes Turnier noch mal ein Objekt Unterformular erzeugen müsste...
Sollte per Copy & Paste, umbenennen und anpassen keine Jahresaufgabe darstellen.
Du kennst selbst die maximal mögliche Anzahl von Turnieren und wenn dieses 10 lautet, gibts halt 10 Unterformulare - ja mei.. Access wird's überleben :)
Zitatdass ich ungebundene Felder mit dem Inhalt von Tabellenfelder
...und warum müssen die ungebunden sein?
Franz hat schon einmal drauf hingewiesen, dass das Datenmodell ev. unstimmig sein wird - ich glaube, dass er da nicht unrecht haben wird.
Zur ganzen Sache mit den Events vielleicht noch ein Hinweis - man kann mit VBA sehr viele Dinge bewerkstelligen, was aber nicht bedeuten soll, dass man sich um das Fundament einer Applikation nicht kümmern muss. Events (Ereignisse) auszulösen ohne dass sie real stattfinden macht m.E. recht wenig Sinn, wenn die Abläufe nicht 100%-ig festgelegt sind.
Es wird auch nicht recht viel bringen, wenn du nun Routinen zusammenschiebst, die Tabellen hin und her transferieren, wenn beim Starten der Applikation noch gar nicht bekannt ist, welche Tabellen es eigentlich heute gibt, und morgen vielleicht nicht mehr.
Verstehst du, das habe ich hier angesprochen...
Zitat...aber mit dem Konzept wirst du auf Dauer nicht glücklich werden!
EOF
Peter
Hallo,
ihr versteht es einem richtig Mut zu machen.
Trotzdem Danke und Gruß Dieter
Na na, nicht gleich den Kopf hängen lassen!
Die Hinweise sind allesamt nicht dazu gedacht dir die Butter vom Brot zu stehlen sondern dir zu zeigen,
dass es eine Möglichkeit gibt die richtige Auftragestärke automatisch zu bekommen ;D
Es ist halt auch ein wenig verwirrend, wenn du von Ereignissen sprichst, die du auslösen lassen möchtest ohne dass wir wissen WOZU.
Das Ändern der Datenherkunft eines Formulars ist ja keine Hexerei.
Die ganze Sache soll halt auch Sinn machen und vor allem funktionieren.
Das Problem liegt daran, dass dieser Wechsel im Code niedergeschrieben ist.
Wenn du nun wahlfrei Tabellen erstellst und wieder verwirfst wirds ein wenig schwierig das im Code abzubilden,
speziell wenn möglicherweise Tabelle XY nicht mehr existiert oder ABC noch nicht erzeugt ist.
Grüße
Peter
Hallo Database,
keine Angst ich mach schon weiter mit meinen Projekt, so schnell gebe ich nicht auf.
Zitat von: database am November 19, 2010, 11:40:07
wenn ich deinen Ausführungen so folge, kommt mir der leise Verdacht, dass du diese Turnierverwaltung schon mal mit Excel versucht hast.
Da hast du nicht ganz unrecht, und die Excel Turniervorlagen funktionieren auch. Was man aber dort nicht machen kann ist die Spielerverwaltung ( welcher Spieler spielt gerade in welchem Turnier und an welchem Automat) dafür ist excel einfach nicht geeignet. Ich hab mir auch lange überlegt wie ich einen solchen Turnierablauf in Access abbilde und was für Tabellen brauche ich. Natürlich muss ich sehr sauber in VBA Programmieren das ist mir schon klar und dass ihr in Sachen Datenbank Konzept mehr drauf habt als ich weis ich natürlich auch.
Ich hab mir auch mal die Links (deinem Rat folgend) von DF6GL angeschaut da sind ein paar sehr interessante Sachen dabei.
Gruß Dieter
Hallo,
ich habe keine Angst - den Zustand kenne ich nicht :)
Auf Excel habe ich wegen deinem Zugang zum Problem getippt - der ist nämlich sehr Excel-lastig.
Das Tabellen konzept von Access entspricht 1:1 einer ordentlichen relationalen Datenbank, auch wenn manche Kritiker das immer wieder verbissen in Abrede stellen wollen.
Excel hingegen ist und bleibt eine Tabellenkalkulation die zwar datenbankähnliche Funktionalitäten bietet aber ein Worksheet nicht annähernd einer Datenbanktabelle entspricht.
Wenn du also von Excel nach Access wechseln willst oder musst, musst du ein neues Progeramm erlernen, dich mit Datenbanktechnik und -design beschäftigen und Excel vollkommen ausblenden.
Willst du Automatismen implementieren kommen dann noch VBA und wenn du die eingegebenen Daten auch jemals wieder asehen möchtest (na no na net ;)) für die Abfragetechnik SQL hinzu.
Wie du siehst ein recht komplexes Thema, das nicht mal so auf die Schnelle nebenher erledigt ist ;)
Wichtig ist in erster Linie ein klares, richtig und vollständig definiertes Konzept darüber, was du machen willst und was am Ende Access für ein Ergebnis liefern soll.
Dabei sind viele Überlegungen notwendig, besonders darüber welche Daten überhaupt benötigt werden und welchen Typs die sein sollen.
Diese bringt man dann in ein Ablaufszenario, also ein Art Ablaufbeschreibung, aus der ein ERM (Entity Relationship Model) gezeichnet wird.
Diese graphische Darstellung der Sachverhalte liefert die Grundlage für das Relationenmodell und in der Folge für den physikalischen Tabellenentwurf.
Es ist m.E. dabei völlig unerheblich ob nun eine Datenbank aus 4, 14 oder 40 Tabellen besteht, der Vorgang der Planung ist IMMER der selbe
und nur wenn der fehlerlos ausgeführt wurde funktioniert das Produkt am Ende auch so, wie man es sich vorgestellt hat ode wie's bestellt wurde.
Also... an die Arbeit!
Grüße
Peter
Bin schon wieder mitten drin in der Arbeit .
Bis dann Dieter