PDA

Vollständige Version anzeigen : Ist mein FE zu benutzerfreundlich ?


chris1791
30.09.2005, 09:52
Hallo Profis,

Über Probleme wie Schreibkonflikte, oder Updateprobleme durch fehlende PrimaryKeys oder TypUnterschiede kam ich bei der Suche nach Lösungen zu dem Eindruck dass ich mir zu viele Gedanken über gleichzeitigen Zugriff oder falsche Eingaben mache...
Sogar Tipps wie: "... das passiert eh nie" oder "verwende die vom Assi erstellten Formulare - dann regelt sich alles von selbst" waren dabei...

Ist den mein Formular wirklich so "exotisch" oder gar zu benutzerfreundlich ?
Frontend_Beisp.gif
Ich krieg es nicht richtig zum Laufen - aber auf Benutzerfreundlichkeit werde ich nie verzichten!!

Falls jemand ein Beispiel zu einem benutzerfreundlichen Formular mit
- Anzeige / Bearbeitungsmodus Buttons/ Speichern und Löschen Buttons
- Wenn ich den Code sehe für Speichern und Löschen weiß ich was ich falsch mache! Ich habe verschiedene Varianten ausprobiert - die funktionieren nur als Einzelplatz-Anwendung! Sonst gibt es Fehlermeldungen und Schreibkonflikte...
Danke fürs Lesen, Chris

jernst
30.09.2005, 11:03
Hallo Chris,

ein zu benutzerfreundliches Formular gibt es nicht.

Mir sind aber bei Deinen Erläuterungen 2 Probleme aufgefallen:
1. Die Artikelnummer kann vom Nutzer vorgegeben werden. Das würde ich nicht machen, denn das gibt Fehlermöglichkeiten und ist ein Grund für Probleme mit doppelten PrimeryKeys

2. Warum speicherst Du die Daten erst lokal zwischen? Da dies auf jedem Client geschieht und global auch nicht getestet wird, ob die Artikelnummer eindeutig ist, kommt es beim Zurückschreiben auf den SQL- Server zu Problemen.

Als Lösung würde ich vorschlagen, die Artikelnummer automatisch zu generieren und den Nutzer da außen vor zu lassen.

Gruß Jörn

JörgG
30.09.2005, 11:06
Hallo Chris,

"Benutzerfreundlich" da streite ich mit Dir :p , wieviele User kennst Du die mit Chr35, aend_flag, Enabled, Integer & Co etwas anfangen können, ich glaube Deine 4 Buttons sind aussagekräftig genug da braucht es keine verwirrenden Erklärungen, die fortgeschrittene Ac-Kenntnisse vorraussetzen. Die Textfelder oben lassen sich bestimmt vorformatieren bzw eine Prüfung nach Änderung vornehmen um Fehleingaben zu vermeiden.
Wenn Du unbedingt Erklärungstexte einbauen willst, dann schreib sie als Tipptext und verzichte dabei auf Fachbegriffe.

PS: ich möchte Dein Formular nicht niedermachen, soll als Denkanstoss dienen :biggrinl:

J_Eilers
30.09.2005, 11:08
Hi,

Keine Ahnung, ob man das zu Benutzerfreundlich nennt, aber Inkosistenz ist in meinen Augen kein Kavalliersdelikt. Und eine PK sollte immer etwas sein, was der User nicht sieht und auch niemals verändern / erstellen kann. Man kann ja statt dessen einen eigene Nummer für die Augen des Users nehmen, aber das sollte kein Feld sein, welches für die eindeutige Identifikation des DS verwendet wird!

chris1791
30.09.2005, 11:25
@Alle: Danke für Eure Schnelle Antwort!

@Jörn:
1. Die Artikelnummer kann vom Nutzer vorgegeben werden. Das würde ich nicht machen, denn das gibt Fehlermöglichkeiten und ist ein Grund für Probleme mit doppelten PrimeryKeys

Antwort: ArtNr ist kein AutoWert - kann sich ändern im Laufe der Zeit - muss gepflegt werden können - vieleicht ein recID als AutoWert in Tabelle und ArtNr nur als eindeutiger index verwenden?

2. Warum speicherst Du die Daten erst lokal zwischen? Da dies auf jedem Client geschieht und global auch nicht getestet wird, ob die Artikelnummer eindeutig ist, kommt es beim Zurückschreiben auf den SQL- Server zu Problemen.
Antw2: Ich arbeite mit einem ungeb. Formular, Cursor ist Clientseitig. Beim Speichern wird rs.update durchgeführt, gleich danach conn geöffnet rs.updatebach und wieder die conn geschlossen. Für andere Lösung wäre ich dankbar!

@JörgG:
Vielleicht nur ein Missverständnis: Im Bild ist nur ein Beispielformular für das Forum damit man versteht was in den Feldern drin sein soll bzw was die Buttons machen sollen. Ich versichere Dir dass wenn mir als User jemand so ein Formular vorliegen würde wie jetzt abgebildet - dann könnte ich für nichts garantieren!

@Jan:
Mal wieder ein guter Denkanstoß von Dir. Soll das im Klartext bedeuten dass man generell die PrimKeys dem Benutzer höchstens anzeigen sollte, aber keinesfals zum bearbeiten? Sollte ich zB generell eine PK als AutoWert nehmen?

Gruß Chris

J_Eilers
30.09.2005, 11:40
Ja, mit einer Ausnahme verwende ich nur Autowerte als PK's und bin damit bisher noch nicht auf die Nase gefallen. Für den User kann man ja gern irgendwelche Zahlengerüste herstellen. Als Beispiel kann man zB Artikelnummern nehmen. Lieber verwende ich eine ArtikelID und eine Artikelnummer, als dass ich die Daten pflegen muss, falls mal Artikelnummern wegfallen und die alte Nummer wiederverwendet wird. Mit der ID ist mir das ziemlich egal.

chris1791
30.09.2005, 11:47
@Jan:
Soweit so gut, aber was passiert wenn 2 user gleichzeitig einen DS anlegen?
User1: ArtNr1 und recID 33 (weil bisher 32 DS)
User2: ArtNr2 und recID auch 33 da das recset nicht connected ist - würde beim rückschreiben auf dem Server doch zu Fehler führen!
Oder wie macht man das?
Gruß Chris