Office: (Office 2007) Parameterabfrage aus 2 Spalten (Datum, Uhrzeit) zur Selektion nach Schichtsystem

Mir ist einfach nicht ganz klar wieso ich ein Schichtdatum erst berechnen soll. Wenn ich das schon nicht weiß, weiß ich auch nicht was ich wie umsetzen soll wenn mir der Sinn noch nicht klar ist.

Er soll ja quasi nur vom eingegebenen Datum alles ab 6 Uhr selektieren und den Folgetag bis kleiner als 6 Uhr. Und mein zuletzt geschriebener Code ist diesbezüglich meine Lösung die ich erarbeitet habe.

Was war an diesem Vorgehen jetzt falsch?

 

Was hindert Dich, das auszuprobieren und das Ergebnis gleich mit kundzutun? Nebenbei hättest Du die Antworten auf Deine Fragen.

Ansonsten: Etwas rechnen wird man immer müssen. Ob nun an den Tabellenwerten oder bei den Kriterienausdrücken ist beim Filtern dann relativ egal:
Code:

Hat man dann nachfolgend höhere Anforderungen als pures Filtern, wird man dann die Varianten neu bewerten.

Höhere Anforderungen: Vielleicht mag einer wissen wollen, welche Stückzahlen schichtweise, tagweise usw. bewegt werden, um da aus Trends Schlussfolgerungen zu ziehen.
Denkweise: Mit dem Lösungsansatz auch bei der nächsten oder übernächsten Anforderung bestehen können.

 

Hallo ebs,

vielen Dank für Deine Rückmeldung:

Ich habe mich jetzt nochmal damit beschäftigt und meinen Code noch etwas geändert und dann ausprobiert:

Code:

 

Siehe fettgedruckter Anteil mit Rot-Anteil in #15. Am verstehenden und vollständigen Lesen musst Du noch reichlich üben.

Für eigene Hinzufügungen bist Du alleine verantwortlich - von wegen "Deines Codes den Du zuletzt gesendet hast".
Ob da etwas angefügt werden kann, hängt u.a. davon ab, welche Daten vorliegen, welche Parameter verwendet wurden, ob irgendwelche Regeln das Einfügen verhindern.

Woher kommt immer der Glaube, dass, wenn man selber nichts weiß, andere alles wissen und einem dabei noch permanent über die Schulter schauen und sehen würden, was da gerade worin so veranstaltet wird??

Ich sag mal so: "Kein Syntaxfehler" ist erst mal gut. Da könnte etwas passieren. Ein gelöstes Problem macht Platz für das Auftreten des nächsten Problems.

 

und bereits in #4 (ohne rot *wink.gif* )

 

Das ist nicht korrekt. Eher ist wohl richtig, dass ich aufgrund mangelnder SQL-Kenntnisse eventuell Dinge anders versuche umzusetzen bzw. interpretiere.

Du schreibst jetzt stellenweise auch nicht gerade anfängerfreundlich, was es mir gerade etwas schwer macht.

Davon abgesehen: Ich finde den SQL-Befehl der von mir kommt jetzt vom Lesen her nicht wirklich komplex. Meines Erachtens wurde im WHERE-Teil auch alles so eingegrenzt sodass er bei der Eingabe des Datums genau das anzeigen sollte was ich mir erhoffe. Ich hab wirklich keine Ahnung warum es nicht funktioniert.

Den Syntaxfehler habe ich behoben. Da hat nur eine Klammer gefehlt sowie die Rauten bei den Uhrzeiten

Bisher konnte ich immer weitestgehend alles nachvollziehen aber im Moment denke ich, mein Code stimmt, tut aber nicht was ich will *grins

Code:

 

Du hast jetzt aber nicht die Erwartung, dass jeder kreative Versuch von Dir kommentiert wird, während Du Vorschläge ignorierst oder verfremdest.
Wie dann auch: Wenn Du gegebene Hinweise ignorierst oder nicht umsetzen kannst (oder willst) - welchen Weg geht dann ein neuer Hinweis? Abgesehen davon, dass man üblicherweise eine "beste Lösung" offeriert, was soll da nachfolgend kommen?

Das wird jeder für sich beurteilen müssen. Aber auch bei Anfängern in SQL und/oder VBA setze ich voraus, dass sie LESEN können (man darf erhaltene Antworten auch mehr als einmal lesen und sich so Inhalte nach und nach erarbeiten) und über ein Mindestmaß an gesundem Menschenverstand verfügen.
Wer da mit dem Hinweis auf Anfängerschaft solches auch ablegt, legt sich insgesamt in die Ablage.

Ursprünglich hatte ich so etwas wahrgenommen:

Wie man jetzt die Uhrzeit an das Datum ranhängen kann, wurde in mehreren Varianten gezeigt. Fertig.

 

Ich möchte jetzt auch nicht blind Vorschläge von insbesondere Dir umsetzen. Ich ziehe NACH WIE VOR vor, selbst zur Lösung zu kommen und quasi die Tipps hier als Anregung mit zu nehmen. Falls das in die Hose geht, würde ich dann als LETZTEN SCHRITT nochmal auf das zurückkommen, was hier konkretes an Lösungsvorschlägen gebracht wurde.

Diese Reihenfolge erachte ich persönlich als die deutlich sinnvollere. Ich hab jetzt 10 Varianten durch, komme nicht weiter, jetzt werde ich mich mal an Deine Eingangsvorschläge ran machen. Falls Du dich wunderst wieso das so lange dauert -- ich mach das alles nur so nebenbei wenn ich hier und da mal 10 Minuten Zeit habe. Ich grübel jetzt nicht, falls Du denkst, wie so ein Doofi seit 2 Wochen an diesem 5 Zeilen SQL Code.

Wenn ich was habe, melde ich mich nochmal. Idealerweise, wenn es dann klappt.

Vielen Dank Dir schon mal, auch wenn Du manchmal etwas forsch bist *biggrin.gif* passt aber schon so. Danke schön!

Gruß

 

Noch einmal zum besseren Verständnis in logischer Reihenfolge:
* Du addierst Datum und Uhrzeit
* Du subtrahierst davon 6 Stunden
* Du extrahierst daraus das Datum (und erhältst den nominellen Schichttag)
* Du verwendest diesen nominellen Schichttag für die Vergleichsbedingung

 

Zusammengefasst heißt das dann, man gibt Dir nach Stellung einer Frage etwa 14 Tage Zeit, ehe man eine Antwort gibt, um die Selbstphase nicht zu stören. So etwas kann man auch eingangs klarstellen.

 

Vielen Dank. Es ist immer wieder schön zu sehen wie manche die Didaktik beherrschen und in wenigen Worten viel Inhalt widergeben können. Ich habe jetzt die Logik dahinter verstanden.

Zudem habe ich noch nachgeschaut und herausgefunden, dass ein Datum quasi der Tag um 0 Uhr systemintern ist. Jetzt gibt es für mich auch Sinn wieso ich Datum + Uhrzeit addieren muss. Als "Nichtinformatiker" ist das wirklich nicht auf Anhieb zu verstehen.

Eine frage habe ich noch: Die neue Datumsspalte existiert jetzt. Das funktioniert. Leider stellt er mir diesbezüglich nur eine Zahl dar

(43012,0416666667 z. b. für den 4.10.2017 um 7 Uhr)

Code:

Ich würde das Datum jetzt wieder so in ein handliches Format umwandeln. Da bringt er mir Syntaxfehler. Ist mein Ansatz totalfalsch oder fast richtig? *wink.gif*

 

CDate([DeinWert]) wandelt Dir das in ein Datum mit Uhrzeit um, CDate(Fix([DeinWert])) würde den Uhrzeitanteil abtrennen. Format hingegen würde Text für's Auge aufbereiten, der dann allerdings kein Datum mehr ist: Format([DeinWert], "dd/mm/yyyy")

PS: lägen die Angaben Datum + Uhrzeit in einem Feld vor, könnte man sich das gesamte Prozedere ersparen - wenn Du Einfluss darauf hast, würde ich Dir empfehlen, diese Änderung vorzunehmen.

 

Hallo Nouba,

vielen Dank für Deine Rückmeldung.

Datum+Uhrzeit liegen jetzt in einer Spalte vor (als Zahl). Wenn die Format-Umwandlung "fürs Auge" ausreicht, sodas ich über eine anschließende Parameterabfrage dieses Datum eingeben kann, ist das vollkommen ausreichend. Ich probiers mal.

Gruß

 

Für's Auge würde ich nicht unbedingt Werte in einer Tabelle ablegen.

Ein Datum/Uhrzeitwert benötigt 8 Byte Speicherplatz. Ein Text mit Uhrzeitangabe und eingestellter Unicode-Komprimierung kommt schon auf 10 Zeichen für das Datum + 1 Leerzeichen + 8 Zeichen für die Zeit. Will man dann diesen schönen Text auch noch chronologisch sortieren, steht man zuerst einmal auf dem Schlauch, weil wir hier in Deutschland zuerst den Tag, dann den Monat und danach das Jahr abgeben.

Der umgekehrte Weg, z. Bsp. über die Format-Eigenschaft des Felds in Tabelle und/oder Abfrage und/oder Textfeld im Formular/Bericht ist hingegen völlig unproblematisch. Auch die Parameterauswertung ist ein Klacks. Du gibst ein Datum als Parameter ein und addierst in der Abfrage (das ist dann Eberhards angedachter Lösungsweg) 6 Stunden hinzu. Weil sich Datum und Uhrzeit in einem Feld befinden, kann ganz leicht (sogar mit Indexnutzung) zwischen 6 Uhr des Eingabetags und 5:59:59 des Folge- oder Zieltags eine einschränkende Auswahl getroffen werden.

Also noch einmal gut überlegen, bevor das ganze Gedöns auch noch verschlimmbessert wird.

PS: wie kommen die Daten denn überhaupt zustande bzw. in die DB?

 

Die Daten kommen wie fast immer bei größeren Firmen aus dem SAP-System. Leider ist da die Uhrzeit und das Datum quasi immer getrennt. Lässt sich sicher leicht ändern, aber das ist kurzfristig erstmal nicht realisierbar.

Ich hab das Problem jetzt übrigens gelöst. ebs17 und Du haben mir sehr geholfen, und gelernt hab ich dabei auch noch was.

Habe zuerst das neue Datum berechnet wie ebs17 es schon ganz am Anfang gesagt hatte. Aufgrund des neuen Datums dann folgender SQL-Code:

Code:

[/
INSERT INTO Zieltabelle (a, b, c, DatumNeu)
SELECT a, b, c, CDate(Fix([DatumNeu]))
FROM Rohtabelle
WHERE (((CDate(Fix([DatumNeu]))) Between [Geben Sie das Startdatum ein] And [Geben Sie das Enddatum ein]));
CODE]

funktioniert einwandfrei! Danke Euch beiden!

@ebs17: habe im Internet einige Statements dazu gelesen, dass berechnete Felder über den Ausdrucksgenerator tendenziell sogar schneller in der Laufzeit sind als SQL-Abfragen. Du meintest ja das Gegenteil. Worauf stützt sich Deine Vermutung?