Gliederung

Naja, aber wenn man zwar beginnt, den Datensatz anzulegen, das ganze dann aber doch wieder abbricht und nichts in der Datenbbank speichert?

Dass das ganze eine Notbehelfslösung ist, habe ich ja schon erwähnt. In den meisten Fällen wird das automatisch erzeugte Schlüsselfeld besser geeignet sein (und erwartungsgemäß funktionieren). Manchmal will man aber z.B. den automatischen Schlüssel mit einem eigenen Prä- oder Postfix versehen, oder sonstwie weiter manipulieren. Genau dafür gibt es leider keine Funktionen, um auf den Schlüssel des letzten Datensatzes zuzugreifen oder die ID des neuen Datensatzes zu erfahren. In Ermangelung solcher Funktionen entstehen dann eben die Krücken …

Dann HAT man ihn erst einmal angelegt, wodurch die Formel, die den Zähler eins hochzählt, greifen muss. Das ist konsequent logisch. Und Absicht:

Das ist so nämlich durchaus überlegt konform mit der Anforderung an Fakturierungs- und Rechnungs-Programme, und auch daraus entstanden.

Wenn man eine neue Rechnung auch nur angelegt hat, DÜRFEN die gar nicht “einfach so” per Undo oder Löschung entfernt werden.

Eine einmal angelegte Rechnung, die man nicht fertig schreibt, muss tatsächlich storniert werden, d.h., es gibt diese Rechnungsnummer eben auch.

Sprich, die einzige Lösung wäre, wenn man dieser Bedingung weiter folgen will (und, je nach Einsatzart, muss), dass es eine weitere Formel-Möglichkeit für “Datensatz löschen” gibt, die dann ggf. (wenn man z.B. Rechnungen schreibt) solche nicht benutzten Zähler-Inhalte irgendwo extra speichert.

Die Absicht kann ich durchaus verstehen. Allerdings würde ich den Vorgang des Datensatz-Anlegens erst dann als durchgeführt betrachten, wenn der Benutzer auch auf “Setzen” oder “Anlegen” geklickt und die eingegebenen Daten damit bestätigt hat. Solange das nicht geschehen ist, hat der Benutzer nur einen Entwurf des Datensatzes vor sich, der aber noch nicht in der Datenbank gespeichert wurde. Bei einem Stromausfall in diesem Moment wären die Daten futsch und die Datenbank-internen Zähler bereits hochgezählt. Auch nicht im Sinne des Erfinders, oder?

@glucose

Ich sehe jetzt irgendwie nicht so sehr das Problem - bei einem solchen Zählerfeld ist doch bloß relevant, dass es sich streng monoton verhält. Lückenlose Reihen hat man auch nicht mehr wenn erst einmal alte Datensätze wieder gelöscht werden. Ich glaube auch nicht, dass einem so schnell die Zähler ausgehen.

Grüße,

Jochen

In einigen Fällen müssen die Reihen auch lückenlos sein, z.B. bei Rechnungsnummern.

Naja. Eine Rechnungsnummer ist dann vergeben, wenn man die Rechnung verschickt oder den Vorgang “Rechnung erzeugen” auslöst (womit im Normalfall ReNr und Buchungseinträge in die Datenbank überführt werden). Denn vorher kann ich z.B. problemlos die Adresse ändern, oder ich will das Ganze vorerst nur als Angebot verwenden, etc. - eine Stornierung erzwingen wäre schlechtes Datenbank-Design (und gibt vor allem die ReNr nicht mehr frei, ich muss eine “Leerrechnung” erzeugen und buchen, um die Lückenlosigkeit zu haben). Grundsätzlich sollte ein “Zähler” vom Typ “Letzter Wert plus irgendwas” immer das nehmen was da ist, und nicht das, was er glaubt, dass es jetzt richtig sei. Wenn also die Variable sich allein durch Starten der Datenbank oder sonstige Navigationsaktivitäten ändert, taugt sie nicht für einen “soliden” Zähler.

Eine “vorausgerechnet vergebene” Nr. führt zwangsläufig zu Löchern in der Nummerierung, die ebenso zwangläufig nicht auffallen müssen. Dann muss eine versehentlich geöffnete Datenbank erst mal wieder eingefangen werden, weil die Nummer hochgezählt wurde. Wobei noch immer unklar ist, wie die überhaupt initialisiert wird (woher kennt die Variable den letzten Wert aus der Datenbank? Sobald ich den sauber ermitteln kann, ist das hier eine überflüssige Diskussion…).

Das mag ja sein, dass Mac-Nutzer eher mit der Maus arbeiten als Windows Nutzer. Ob das womöglich daran liegt, dass es auf dem Mac eher selten Programme gibt, die Tastensteuerbar sind (zumindest ist das mein - zugegebenermaßen sehr alter - Wissensstand) und dieses Vorgehen daher vom System erzwungen wird, sei mal dahin gestellt. Ob Windows - weil von Dos kommend - „unmausiger“ als ein Mac ist, würde ich spätestens ab Windows XP nicht mehr ohne Rot werden behaupten.

Fraglos hat es auch was philosophisches, ob Mausgerutsche oder Tastengeklappere das Mittel der Wahl ist. Das «Anklicken müssen» von Bildflächen ist irgendetwas dazwischen. Ich muss – was meine Erfahrungen betrifft – einräumen, dass ich eher mit „Einfachnutzern“ Kontakte habe und sehe, wie die sich motorisch mit der Maus quälen. Für einen Routinier ist es sicherlich einfacher, mal eben etwas in einem TreeView zu markieren, den mit einem Schlenker neu zu positionieren und die Markierung „fallen zu lassen“. Ich weiß halt, wie schwer sich manche tun, allein aus einem Absatz einen Satz zu markieren und per Drag´n Drop innerhalb dieses Absatzes zu verschieben (ohne Scrollen des Textes). Von der Problematik, dass man bei verschiedenen Betriebssystemen bei der Entwicklung noch mit deren individuellen Widrigkeiten kämpfen muss, mal ganz abgesehen.

Muss dann aber ein wirklich recht alter Wissensstand sein ;). Man kann in Mac OS X nahezu alles mit der Tastatur bedienen. In Textfeldern funktioneren sogar u. A. viele Emacs-Tastenkombinationen wie Strg-A/-E-/-F/-B/-P/-N (Zeilenanfang/-ende, Vorwärts, Rückwarts, letzte Zeile, nächste Zeile). Die Tastenbefehle sind für alle Anwendungen in den Systemeinstellungen zentral einstellbar - ALLES was einen eindeutigen Menünamen hat kann automatisch per Tastenkombination anwendungsspezifisch belegt werden. Ich bin selbst ja “erst” seit Mac OS X 10.3 (also etwa 6-7 Jahre) dabei - ob das alles vorher (z.B. zu Zeiten von Mac OS 9) anders war kann ich daher nicht sagen :). Ich kam vorher eher aus der Unix (BSD und Linux) Ecke; Mac OS 9 wäre für mich nie in Frage gekommen; OS X war (und ist) für mich immer noch ein solides Unix mit hervorragender, konsistenter und schlicht-funktioneller Benutzerschnittstelle.

Ich meinte eigentlich gar nicht so sehr, dass Windows unmausiger ist; nur dass speziell dieses Drag&Drop-Konzept im Vergleich zu NextStep (Quasi-Vorgänger von OS X) und Mac OS X weniger durchgängig Anwendung findet. Beim Einsortieren in TreeViews zeigt Mac OS X z. B. automatisch “Hilfslinien” an. Anhand dieser kann man erkennen, zwischen welchen Knoten und auf welcher Ebene der genommene Knoten eingefügt werden wird. In jedem Papyrus-Dokumentfenster sieht man auch ein “Proxy-Icon” des Dokuments - das kann man ebenfalls einfach ziehen und benutzen als ob es ein Dateiicon im Finder wäre. Klickt man rechts darauf, dann sieht man eine Liste der Verzeichnisse des Pfades. Anwendungen oder Icons in der Menüleiste entfernt man auch einfach durch herausziehen und fallenlassen. Das Konzept hinter Drag & Drop ist “Direct Manipulation” - der Gedanke, dass es intuitiver und effizienter ist, wenn man Objekte einfach direkt und nicht nur über indirekte Befehle manipulieren kann.

Am Anfang meiner Mac OS X Zeit hatte ich da noch weniger ein Problem damit. Jeder der die Situation von Linux-Desktops vor 6-7 Jahren kennt, weiß, dass Einheitlichkeit und konsistentes, vorhersehbares Verhalten nichts ist was man dabei lernte - Doch gerade das gewöhnt man unter Mac OS X sehr schnell! Ich hätte das vorher selbst nie gedacht. Diese Kontinuität hat einen enormen Vorteil: Sie ermutigt einen das System ernsthaft zu lernen, weil es sich bezahlt macht; man kann das Erlernte in fast jeder Anwendung benutzen. Apple macht es Entwicklern dabei erstaunlich leicht: Cocoa ist so implementiert, dass Anwendungen all diese Features oft ohne großes Zutun erhalten. Ich vermute, dass deshalb Mac OS X Nutzer schneller von solchen “Kleinigkeiten” angenervt sind als jene anderer Systeme. Bei Windows ist man eher gewohnt dass oft alles immer ein bisschen anders ist. Ich behelfe mir auf meinen Windows-Maschinen einfach damit, dass ich sie massiv “anpasse”.

Grüße,

Jochen

So unterschiedlich kann Wahrnehmung sein. Ich habe mich unter Mac immer “gegängelt” gefühlt, weil es “nur so und nicht anders” geht. So scheint die Philosophie ja noch immer zu sein. Das ist zwar hinsichtlich Konsistenz fraglos toll, aber den Verkaufszahlen nach hat es nicht geholfen.

@ Ulli: zwischendurch noch einmal kurz zur Mindmap/Inhaltsübersicht: Ein grandioser Gedanke!

Im Übrigen habe ich gerade für ein Review die etwas kleinere Version dieses Gedankens getestet. Schau dir doch mal NovaMind Screenwriting an (www.novamind.com). Vielleicht inspiriert euch ja der eine oder andere dort eingeschlagene Weg ein wenig :slight_smile: