piomode1

Hi, Graf Koks! Ich vermute, das Problem taucht in einem Bericht auf?! Es ist leider schon seit Access 2.0 so, daß einem Bericht die Abfragereihenfolge manchmal ziemlich egal ist (vor allem bei sortierten Datum/Zeitwerten. Da hilft nur eins: Im Berichtsentwurf die Schaltfläche 'Sortieren und Gruppieren' (die mit den drei blauen runden Klammern) klicken und dort die zu sortierenden Felder erneut eintragen. Dann sollte es funktionieren!

Hi, Sonic! Ich war etwas zu langsam... Deine Lösung würde mich wahnsinnig interessieren!! PS zu meiner Lösung: Den unschönen Rahmen um den Unterbericht bekommt man weg: Entwurf Hauptbericht, Eigenschaften Unterbericht, Rahmenart Transparent. Das Beschriftungsfeld des Unterformulars kann gelöscht werden; es stört hier nur.

Hi, Sonic83! Ich habe da eine Lösung: Du mußt die Datensätze mit Hilfe von zwei Abfragen 'trennen'! Hier der SQL-Text: aPunktHaupt ----------- SELECT tPunkt.xPunkt, Mid$([xpunkt],1,1) AS xPunktPunkt FROM tPunkt WHERE (((Mid$([xPunkt],2,1))=" ")); aPunktUnter ----------- SELECT tPunkt.xPunkt, Mid$([xpunkt],1,1) AS xPunktPunkt FROM tPunkt WHERE (((Mid$([xPunkt],2,1))=".")); Ich habe der Einfachheit halber nur das Feld 'xPunkt' in der Tabelle 'tPunkt' (NEIN, keine Schleichwerbung!) Nach Deiner Notation ist das zweite Zeichen ein Leerzeichen, wenn es sich um einen Hauptpunkt handelt; ein Punkt, wenn es ein Unterpunkt ist. Die beiden Abfragen filtern nach eben diesem Zeichen und stellen ein weiteres Feld mit der Hauptnummer zur Verfügung 'Mid$([xpunkt],1,1) AS xPunktPunkt'. Das brauchen wir gleich! Dann wird ein Bericht (der spätere Unterbericht) auf der Abfrage 'aPunktUnter' erstellt und gespeichert (z.B. 'bPunktUnter'). Das Feld 'xPunkt steht im Detailbereich. Ein weiterer Bericht beruht auf der Abfrage 'aPunktHaupt' und der Bericht 'bPunktUnter' wird als Unterbericht ebenfalls im Detailbereich eingefügt (so wie auch hier das Feld 'xPunkt'. Die Verknüpfung der beiden Berichte erfolgt über das berechnete Feld xPunktPunkt. AN ALLE: Benutzt nach Möglichkeit beim Verknüpfen die Option 'Meine eingenen definieren'. Ansonsten KANN ein kleines Durcheinander entstehen! Auf beiden Seiten xPunktPunkt wählen. Speichern (z.B. unter 'bPunktHaupt'). Fertig. Meiner Erfahrung nach hält Access jetzt den Hauptpunkt mit den Unterpunkten zusammen. Sollte ein Seitenwechsel nötig sein, zieht der Hauptpunkt mit auf die nächste Seite. Erst wenn es mehr Unterpunkte gibt als auf einer Seite dargestellt werden können erfolgt ein Seiten wechsel mitten in den Unterpunkten. Dagegen ist kein Kraut gewachsen. Höchstens eine kleine Schriftart...

Hi, DannyUlm! 1) Den Zeilenumruch bekommst Du mit der Systemkonstanten vbCr Bsp: "Danny" & vbCr & "Ulm" ergibt Danny Ulm Ganz WICHTIG: Das Leerzeichen hinter vbCr, da das '&' ansonsten als Variablentypzeichen interpretiert werden könnte. (Wenn es dabei nicht schon vorher zu einem Fehler kommt...) 2) Wie ist Dein Problem mit der Schriftart zu verstehen? Du darfst nur die Zeichen übernehmen, die mit/in einer bestimmten Schriftart formatiert sind?

Hi, Wolle! Vielen Dank für Deinen Tip!! Manuell funktioniert es 100%ig! Jetzt muß ich mich nur noch durch die endlosen Zeilen Code in Deinem Link arbeiten; ich habe bis jetzt (mit wenig Zeitinvestition) nicht herausgefunden, was ich davon eigentlich genau brauche... Kannst Du nicht die Zeilen, die Du verwendet hast, evtl. hier einmal einfügen?

Hi, hades! Ich bin Access-Spezi. Andere Datenbanksysteme sagen mir (leider(!)) nicht viel . Ebenso die Portierbarkeit. Daher meine obigen 'Entscheidungen'. ----- Hi, SteffiMichi! Z.Zt. leider keine Zeit vorhanden, viel weiteres zu schreiben. Evtl. nächstes Jahr...!?

Hi, s35i! Folgender halbfertiger Vorschlag: Lese die fette Tabelle in ein fettes Array mit zwei Dimensionen ein. Danach kannst Du ja über die Indizes auf die einzelnen Felder zugreifen und Dein 'Durchzählen' realisieren!!?

Hi, Leute! Folgendes Problem: Wenn man Access öffnet, erscheint standardmäßig folgendes Dialogfenster: ----- o Leere Datenbank o Datenbankassistent o Öffnet eine bestehende Datenbank <Liste der bisher geöffneten Datenbanken> ----- Die Liste der 'bisher geöffneten Datenbanken' soll gelöscht werden. Geht das? Wenn ja: wie? Eine Access 2000-Lösung ist dringender; ich freue mich auch über Access 97-Vorschläge!

Hi, hades! SUPER! Mit Deinem Einwand, der Primärschlüssel kann auch aus mehreren Feldern bestehen, hast Du natürlich Recht. Ich habe an zitierter Stelle evtl. nicht deutlich darauf hingewiesen, daß es nur in diesem Beispiel so ist, daß der Primärschlüssel aus nur einem Feld besteht! Und sehr schön übersichtlich ist auch Deine Auflistung der x:y-Beziehungen. Noch ein Wort zu der undefinierten Verknüpfung: Access stuft (wie bereits geschrieben) eine Verknüpfung derart ein, wenn keines der beiden miteinander verknüpften Felder eindeutig ist. <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR> Original erstellt von hades Wie kennzeichnest Du folgende Datensätze der Tabelle tMitarbeiter mit minimalen Mitteln eindeutig? Meier, Entwicklung, 5000 Mueller, Entwicklung, 4500 Meier, Entwicklung, 5500 Schulz, Entwicklung, 3000

Hi FaFo! Ich hoffe, ich sehe das Problem nicht zu einfach: Bastel eine Abfrage, in der alle Tabellen, aus denen die Daten stammen, enthalten sind. Die einzelnen Tabellen sollten eigentlich über Felder verknüpfbar sein. Du willst bestimmt nur die Daten, die jetzt im Formular angezeigt werden. Dazu ist es in der Abfrage nötig, in einem eindeutiges Feld ein Kriterium zu setzen. (Z.B. Das Hauptforular [HF] zeigt einen Kunden, das Unterformular [uF] die zugehörigen Bestellungen.) In das Abfragefeld der Tabelle mit den Kunden-Daten, welches z.B. die Kundennummer (eindeutiges Feld) enthält, schreibst Du als Kriterium: =forms!<Name_des_HF>!<Name_des_HF_Feldes_Mit_Eindeutigem_Wert> Die Abfrage liefert nur (vernünftige) Werte, wenn das HF geöffnet ist. Sind das die richtigen Daten, wandelst Du diese Abfrage in eine Tabellenerstellungsabfrage (oder in eine Anfügeabfrage (bei dieser Wahl muß allerdings schon eine Tabelle existieren, die die gewünschten Felder aufnehmen kann)) um die Datensätze in eine andere Tabelle zu kopieren!

Hi, Durone! Die Funktion für den Wochentag lautet: _____ function WoTa(dMeinDatum as Date) as String Select Case weekday(iMeinDatum) Case Is = 1 WoTa="Sonntag" Case Is = 2 WoTa="Montag" Case Is = 3 WoTa="Dienstag" Case Is = 4 WoTa="Mitwoch" Case Is = 5 WoTa="Donnerstag" Case Is = 6 WoTa="Freitag" Case Is = 7 WoTa="Samstag" End Select End Function _____

Hi, Jogo! Versuche es doch einmal mit einer Abfrage, in der beide Tabellen drinstehen. Dann verknüpft Du ALLE Feldner miteinander, die die Eindeutigkeit ausmachen (z.B. Nachname mit Nachname, Vorname mit Vorname, Geburtsdatum mit Geburtsdatum, usw.) Ist tatsächlich nur die Typenbezeichnung ausschlaggebend und in beiden Tabellen eindeutig, genügt die Verknüpfung zwischen den Typenbezeichnungen!

Hi, FaFo! Naberius, ich muß Dir mal auf die Füße treten . Deine Function läuft, ABER wie wäre es mit folgender Lösung: Lege ein neues Modul im Datenbankfenster an. Dorthinein kommt folgender Code _____ Public Function CalcDmEuro(Betrag As Double, _ Optional Nachkommastellen As Integer = 2) As Double Dim NkSt As Integer NkSt = Nachkommastellen CalcDmEuro = (Int(Betrag / 1.95583 _ * 10 ^ NkSt + 0.5)) / 10 ^ NkSt End Function _____ Die Funktion hat folgende Vorteile: 1) Sie ist überall in dieser Datenbank verfügbar. Aufruf aus einem Formular: Lege ein ungebundenes Steuerlement an. Als Steuerelement schreibst Du: =CalcDmEuro([<Feldname_Mit_DM_Betrag>];[<Feldname_Mit_Nachkommastellen_Angabe>] 2) Die Anzahl der Nachkommastellen [NkSt] ist variabel; ist das NkSt-Feld leer (NICHT zu verwechseln mit 0), wird der Standardwert 2 verwendet. Ich habe eine kleine Beispiel-Datenbank geschrieben, die ich Dir/Euch zumailen kann. (Funktioniert das auch als Anhang einer PM?) Ansonsten werden von mir natürlich keine persönlichen e-mail-Adressen weitergegeben, komerziell genutzt usw, sondern nur einmalig, um die DB zu übermitteln!!!

Hi, Abe! Also, ein Formular wäre nicht schlecht. Darin könntest Du mit einer vorangestellten Checkbox alle Produkte ausgeben lassen, der User setzt dann Häkchen in die relevanten Produkte. Dann noch zwei kleine Optionsschaltflächen dazu, mit denen der User entscheiden kann, ob UND- oder ODER-verknüpt werden soll. Den Check- und Optionsschaltflächen unbedingt aussagekräftige Namen geben und ab in die VBA-Programmierung, die denn da so aussieht, daß ein SQL-String aufgebaut wird: Pseudo-Code: _____ If chkUnd=true then sVerknuepfung="and" Else sVerknuepfung="or" endif 'Für jede Produkt-Checkbox in diesen Formular: For Each chk in forms 'Wenn sie dann angehakt wurde... If chk.Value=true then '...ergänze den Sql-String SqlString=SqlString & sVerknuepfung & chk.Name End If Next _____ Der Sql-String muß dann noch mit 'Select(<Feld(er)> From <Tabelle(n)> Where' usw. ergänzt werden! Es kann so nicht klappen! Der Code-Abschnitt soll nur als Anregung denen dienen, die sich besser mit dem Aussehen von Sql-Strings auskennen!!! Es wird evtl. mit dem Sql-Operator IN gearbeitet werden müssen. Das kann ich nicht beurteilen, da ich nicht weiß, wie die Daten strukturiert sind!

Hi, CK82! Fragen: 1) Werden im Haupt- [HF] und im Unterformular [uF] Daten aus EINER Tabelle angezeigt? Wenn ja: Im Unterformular werden nicht alle Daten angezeigt, die im HF sichtbar sein sollen? 2) Wäre es nicht einfacher (möglich) die Darstellung umzukehren?: Im HF suchst Du über eine mit dem Steuerelement-Assistenten erstellte Kombo-Liste einen bestimmten DS und läßt dann im UF die zugehörigen Daten anzeigen. Anm zu Tiana Ry: 'Sub GetFocus()' wird (außer evtl. einer Fehlermeldung) überhaupt nichts bewirken. Soll eine Sub bei einer bestimmten Aktion ausgeführt werden, ist es unbedingt notwendig, daß a) sich der Code als Klassenmodul (gebunden an das Formular) in demselben befindet. Das zu erreichen ist kein Problem: Einfach in der Entwurfsansicht das entspr. Ereignis aussuchen und den Code-Editor aktivieren. Das führt dann zu der Erklärung, warum 'Sub GetFocus()' nichts bewirkt: der Name einer ereignisgesteuerter Sub sich zusammensetzt aus <NameDesSteuerelements>_<Ereignis> (Die Vergabe des Sub-Names erfolgt vollautomatisch und darf nicht verändert werden. Ausnahme: Nachträglich ändert sich der Name des Steuerelements. Access gleicht dann NICHT automatisch den Sub-Namen an :mad: !!

Hallo, endlich wieder... Interbase 5.0 sagt mir überhaupt nichts! Wie schon geschrieben: Ich bin ein Access-Programmierer (mit Scheuklappen(?))! Ich hoffe, alle 'hilsbedürftigen' Interbaseler haben u.U. a.a.O. bereits Hilfe erhalten!! Ich war ja nun lange im Forum. Sollte trotzalledem weiterhin Bedarf an der Fortführung dieses 'Lehrgangs' bestehen, laßt es mich wissen. Ich werde dann versuchen den Faden wieder aufzunehmen und mich bemühen, die Beschreibungen so allgemein wie möglich zu halten. Bis dann

Schreibfehler? Amis oder Admis?

Hi, SteffiMichi! Vor- und Nachteile kann ich schlecht auflisten, da ich bisher nur unter Access 2.0/97/2000 Datenbanken entwickelt habe. Und daß es bei MS Mängel gibt - dazu gibt es a.a.O. genügend Schriftverkehr... Also: Alles was ich hier so vin mir gebe ist relativ eng an Access geknüpft. Betrachten wir heute also mal so zwischendurch eine Sache, die jedem DB-Entwickler immer wieder über den Weg läuft: Die referentielle Integrität [rI]. Nehmen wir nochmal das Abteilungsbeispiel, in dem noch keine Beziehungen definiert wurden. Es ist in diesem Moment durchaus möglich, einem Mitarbeiter eine Abteilung zuzuweisen, die (noch) gar nicht existiert. Mal eben zwischendurch: (Im folgenden lege ich hier einmal folgende Formatierung fest: Tabellennamen Primärschlüssel tMitarbeiter: Nachname, Abteilung, Gehalt tAbteilung: Abteilung, Raumnummer An dieser Stelle ist es zweckmäßig, eine Beziehung zwischen den beiden Tabellen aufzubauen. ***** Allgemein: Es gibt drei Beziehungsarten. 1) 1:n Dieses ist wohl die am meisten erstellte Beziehung. In diesem Bsp. gibt es zu 1 Abteilung n Mitarbeiter. Die Interpretation 1 Mitarbeiter ist in n Abteilungen tätig ist hier falsch (unmöglich), da die 'Abteilung' in 'tAbteilung' der Primärschlüssel ist, und der ist (von Natur aus) 1deutig. (Fragen zum Primärschlüssel?) D.h. also, daß in der Tabelle 'tAbteilung' jede Abteilung nur einmal erfaßt wird, sie in der Tabelle 'tMitarbeiter' (natürlich) öfter (n-mal) auftauchen kann. (Dort ist das Feld 'Abteilung' ja kein Primärschlüssel.) Nebenbei bemerkt: Genau ein Feld ist Primärschlüssel. Daraus ergibt sich dann, welche Tabelle die 1-Seite darstellt. Dann gibt es noch 2) die 1:1 Beziehung Diese Beziehung macht im ersten Augenblick keinen Sinn: Einem Datensatz [DS] der einen Tabelle ist genau ein DS der anderen Tabelle zugeordnet. Dann kann man doch alle Datenfelder in einer Tabelle gemeinsam verwalten. Ja, richtig. Es macht aber irgendwann doch Sinn. Mehr dazu (viel) später. Nebenbei bemerkt: Bei dieser Beziehungsart sind beide verknüpften Felder Primärschlüssel. und 3) die undefinierte Verknüpfung Diese Beziehung liegt vor, wenn keines der beiden verknüpften Felder Primärschlüssel ist. Ganz selten benutzt und in den meisten Fällen resultierend aus einem Fehler in der Tabellenstruktur. ***** Wenn also eine Beziehung aufgebaut wurde und keine weiteren Optionen gewählt wurden, ist es nach wie vor möglich, Mitarbeitern Abteilungen zuzuweisen, die (noch) nicht existieren! Um das zu verhindern, verändert man die Beziehung derart, daß man rI fordert. Dann ist es so, daß nur noch in der Tabelle 'tAbteilung' (also auf der 1-Seite) existierende Abteilungen den Mitarbeitern in der Tabelle 'tMitarbeiter' (also auf der n-Seite) zugewiesen werden können. Nun kommt die berechtigte Frage:"Wer hat denn alle Abteilungen im Kopf?" Berechtigt. Die Lösung liegt in der Nachschlagefunktion, ist aber (wahrscheinlich) accessspezifisch, so daß ich an dieser Stelle nicht weiter darauf eingehe. (Später mehr dazu...) So, jetzt können wir also beruhigt den Mitarbeitern Abteilungen zuweisen. Wollen wir eine nicht in 'tAbteilung' erfaßte Abteilung in 'tMitarbeiter' eingeben, erscheint eine Fehlermeldung (, die mehr oder weniger gut verständlich ist). Jetzt haben wir aber ein bis zwei neue Probleme: 1) Wenn wir eine Abteilung aus 'tAbteilung' löschen wollen, und wir haben diese Abteilung mindestens einem Mitarbeiter zugewiesen, erscheint wiederum eine Fehlermeldung. Es würden dann Datensätze [DSe] in 'tMitarbeiter' Abteilungen beinhalten, die dann nicht mehr existieren würden! Lösung: In der Beziehung wird die 'Löschweitergabe an Detaildatenfeld' vereinbart. Wenn nun DSe auf der 1-Seite gelöscht werden, schaut Access nach, ob referierende DSe auf der n-Seite existieren. Wenn ja, werden diese ebenfalls gelöscht. Problem dann hier: Wird eine Abteilung gelöscht, werden alle Mitarbeiter dieser Abteilung ebenfalls gelöscht!! 2) Wenn sich eine Abteilungsbezeichnung ändert, und wir haben diese Abteilung mindestens einem Mitarbeiter zugewiesen, erscheint wiederum eine Fehlermeldung. Es würden dann Datensätze [DSe] in 'tMitarbeiter' Abteilungen beinhalten, die dann nicht mehr unter der alten Bezeichnung existieren würden! Lösung: In der Beziehung wird die 'Aktualisierungsweitergabe an Detaildatenfeld' vereinbart. Wenn nun Abteilungen auf der 1-Seite umbenannt werden, schaut Access nach, ob referierende DSe auf der n-Seite existieren. Wenn ja, werden diese Abteilungene benfalls umbenannt. Soviel für heute...

Hi, Durone! Halte beim Öffnen der Datenbank die Shift-Taste gedrückt. Dann solltest Du das DB-Fenster sehen. (Damit umgehst Du die Startoptionen.) Wenn Du das DB-Fenster nicht ausgeblendet und die Menüleisten verändert hast, gibt es im Menü 'Fenster' die Möglichkeit, ein bestimmtes Fenster in den Vordergrund zu holen.

Hi, s35i! Im Prinzip hast Du recht, es ist sauberer so zu programmieren, wie Du es vorschlägst: _____ Me.Kombinationsfeld0.value = rs![idKunde] _____ Nun ist es aber so, daß sich MS manchmal etwas anstellt, und nur Zuweisungen an Felder zulässt, wenn dieses Feld den Fokus besitzt. Das ist manchmal aber unerwünscht bzw. etwas schwer zu realisieren. Abhilfe schafft hier die Möglichkeit unsauber zu implementieren. Es gibt für jedes Steuerelement eine Standardeigenschaft. Und wenn genau diese Eigenschaft manipuliert werden soll, braucht sie nicht mit angegeben zu werden: _____ Me.Kombinationsfeld0 = rs![idKunde] _____ Und wenn man den Feldnamen ohne Leerzeichen und Bindestrich und sonstwelche 'Sonderzeichen' gewählt hat, kann man auch die eckigen Klammern weglassen: _____ Me.Kombinationsfeld0 = rs!idKunde _____ Und wenn der Code als Klassenmodul (gebunden im Formular) vorliegt, kann auch das Me. wegfallen. ABER das Me. nimmt viel Schreibarbeit ab, da dann in der KomboListe alle Eigenschaften und auch die Steuerelemente in diesem Formular aufgelistet werden, so daß folgende Zeile nur eine (theoretische aber funktionierende) Möglichkeit darstellt: _____ Kombinationsfeld0 = rs!idKunde _____

Hi, Stefan Ob das ein Problem ist? Ivh weiß novh nivht... (Und an dieser Stelle kommen ganz doll viele Smileys!) Ihr habt ja die Möglichkeit geschaffen auf "Kennwort oder Paßwort vergessen?" zu klicken und dort Hilfe zu bekommen. me: Aber wie schnell hat man sich vertippt? You: Dann mußt Du das Kennwort langsamt und kontrolliert eintippen! me: Ja, aber auch dann...!? Bisher war die fehlende Passwortbestätigung kein Problem für mich, und wenn ihr nicht mit o.g. Hilfegesuchen überflutet werdet, kann es so bleiben.

Hallo, Leute! Der Code von Mercutio ist schlüssig und müßte meines Wissens nach funktionieren. Nur bei mir nicht... Es kommt zum Laufzeitfehler 13: Typen unverträglich. Das Problem taucht auch auf, wenn ich statt SQL eine existierende Abfrage einsetze! Ich habe dazu ein neues Thema gestartet: Access 2000, OpenRecordset, Lzf. 13 An dieser Stelle ersteinmal vielen Dank an alle!

Hallo, Leute! Beim Öffnen eines Formulars kommt es im folgenden Code zur Fehlermeldung. _____ Private Sub Form_Open(Cancel As Integer) Dim Db As Database Dim Rs As Recordset Set Db = CurrentDb() '---Folgende Zeile verursacht Laufzeitfehler. 13: '---Typen unverträglich Set Rs = Db.OpenRecordset("MeineAbfrage", dbOpenSnapshot) _____ Liegt es daran, daß die Tabelle, auf der die Abfrage basiert, aus einer anderen Access2000-DB verknüpft ist? Das kann ich mir nicht vorstellen. Ich bin ratlos ! Aber hoffentlich nicht lange !!

Hallo, liebe Admis! Kontrolliert mal, ob ich innerhalb von 2 Minuten wirklich 555 Hits auf dieses Thema hatte... PS: Ok., es war nur ein Anzeigefehler!! <FONT COLOR="#a62a2a" SIZE="1">[ 26. Oktober 2001 11:45: Beitrag 1 mal editiert, zuletzt von piomode1 ]</font>

Hallo, liebe Admis! Habe ich einen Blackout oder wurde ich beim Ändern meines Kennwortes tatsächlich NICHT nach einer Bestätigungseingabe aufgefordert!? Falls ich mich irre bzw. es geändert wurde -> kurze Rückmeldung -> schließen