Bernd: Wie könnte ich folgendes umsetzen?

Hallo,

ich stehe irgendwie total auf dem Schlauch und weiß nicht wie ich folgendes umsetzen könnte.

Folgende Tabelle habe ich

CREATE TABLE IF NOT EXISTS `artikel_ausgeliehen` (
  `aa_id` int(11) NOT NULL AUTO_INCREMENT,
  `aa_artikelID` varchar(200) NOT NULL,
  `aa_projektID` varchar(200) NOT NULL,
  `aa_userID` varchar(200) NOT NULL,
  `aa_menge` varchar(10) NOT NULL,
  `aa_datum` date NOT NULL,
  `aa_status` varchar(5) NOT NULL,
  `aa_grund` varchar(5) NOT NULL,
  `aa_code` varchar(255) NOT NULL,
  PRIMARY KEY (`aa_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=445444 ;

Hier stehe pro Tag die Artikel drin, die ausgeliehen sind, das wichtigste ist die menge und projektID sowie das Datum.

Jetzt habe ich ein Projektzeitraum, dieser steht in $von und $bis im englischen Format, also 2019-06-16, Außerdem gibt es noch eine Variable mit $Ausgabe_Tagesbestand. Jetzt muss ich natürlich die Menge berücksichtigen die in der artikel_ausgeliehen stehen. Und genau da habe ich mein Problem. Wie kann ich die artikel_ausgeliehen mit dem Zeitraum abgleichen?

Mein Kopf ist irgendwie total leer 😕

  1. Wie kann ich die artikel_ausgeliehen mit dem Zeitraum abgleichen?

    Den Zeitraum vorgeben. Dann kannst Du auch die Abfrage formulieren. MFG

    1. Moin,

      Den Zeitraum vorgeben. Dann kannst Du auch die Abfrage formulieren.

      den habe ich ja in $von und $bis z.B. steht da 2019-06-16 bis 2019-06-22

      1. Moin,

        Den Zeitraum vorgeben. Dann kannst Du auch die Abfrage formulieren.

        den habe ich ja in $von und $bis z.B. steht da 2019-06-16 bis 2019-06-22

        Ausgeliehen heißt: Der Artikel wurde nicht zurückgegeben. Du brauchst also auch diese beiden Zeitangaben: Ausgabe, Rücknahme. Dann kannst Du je Artikel abfragen ob der ausgeliehen oder wieder im Bestand ist. MFG

  2. Hello,

    das gezeigts Format ist nicht "englisch", sondern quasi ANSI. ANSI wäre "20190616" => "YYYYMMDD" (alles Ziffern, führende Nullen). . Es gibt "between".
    Beide Spalten soltten den gleichen Datums/Zeittyp haben.
    Beachte ggf. die Zugehörigkeit der Grenzen.

    Glück Auf
    Tom vom Berg

    --
    Es gibt nichts Gutes, außer man tut es!
    Das Leben selbst ist der Sinn.
    1. Ok, meine Idee war

      SELECT SUM( aa_menge ) AS  `summe_unterwegsProjektzeitraum` 
      FROM  `artikel_ausgeliehen` 
      WHERE  `aa_status` =2
      AND  `aa_artikelID` =  'a196f40a4bdb40c6551a41cdd3910d53'
      AND  `aa_datum` 
      BETWEEN  '2019-06-22'
      AND  '2019-06-23'
      

      Als Ergebnis erhalte ich

      Das Problem ist, er zählt jetzt beide Tage zusammen, was ja nicht richtig ist, denn es sind nur 5 unterwegs. Ich brauch aber die SUM weil es ja mehrere Projekt geben kann wo ein Artikel unterwegs ist.

      Versteht ihr was ich meine?

      1. Hello,

        also möchtest Du lieber pro Tag gruppieren, also zählen lassen, wieviele Artikel an welchem Tag in dem Bereich unterwegs waren?

        Glück Auf
        Tom vom Berg

        --
        Es gibt nichts Gutes, außer man tut es!
        Das Leben selbst ist der Sinn.
      2. Was sagt ihr zu meiner Idee/Lösung?

        SELECT SUM( aa_menge ) AS  `summe_unterwegsProjektzeitraum` 
        FROM  `artikel_ausgeliehen` 
        WHERE  `aa_status` =2
        AND  `aa_artikelID` =  'a196f40a4bdb40c6551a41cdd3910d53'
        AND  `aa_datum` 
        BETWEEN  '2019-06-22'
        AND  '2019-06-23'
        GROUP BY  `aa_datum` 
        LIMIT 1
        

        Habe ich etwas vergessen, ist dieses die Lösung oder würdet ihr es komplett anderes machen? Vielleicht noch als Hinweis, in jedem Projektzeitraum ist die Menge immer gleich, es kann also nicht vorkommen, heute 4 morgen 10 und in drei Tagen 2, das ist vom System ausgeschlossen.

        1. Ich habe noch etwas ergänz, da ich noch immer ein Problem mit meinem Datum habe, welches ich leider derzeit noch auf Deutsch in der Tabelle stehen habe

          function unterwegsProjektzeitraum($mysqli, $artikelID, $Datum_von, $Datum_bis){
          
              $D_von       = explode(".",$Datum_von);
              $D_tag_von   = $D_Von[0];
              $D_monat_von = $D_Von[1];
              $D_jahr_von  = $D_Von[2];
          
              $D_bis       = explode(".",$Datum_bis);
              $D_tag_bis   = $D_bis[0];
              $D_monat_bis = $D_bis[1];
              $D_jahr_bis  = $D_bis[2];
          
              $Ausgabe_D_von = $D_jahr_von."-".$D_monat_von."-".$D_tag_von;
              $Ausgabe_D_bis = $D_jahr_bis."-".$D_monat_bis."-".$D_tag_bis;
          
              $sql = "
          
                  SELECT SUM(aa_menge) AS `summe_unterwegsProjektzeitraum` 
                  FROM artikel_ausgeliehen 
          
                  WHERE aa_status=2 AND aa_artikelID=? AND aa_datum BETWEEN  ? AND ?
                  GROUP BY  `aa_datum` 
                  
                  LIMIT 1";
              
              $res = $mysqli->prepare($sql);
              $res->bind_param("sss", $artikelID, $Ausgabe_D_von, $Ausgabe_D_bis);
          
              $res->execute();
              $res->bind_result($summe_unterwegsProjektzeitraum);
              $res->fetch();
              $res->close();  
          
              return $summe_unterwegsProjektzeitraum; 
          }
          

          Muss ich den komplizierten Weg über das Umwandeln vom Datum gehen oder könnte dieses mySQL auch direkt mit einer Funktion machen?

          1. Hallo Bernd,

            das Umgruppieren wird wohl nötig sein; du kannst es aber eleganter bauen. Das Format YYYY-MM-DD ist übrigens das ISO-Format.

               $ISO_D_von = convert_german_date_to_iso($Datum_von);
               $ISO_D_bis = convert_german_date_to_iso($Datum_bis);
            

            (ich habe die Variablen ISO_D genannt, wenn Du das übernimmst, denk an den bind_param).

            In die Funktionen-Werkzeugkiste kommt dann dies:

            function convert_german_date_to_iso($german_date)
            {
               $teile = explode(".", $german_date);
               return "$teile[2]-$teile[1]-$teile[0]";
            }
            

            Die Funktion kann man noch aufgemotzen, damit sie auch "4.5.18" korrekt verarbeitet, aber solange Du sicher sein kannst, dass dein $german_date immer exakt im "tt.mm.jjjj" Format ist, kannst Du Dir das sparen.

            Rolf

            --
            sumpsi - posui - clusi
      3. Hallo Bernd,

        Versteht ihr was ich meine?

        Nein, überhaupt nicht. Erzähle mal ein bisschen mehr über die Bedeutung der Sätze in deiner Table, beschreibe mal, welche fachlichen Sachverhalte sich da wie wiederfinden.

        `aa_datum` BETWEEN  '2019-06-22' AND  '2019-06-23'
        

        verarbeitet auf jeden Fall zwei Tage; die Between-Grenzen sind inklusiv. Wenn er dann doppelt zählt, würde das bedeuten, dass Du für jeden Ausleihtag des Artikels eine Row in der Table hast?

        Und mir ist auch noch überhaupt nicht klar, welche Erkenntnis Du mit Deiner Query gewinnen willst.

        Rolf

        --
        sumpsi - posui - clusi
        1. Hallo Rolf,

          Versteht ihr was ich meine?

          Nein, überhaupt nicht. Erzähle mal ein bisschen mehr über die Bedeutung der Sätze in deiner Table, beschreibe mal, welche fachlichen Sachverhalte sich da wie wiederfinden.

          es beruhigt mich, dass ich nicht der einzige bin. Ich verstehe zwar einige Details von Bernds Ausführungen, aber mir fehlt einfach noch der Zusammenhang, der Überblick. Vor allem auch das Verständnis, wie Projekte, Artikel und Zeiträume gedanklich (nicht programmtechnisch!) miteinander in Verbindung stehen.

          Und mir ist auch noch überhaupt nicht klar, welche Erkenntnis Du mit Deiner Query gewinnen willst.

          Genau: Wieviel Stück eines Artikels zu einem gegebenen Zeitpunkt noch "in stock" sind? Oder wieviele in einem bestimmten Intervall ausgeliehen (und zurückgegeben?) wurden? Oder die Bestands-Änderung in einem Intervall?

          Schönen Sonntag noch,
           Martin

          --
          Ein Tag, an dem du nicht wenigstens einmal gelacht hast, ist ein verlorener Tag.
        2. Hallo,

          Nein, überhaupt nicht. Erzähle mal ein bisschen mehr über die Bedeutung der Sätze in deiner Table, beschreibe mal, welche fachlichen Sachverhalte sich da wie wiederfinden.

          Ich habe eine Tabelle Artikel, weiter gibt es noch eine Tabelle Unterwegs unterwegs und nicht benutzbar. Jetzt möchte ich einen Artikel für den Zeitraum 16.06.2019 - 22.06.2019 bestellen. Zuerst schau ich, ob dieser Artikel in der Menge verfügbar ist, also wenn alles im Lager wäre. Wenn dieses der Fall ist, muss ich schauen ob dieser Artikel für den gewählten Projektzeitraum verfügbar ist. Dann muss ich noch schauen ob ein Artikel als Reparatur oder eigner Lieferschein hinterleg ist. Erst wenn alles passt darf dieser Artikel bestätigt werden.

          Bis jetzt habe ich bzw. wir dieses händisch überprüft dieses führte in der letzten Zeit zu Fehlern, welche nicht schön sind bzw. einem Ärger beschert. Deshalb möchte ich dieses jetzt durch das System prüfen lassen.

          Variable kann der Wert Reparatur sein. Es kann auch ein Artikel verschickt werden der Defekt ist, kommt immer drauf an wo dieser aufgehängt wird. Wenn ein Banner in 10 Meter Höhe aufgehängt wird sieht man eine ausgerissene Öse z.b. nicht. Wenn dieser auf Augenhöhe hängt dann ist es schon fraglich.

          `aa_datum` BETWEEN  '2019-06-22' AND  '2019-06-23'
          

          verarbeitet auf jeden Fall zwei Tage; die Between-Grenzen sind inklusiv. Wenn er dann doppelt zählt, würde das bedeuten, dass Du für jeden Ausleihtag des Artikels eine Row in der Table hast?

          Genau, jeder Tag wo der Artikel unterwegs ist, hat eine Zeile. Ist ein Artikel vom 22.06.2019 - 23.06.2019 unterwegs, hat dieser zwei Einträge. Er darf in der Summe dann natürlich die Summe dann nicht x Anzahl der Zeilen nehmen.

          1. Hallo Bernd,

            das klingt alles noch sehr unsortiert. In deinem Kopf ist sicherlich alles klar, aber meiner schwirrt 😂. Vor allem, weil ich die Begriffe aus deiner Beschreibung nicht auf das abgebildet bekomme, was wir bisher auf SQL Ebene diskutiert haben. Das Thema "Artikelzustand" ist darüber hinaus noch eine ganz neue Baustelle.

            Vor allem komme ich mit dem Begriff "Artikel" und "Menge" nicht klar. Angenommen, der Artikel ist "Biertisch", das liegt mir näher als Banner 😉. Du hast 10 Biertische im Inventar, und irgendwer möchte 5 bestellen. 4 sind für den fraglichen Zeitraum bereits vergeben.

            Die Artikel-ID 'a196f40a4bdb40c6551a41cdd3910d53' würde nun für "Biertisch" stehen? Oder für "Biertisch Nr. 7"?

            Und was steht in der der Reparaturentabelle? "3 Biertische kaputt"? Oder sind es 3 Einträge: "Biertisch Nr. 2 hat Kerben", "Biertisch Nr. 5 hat rostige Beine", "Biertisch Nr. 9 angebrochen"?

            Ein Lagerist müsste also einzeln schauen, wie der Zustand der im Zeitraum verfügbaren Tische ist. Kerben und rostige Beine mag akzeptabel sein, "angebrochen" sicherlich nicht.

            Du kannst also doch eigentlich nichts weiter tun als für jeden Tisch schauen, ob er im fraglichen Zeitraum keine Reservierung hat, und dann seinen Reparaturstatus dazu anzeigen. Und ein Mensch muss dann Stück für Stück schauen, ob dieser Status für das neue Projekt akzeptabel ist.

            Aber vielleicht habe ich ja auch komplett Bahnhof verstanden⁉️

            Rolf

            --
            sumpsi - posui - clusi
            1. Hallo,

              bleiben wir beim Biertisch 😉

              Lagerbestand komplett: 6 Stück

              Reparatur 1

              Lagerbestand aktuell: 5 Stück

              Projekt 1 vom 17.06.2019 - 22.06.2019 3 Stück

              Projekt 2 vom 19.06.2019 - 19.06.2019 5 Stück

              Das System muss jetzt erkenne dass der Lagerbestand aktuell 5 Stück sind (kpl. 6 - 1) und muss schauen ob im Zeitraum schon welche unterwegs sind, in meinem Fall also 3. In diesem Fall geht es nicht, es sind zwar wenn alle zurück kommen 5 da bzw. wenn der eine repariert wurde 6 aber 3 sind auf einem anderen Event. Ich kann also nur 2 bestellen.

              Die Artikel-ID 'a196f40a4bdb40c6551a41cdd3910d53'

              Genau, dieses ist intern die Artikel Id bzw. der dazugehörige Code.

              Und was steht in der der Reparaturentabelle? "3 Biertische kaputt"? Oder sind es 3 Einträge: "Biertisch Nr. 2 hat Kerben", "Biertisch Nr. 5 hat rostige Beine", "Biertisch Nr. 9 angebrochen"?

              Die Biertische sind nicht nochmals unterteilt, dieses wäre viel zu viel Arbeit. In der Reparaturentabelle steht z.B. Artikel a196f40a4bdb40c6551a41cdd3910d53 1x defekt. Der defekte ist eigentlich aus dem Lagerbestand heruasgenommen nur wenn eine Anfrage kommt und ich es nicht anderes geregelt bekomme, weil etwas nicht mehr besorgt werden kann oder die Produktion schafft es nicht mehr neu herzustellen dann wird geschaut ob ein Artikel der als Reparatur hinterlegt ist doch genommen werden kann. 100% automatisch wird es nie laufen können.

              1. Hallo Bernd,

                Die Artikel-ID 'a196f40a4bdb40c6551a41cdd3910d53' würde nun für "Biertisch" stehen? Oder für "Biertisch Nr. 7"?

                Das hast Du nicht direkt beantwortet, aber daraus

                Die Biertische sind nicht nochmals unterteilt,

                lese ich, dass die Artikel-ID den Artikel-Typ "Biertisch" bezeichnet und nicht den einzelnen Tisch. Ok.

                Und ich nehme an, es gibt eine Tabelle "Artikel", in der steht, dass Du 6 Biertische hast. Aber ich habe dich so verstanden, dass die kaputten Tische in einer separaten Tabelle gezählt werden?

                In dem Fall müsstest Du tatsächlich eine Abfrage über die Tage machen, und prüfen, ob es darunter Tage gibt wo zu wenig da ist. Dafür kann man HAVING verwenden. Das ist sozusagen ein WHERE, der auf das GROUP BY Ergebnis wirkt.

                SELECT aa_datum, COUNT(*)
                FROM artikel_ausgeliehen
                WHERE aa_status=2 
                  AND aa_artikelID=? 
                  AND aa_datum BETWEEN ? AND ?
                GROUP BY  `aa_datum` 
                HAVING COUNT(*) < ?
                

                Für das vierte Fragezeichen übergibst Du die benötigte Anzahl im Zeitraum, und bekommst eine Liste der Tage, wo zu wenig da ist. Ist das Ergebnis leer, hast Du an jedem Tag genug da. Wie Du das nun sinnvoll mit der Liste der defekten Artikel zusammendrehst, weiß ich nicht. Vermutlich hängt das auch davon ab, wie der Arbeitsprozess aussehen soll.

                Rolf

                --
                sumpsi - posui - clusi
  3. Hallo,

    ist es möglich eine Testausgabe von

    function unterwegsProjektzeitraum($mysqli, $artikelID, $Datum_von, $Datum_bis){
    
        $D_von       = explode(".",$Datum_von);
        $D_tag_von   = $D_Von[0];
        $D_monat_von = $D_Von[1];
        $D_jahr_von  = $D_Von[2];
    
        $D_bis       = explode(".",$Datum_bis);
        $D_tag_bis   = $D_bis[0];
        $D_monat_bis = $D_bis[1];
        $D_jahr_bis  = $D_bis[2];
    
        $Ausgabe_D_von = $D_jahr_von."-".$D_monat_von."-".$D_tag_von;
        $Ausgabe_D_bis = $D_jahr_bis."-".$D_monat_bis."-".$D_tag_bis;
    
        $sql = "
    
            SELECT SUM(aa_menge) AS `summe_unterwegsProjektzeitraum` 
            FROM artikel_ausgeliehen 
    
            WHERE aa_status=2 AND aa_artikelID=? AND aa_datum BETWEEN  ? AND ?
            GROUP BY aa_artikelID, aa_datum 
            
            LIMIT 1";
        
        $res = $mysqli->prepare($sql);
        $res->bind_param("sss", $artikelID, $Ausgabe_D_von, $Ausgabe_D_bis);
    
        $res->execute();
        $res->bind_result($summe_unterwegsProjektzeitraum);
        $res->fetch();
        $res->close();  
    
        return $summe_unterwegsProjektzeitraum; 
    }
    
    

    mir geben zu lassen um zu sehen was passiert? Ich dachte erst so

    var_dump($Ausgabe_unterwegsProjektzeitraum);
    

    aber da erhalte ich nur float(4) Und genau das ist auch das Problem, ich erhalte eine 4 obwohl ich eigentlich kein Wert halten würd.

    Wenn ich das SQL direkt im phpMyAdmin ausführe erhalte ich keine Einträge

    SELECT SUM( aa_menge ) AS  `summe_unterwegsProjektzeitraum` 
    FROM  `artikel_ausgeliehen` 
    WHERE  `aa_status` =2
    AND  `aa_artikelID` =  'b6af5e94a24e07076e3fe2e7a1219758'
    AND  `aa_datum` 
    BETWEEN  '2019-06-22'
    AND  '2019-06-23'
    GROUP BY  'aa_artikelID', 'aa_datum'  LIMIT 1
    

    Deshalb verstehe ich es nicht.

    1. Ok, es lag an diesem

      $D_von           = explode(".",$Datum_von);
          $D_tag_von   = $D_Von[0];
          $D_monat_von = $D_Von[1];
          $D_jahr_von  = $D_Von[2];
      
          $D_bis       = explode(".",$Datum_bis);
          $D_tag_bis   = $D_bis[0];
          $D_monat_bis = $D_bis[1];
          $D_jahr_bis  = $D_bis[2];
      
          $Ausgabe_D_von = $D_jahr_von."-".$D_monat_von."-".$D_tag_von;
          $Ausgabe_D_bis = $D_jahr_bis."-".$D_monat_bis."-".$D_tag_bis;
      

      dieses kann ich wohl nicht in der Funktion ausführen, warum auch immer. Wenn ich die Funktion von Rolf nehme und den Wert direkt an die Funktion übergeben, dann erhalte ich auch keinen Eintrag mehr.

      Aber warum ist dieses so?

      1. Hallo Bernd,

        Variablennamen in PHP sind case sensitive.

            $D_von           = explode(".",$Datum_von);
            $D_tag_von   = $D_Von[0];
        

        Was fällt Dir auf?

        Lass die E_NOTICE-Errors an, wenn du testest! Jede Notice ist eine zu viel.

        Alternativ schreib Dir einen Error-Handler für E_NOTICE und ggf. noch E_STRICT Fehler, wenn Du vermeiden willst, dass die Dir das UI versauen. Ich habe mal ein Kommandozeilenspielzeug geschrieben:

        <?php
        require_once('notice_error_handler.php');
        
        echo "Begin test\n";
        
        $a_von = 3;
        
        echo $a_Von;
        echo "\n\nEnd of test ---------------------\n\n";
        
        report_notices();
        

        Wenn ich das laufen lasse, kommt dies hier.

        Begin test
        
        
        End of test ---------------------
        
        -----------------------------------------
        You hit a snafu!
        
        E_NOTICE Undefined variable: a_Von
         - in D:\temp\php\test_notice.php7:8
        

        Der eigentlich Ablauf ist ungestört, und erst am Ende stellt sich heraus, dass unterwegs was passiert ist. Das gelingt mit diesem notice_error_handler.php:

        <?php
        $error_notices = [];
        set_error_handler('myHandlerForMinorErrors', E_NOTICE | E_STRICT);
        
        function myHandlerForMinorErrors($errno, $errstr, $errfile, $errline) 
        {
            global $error_notices;
            $error_notices[] = [
            	"type" => ($errno == E_NOTICE ? "E_NOTICE" : "E_STRICT"),
            	"message" => $errstr,
            	"location" => "$errfile:$errline"
           	];
            return true;
        }
        
        function report_notices()
        {
           global $error_notices;
           if (count($error_notices) > 0) {
              echo "-----------------------------------------\nYou hit a snafu!\n\n";
              foreach ($error_notices as $notice) {
                 echo "$notice[type] $notice[message]\n - in $notice[location]\n";
              }
           }
        }
        error_reporting(E_ALL);
        

        error_reporting steht auf E_ALL, aber für E_NOTICE Und E_STRICT ist ein custom error handler definiert, dessen Callback-Funktion TRUE zurückgibt. TRUE heißt: Alles klar, Onkel PHP, ich habe das Problem gelöst, ist nix mehr zu tun für Dich. PHP gibt dementsprechend keine Fehlermeldung mehr aus. Aber der Errorhandler hat sich die Meldung gemerkt.

        Und wenn Du report_notices() aufrufst, rotzt er alles raus.

        Das ist jetzt Spielzeug, eine reale Implementierung würde die Fehlermeldungen in HTML einpacken und in den Footer schreiben. Wenn Du es ganz komfortabel haben willst, bau noch das Ergebnis von debug_backtrace mit ein, um einen Stacktrace zu bekommen.

        Man hat zwei Möglichkeiten, sowas zu benutzen.

        Möglichkeit 1: Man hat auf der Entwickler- oder Test-Maschine eine andere Version von notice_error_handler.php als auf der Produktionsmaschine. Die Produktivversion definiert einen Dummy für report_notices und setzt error_reporting auf E_WARNING, die Testversion ist geschwätzig.

        Möglichkeit 2: Dein Web kennt einen Testschalter, mit dem man einschalten kann, dass am Ende jedes Requests report_notices aufgerufen wird. Eine PHP Anwendung von mir hat im Footer einen undekorierten Link, der in $_SESSION einen entsprechenden Schalter zwischen TRUE und FALSE umschaltet.

        Wichtig ist jedenfalls, dass Dir Notice-Error wegen undefinierter Variablen nicht entgehen.

        Rolf

        --
        sumpsi - posui - clusi
        1. n'Abend,

          Variablennamen in PHP sind case sensitive.

          das habe ich fast eine halbe Stunde früher auch schon festgestellt.

          Lass die E_NOTICE-Errors an, wenn du testest! Jede Notice ist eine zu viel.

          Absolut. Jede Notice ist ein Hinweis darauf, dass irgendwas zwar noch "beherrschbar", aber nicht einwandfrei korrekt ist.

          Alternativ schreib Dir einen Error-Handler für E_NOTICE und ggf. noch E_STRICT Fehler, wenn Du vermeiden willst, dass die Dir das UI versauen. Ich habe mal ein Kommandozeilenspielzeug geschrieben:

          Das ist ein guter Ansatz!

          Coap,
           Martin

          --
          Es gibt keine dummen Fragen - nur dumme Antworten.
          1. Hallo Martin,

            das habe ich fast eine halbe Stunde früher auch schon festgestellt.

            nein, ich glaube nicht. Das haben wir vermutlich zeitgleich festgestellt, jedenfalls stand dein Beitrag noch nicht da als ich auf "antworten" drückte.

            Aber glaubst Du, dieser myHandlerForMinorErrors Tee war fertig in der Isokanne? Den habe ich frisch aufgebrüht (mit Hilfe eines Teebeutels von stackoverflow), und dieser Ausflug in die Hexenküche hat mich 'ne halbe Stunde gekostet, bis die Brühe so schmeckte wie sie sollte und ich zurück am "speichern" Button war.

            🍵 Rolf

            --
            sumpsi - posui - clusi
            1. Hallo Rolf,

              das habe ich fast eine halbe Stunde früher auch schon festgestellt.

              nein, ich glaube nicht. Das haben wir vermutlich zeitgleich festgestellt, jedenfalls stand dein Beitrag noch nicht da als ich auf "antworten" drückte.

              du meinst, gut Ding will Weile haben?

              Aber glaubst Du, dieser myHandlerForMinorErrors Tee war fertig in der Isokanne? Den habe ich frisch aufgebrüht (mit Hilfe eines Teebeutels von stackoverflow), und dieser Ausflug in die Hexenküche hat mich 'ne halbe Stunde gekostet, bis die Brühe so schmeckte wie sie sollte und ich zurück am "speichern" Button war.

              Ah, okay. Und ich habe halt sofort "Iiih!" geschrien, als ich einen Käfer im Tee gefunden habe, ohne erst nachzuforschen, wo er herkam.

              Ciao,
               Martin

              --
              Ein Tag, an dem du nicht wenigstens einmal gelacht hast, ist ein verlorener Tag.
    2. Hallo Bernd,

          $D_von       = explode(".",$Datum_von);
          $D_tag_von   = $D_Von[0];
          $D_monat_von = $D_Von[1];
          $D_jahr_von  = $D_Von[2];
      

      PHP ist bei Variablennamen case-sensitive. Und vergleiche mal ganz genau deine Schreibweise von $D_von in den oben zitierten vier Zeilen.

      Und das ist wieder so ein Fall: Wenn du dir während der Entwicklungsphase alle Meldungen anzeigen lassen würdest, auch die Notices, dann hättest du das sofort bemerkt.

      Schönen Abend noch,
       Martin

      --
      Ein Tag, an dem du nicht wenigstens einmal gelacht hast, ist ein verlorener Tag.

      Folgende Beiträge verweisen auf diesen Beitrag: