6ed61a6b3d76d4be5c618616f1e9f14f322a013f
"jetzt hab ich eine hochgeladen ber sehe sie nicht."
WAS PASSIERT IST, aus der Datenbank gelesen und nicht vermutet: Seine
Backstage-Ausgabe lief durch den EINZEL-Import ("Aus Datei einlesen")
und schrieb genau eine Zeile -- creator_id 2, Tag 2026-09-01, alle
Werte 0, Quelle "import", erfasst 11:52. Unsichtbar war sie aus zwei
Gruenden: Der 1. September liegt 13 Tage zurueck (die Liste zeigt
sieben), und es stand nichts darin.
DREI FEHLER AUF EINMAL, und alle drei waren meine:
1. DER ZEITRAUM-SCHUTZ STAND NUR IM BACKSTAGE-WEG. Ich hatte ihn heute
frueh gebaut, gemessen, geprueft -- und an genau einer von drei
Stellen eingesetzt. "2026-09-01 ~ 2026-09-11" wurde im Einzel-Import
weiterhin zum 1. September.
Das ist an diesem Tag das DRITTE Mal dieselbe Sache: eine Regel,
zweimal aufgeschrieben, und die zweite Abschrift ist die
unvollstaendige. Jetzt steht sie EINMAL in `tagAusZelle()` und wird
dreimal benutzt. Sie liefert immer genau eines von beidem: Tag oder
Grund -- nie beides, nie keines.
2. DIE DAUER-EINHEIT FEHLTE DORT EBENFALLS. Auch das hatte ich nur im
Backstage-Weg eingesetzt.
3. DIE DATEI GEHOERTE GAR NICHT DORTHIN. Sie enthaelt ALLE
Creator:innen; der Einzel-Import schreibt auf EINE Person. Es gab
keine Fehlermeldung -- es passierte nur nichts Sichtbares, und das
ist die schlechteste aller Antworten.
Jetzt erkennt der Weg eine Namensspalte mit mehreren verschiedenen
Eintraegen und sagt: "In dieser Datei stehen 3 verschiedene Creator
(Spalte ...). Dieser Weg schreibt auf EINE Person. Nimm
'Backstage-Tabelle einfuegen'." Mit Gegenprobe, dass eine Datei mit
EINEM Creator weiterhin durchgeht.
pruef-xlsx 60 -> 67, pruef-backstage-import 82 -> 86.
NEBENBEFUND AUS DER EIGENEN PRUEFUNG: Mein Testfile fuer den
Einzel-Import hatte selbst zwei verschiedene Creator -- die neue Sperre
hat es sofort abgewiesen. Das war ihr erster echter Treffer, und es
zeigt, dass ich den Weg beim Schreiben der Pruefung selbst falsch
verstanden hatte. Jetzt steht dort, wofuer er da ist: eine Person,
mehrere Tage.
Die Zeile vom 1. September steht noch in der Datenbank. Sie zu
entfernen ist Filipes Entscheidung, nicht meine.
Co-Authored-By: Claude Opus 5 <[email protected]>
Description
No description provided
726 MiB
Languages
JavaScript
77.7%
CSS
13.1%
HTML
9%
Shell
0.2%