Abfragenrealisierung über Bericht?

[YannDecay]

Hallo liebe Access-Gemeinde,

nach vielem Suchen nach gleichen Problemen konnte ich nichts finden daher versuch ichs jetzt nochmal bei euch
Ich möchte einem Datensatz ein Zahlenfeld (Kalenderwoche)  hinzufügen. Dann sollte man über einen Bericht, alle Einträge abrufen können, deren Kalenderwoche die gleiche ist, wie die bei der Abfrage.

hab bei meiner suche auch einiges gefunden aber nix passendes....
das hier könnte man jedoch auch verwenden denk ich:



Public Function Kalenderwoche(Datum As Date)

    Kalenderwoche = Format(Datum, "ww", 2, 2)

End Function

Aufruf:

MsgBox (Kalenderwoche(Date))



Wobei ich hier auch nicht den Aufruf verstehe? wo macht man den dann? im Bericht? habe noch nie mit berichten gearbeitet (ist ja auch meine erste DB )
weiß nur soviel das es mit SQL zusammenhängt nur so eine Abfrage ist für mich schon zu hoch :/ und wie verknüpf ich dann die abfrage mit dem bericht ? bitte um detailierte Beschreibung 

Vielen Dank schonmal für die Mühe !

Mfg Yann Decay

[Hondo]

Hallo,
klar funktioniert da nichts da die Funktion nichts zurückliefert. So sollte es funktionieren:

Public Function Kalenderwoche(Datum As Date) As String
    Kalenderwoche = Format(Datum, "ww", 2, 2)
End Function

[DF6GL]

Hallo,

@Hondo:  die Funktion liefert schon einen Wert (die Kalenderwoche) , allerdings vom Datentyp Variant mit Unterdatentyp String (wegen der Zuweisung des Ergebnissen der Formatfunktion, die einen String darstellt.)



@YannDecay:

beschreib nochmal die eigentliche Aufgabe, vor der Du stehst, nicht schon die vermeintliche Lösung...und gebe den Aufabu und die Namen der Tabellen/Formulare  und  Felder an, die daran beteiligt sind.

[YannDecay]

Ok jetzt etwas konkreter:

Meine Tabelle mit Kunden heißt Clients.  Wo allemöglichen Kundendaten drin sind. Da kommt jetzt ein eingebbares Zahlenfeld dazu namens KW (Kalenderwoche). Und das wars eigtl schon von der tabelle ^^ wenn du doch mehr tabellen/feld namen brauchst, tipp ich sie doch mal ab aber es sind standart einträge wie Vorname, nachname, straße usw....

So stellt euch das so vor, das ein Kunde mir ein Datum vorschlägt und ich dieses bei ihm in der KW eintrage (aber dann schon als KW also z.b 24 )

Dann möchte ich, wenn ich meine Datenbank öffne und auf ein bestimmten bericht gehe, mir alle Datensätze angezeigt werden, deren KW die gleiche ist wie bei der jetzigen Abfrage, also gerade.

Hintergrund: Die Kunden geben ein Datum an dem man sich melden soll, und das ich das "Event" nicht verpasse muss ich erinnert werden


Jetzt sind wir aber auch schon bei der fehlerbeseitigung... weil was ist wenn ich 2 wochen im urlaub bin? die datensätze würde mich nur auf klick in dem bericht erinnern.... wenn ich in den 2 wochen die Datensätze nicht abrufe sind sie weg ....  könnte man das umgehen?

kann man die Datensätze vllt sogar irgendwo zwischenspeichern? vllt in eigener tabelle ? und die dann im bericht anzeigen und mit kontrollkästchen versehen sprich X für angerufen leer für noch nicht ....
Was meint ihr ?

[DF6GL]

Hallo,


1) die Angaben reichen (zunächst)

2) besser wäre ein Datum. Wenn allein die Woche eingeben wird, fehlt die notwendige Jahreszahl, um die Woche eindeutig zu bestimmen.

3) Hier fehlt mir die Erwähnung einer Ablaufsteuerung über Formulare.. In einer fertigen DB hat der User keinen direkten Zugriff auf Formulare oder Berichte, geschweige denn Tabellen oder Abfragen (außer einem evtl. Startformular, von dem aus auf weitergehende Forms verwiesen wird.

Abfrage , die alle Kunden zeigt, bei denen die Erinnerungs-Woche(nzahl) erreicht/überschritten wurde:


Select * from Clients where KW <= datepart("ww", 2, 2)


mit einem Datumsfeld:

Select * from Clients where ErinnerungsDatum <= Date()


"deren KW die gleiche ist wie bei der jetzigen Abfrage, also gerade."   was heißt das? was ist die "jetzige Abfrage" beim Öffnen der db?

"Hintergrund"    wäre mit einem Dateum wesentlich einfacher..

4) Fehlerbeseitigung: wieso "weg" ?  Der Bericht löscht doch nichts...

Um eine "Erinnungshistorie" zu managen, wird eine weitere Tabelle benötigt , die als n-Tabelle zu "Clients" aufgebaut wird und die bei jeder neuen Vereinbarung eines Erinnerungstermins einen neuen Datensatz mit dem neuen Datum und anderen nötigen Werten erhält.

[YannDecay]

mhhh ok Kalenderwoche würd ich zwar einfacher finden, da man beim Kunden ja auch nicht direkt auf den Tag sagt ich meld mich GENAU an dem tag, sondern in der bestimmten zeit daher dachte ich wäre kalenderwoche besser, auch einfach zum eingeben.... würd es gern so haben wollen :p

was hälst du denn von KW-Jahr also so -> 1-11, würde das gerne so machen... wie würde dann der SQL Befehl lauten?

ablaufsteuerung über formulare? ich wusste nich das in einer fertigen db der user kein zugriff darauf hat xD wo gibt er sonst die daten ein xD? so wie es jetzt ist ist schon gut tragen ja nur max. 3 leute ein und die 2 formulare dafür sind schon gemacht un laufen von daher...

sorry für meine unwissenheit, aber wie stelle ich das jetzt an besten an? die sql anweisung allein reicht mir leider net, genauere beschreibung wäre nett

Hab mir jetzt noch etwas neues einfacheres ausgedacht, wie ich auch den Fehler umgeh, das wenn keiner abruft trotzdem die werte da sind die ich will...
Würde das gerne so machen und hoffe das mir jemand dazu eine Anleitung schreibt

Ich möchte ein Suchfeld haben, wo ich zb. 5-12 eingebe (Kalenderwoche 5 - Jahr 2012) und mir alle Datensätze angezeigt werden die 5-12 als KW-Eintrag haben...

jaaaa das hört sich doch gut und einfach an^^

danke im vorraus
mfg yann decay

[DF6GL]

Hallo,


"würd es gern so haben wollen "

na denn, des Menschen Wille ist sein Himmelreich 

"von KW-Jahr also so -> 1-11, würde das gerne so machen... wie würde dann der SQL Befehl lauten?

da nimmst Du zwei Felder, eines für die Kw und eines für die Jahreszahl. Die SQL (Abfrage) ist im Moment völlig unwichtig. Wenn man sich auf eine vernüftigen Tabellenaufbau geeinigt hat, dann sind hinterher Abfragen nur Peanuts.

Ablaufsteuerung:  Du verstehst da was falsch. Daten werden (manuell) nur und nur über Formulare eingegeben und gepflegt. Welches Formular für welchen Zweck man gerade benutzen muss, wird durch eine "Ablaufsteuerung" festgelegt, indem von einem bestimmten Formualr heraus ein anderes geöffnet wird. Das geschieht NICHT über das Datenbankfenster (Navibereich bei A2007). Tabellen/Abfrage-Ansichten sind im Normalfall nicht für die Augen des Users bestimmt.

"sql anweisung allein reicht mir leider net"

eben..  überleg Dir ein Konzept, wie Du am Besten vorgehen willst. Orientiere Dich daran, wie Du auch schon im Moment arbeitest, ohne an die DB zu denken.


"Hab mir jetzt noch etwas neues einfacheres ausgedacht"

denk das Ganze (Was willst Du erreichen, was soll die DB Dir erleichtern, welche Daten hast Du zur Verfügung, welche Daten soll die DB aus den vorhanden ableiten, welche Arbeitsschritte erledigst Du jetzt, um das Areitsziel zu ereichen, sind diese Areitsschritte optimal oder eher umständlich, etc. )  erst nochmal in Ruhe von Anfang bis Ende durch (und mach Dir ein paar Stichworte, damit Du nichts vergisst...)

Wenn Dir alles klar geworden ist, erstellst Du die Tabellen nach den Normalisierungsregeln ( siehe u. st. Linls 1 und 1a). Danach wiederholst Du die o. g. Überlegungen und prüfst, ob die Tabellen immer noch den neuen Überlegungsergebnissen  entsprechen. Wenn nicht, dann werden die Tabellen angepasst.  Erst jetzt , und wirklich erst jetzt, kannst Du Dich an die Formularerstellung für die Datenpflege machen.

Dass dabei Abfragen gebraucht werden, ist normal und kein mystisches Hexenwerk.  Als Ausgangspunkt für den Gebrauch der DB erstellst Du noch ein Übersichtsform, in dem, bzw. mit dem die anderen (Bearbeitungs-)Formulare (auch Berichte) je nach Bedarf  geöffnet werden.


Du kannst das Ganze aber auch bleiben lassen und Dich mit einem DB-Fragment zufrieden geben, dass Dir (und den anderen Usern)  weder die Arbeit erleichtert noch authentische Daten liefert. 


SQL für Selektion eines oder mehrere DS anhand der KW und der Jahreszahl (mit zwei getrennten Feldern für KW und Jahreszahl und mit Abfrageparametern, die allerdings so nicht zu empfehlen sind) :


Select * from Clients where KW= [KW eingeben:] and Jahreszahl =[Bitte Jahreszahl eingeben:]

[YannDecay]

vieeelen dank für deine ausführliche antwort, meine tabellen sind schon normalisiert =D hab sogar mehr oder weniger ein ERM erstellt =D also hab mir eigtl schon bissl Grundwissen angeeignet. Es läuft jetz auch alles so wie ich es will

nur eine frage bleibt mir noch wieso meinst du das dein sql befehl SO nicht zu empfehlen ist? bei mir macht er das was er soll zumal ich KWJ zusammengesetzt hab und so wie ich es eigtl wollte suche und finde --> 01-11.

Wieso ist das problematisch wenn ich beides in ein Feld abspeicher da brauch ich doch kein extra Jahresfeld, das Jahr ist ja nur zur übersicht für mich.
Hab es jetzt so wie ich will und und es geht. mhhh klär mich auf =)

[DF6GL]

Hallo,


ganz einfach:  das Feld ist nicht normalisiert (atomisiert) und bedarf genauer Eingabe (z. B. muß auch die führende 0 explizit angegeben werden), sonst schlägt der Vergleich fehl..

[YannDecay]

ich sag mal so jaein

denn normalisiert ist es schon.... Unnormalisiert wäre ja z.b. Name ... normalisiert wäre Name = Vorname & Nachname ... schön und gut, nur bei meinem Fall ist das Jahr, eigtl nicht notwendig und hat auch sonst in den Benutzerdaten nix zu suchen, ich würde es mal eher so vergleichen: Mein KWJ Feld ist ein Datumsfeld..., das speichert man ja auch nicht in monat tag und jahr (naja gut kommmt ganz auf die db an ^.^, aber ich hoffe du verstehst was ich dir damit sagen will...)


außerdem kommt es darauf an wie es abspeicher,  ich habs ja schon unter 01-11 dann gespeichert, hätte ja ebenso auch 1-11 nehmen könen, dann müsste ich auch in der Abfrage keine führende Null dranhängen....

aber wie auch immer .... es läuft =) ich danke dir, versteh auch deinen ansatz aber in meinem Fall finde ich das Quatsch so. Hab nur sonst gedacht das sich das irgendwo reibt, aber wenn ansonsten keine probleme dadurch resultieren bin ich ja zufrieden

[DF6GL]

Hallo,

naja, wenn Du meinst...  ich will aber jetzt nicht weiter über diese "Normalisierung" diskutieren.

Wenn Du damit klarkommst, ist es ja gut