Pflichtfelder in NAV 5.0
5. August 2007 04:46
Hallo zusammen,
ich bin neu in diesem Forum da ich mich erst seit wenigen Wochen mit Navision und dessen Einführung in unserem Unternehmen befasse.
Mein Problem ist die Erstellung von Pflichtfeldern bzw. die Datenverwaltung von Navision. Ich habe in der Suche bereits geschaut, und auch versucht über Google Antworten zu finden. Aber bislang konnte ich von niemandem eine machbare Lösung finden. Problem ist u.a. auch, dass wir die Business Essentials einsetzen, wobei so eine einfache Sache keine Advanced Edition erfordern dürfte.
Ich finde es ziemlich merkwürdig, naja, fast schon unglaublich, dass es scheinbar keinen einfachen Weg zur Erstellung von Pflichtfeldern in Dynamics NAV gibt; und das schon offensichtlich seit vielen Versionen. Seit einiger Zeit lässt sich NAV neben dem NAV-Datenbankserver ja auch auf dem richtigen SQL Server verwenden. Man sollte meinen, dass Microsoft hieraus auch alle Vorteile ziehen würde. Was ich aber entdeckt habe, ist für mein Verständniss als Programmierer von Datenbanken völlig unverständlich.
Ein Beispiel:
Im Betrieb mit einem SQL Server sind ja dort in der Datenbank für jeden Mandanten die einzellnen Tabellen hinterlegt. Wenn man sich eine Tabelle einmal ansieht (Beispiel hier: Employee), dann stelllt man fest, dass nur das Feld für das BLOB des Mitarbeiterfotos die Eigenschaft "NULL zulassen" besitzt. Ergo sollte man annehmen, dass alle anderen Felder auszufüllen, somit Pflichtfelder sind; und jetzt macht es sich NAV sehr einfach:
NAV legt beim Erstellen eines neuen Datensatzes sofort den Datensatz in der Datenbank an. Zum Zeitpunkt des Anlegens existiert aber in diesem Datensatz allerdings noch nichts außer der von der Nummernserie vergebenen ID - man konnte ja auch vorher bzw. so schnell noch nix eingeben. Dies stellt eigentlich ein Problem dar, wenn man sich an die vorhin erwähnten fehlenden "NULL zugelassen"-Felder in den DB-Tabellen erinnert. Nun sollte man meinen, dass nur ID in dem Datensatz der Datenbanktabelle ausgefüllt ist, und die restlichen Felder ersteinmal ein NULL enthalten müssten (was ja aber nicht gehen würde, denn NULL ist bei nur dem einem Feld in der Mitarbeitertabelle zugelassen). Daher geht NAV kurzerhand hin und setzt ersteinmal überall, in jedes Feld des Datensatzes (Vorname, Name, ...) einen leeren Eintrag ohne Textinhalt und entfernt somit aber das logisch korrekte NULL. Damit kann der Datensatz gespeichert werden obwohl er unkomplett ist. Mit diesem Zug macht sich Navision die Möglichkeit selber kaputt, SQL-seitig prüfen zu können, ob Felder nicht ausgefüllt wurden. Somit existiert NULL in einem Datensatz bei NAV eigentlich nie!
Alles was NAV machen müsste, wäre den SQL-Error, beim Einfügen von NULL in ein nicht-NULL Feld, abzufangen und in aufbereiteter Form à la "Sie haben das Feld <FELDNAME> nicht ausgefüllt!" an den User weitergeben und erst dann wegschrieben, wenn die als NULL-unzulässigen Felder im Formular ausgefüllt wurden. Dann wäre Konsistenz gesichert und keine unvollständigen Datensätze vorhanden.
Ich denke über diese Praxis bzw. Vorgehensweise nun seit Tagen nach und mir fällt einfach kein Grund ein, wieso dies nicht so gemacht wird.
Wieso lässt man nicht SQL-seitig die Pflichtangaben steuern oder wieso fügt man nicht noch eine Objekteigenschaft "Pflichtfeld JA/NEIN" den Formularfeldern hinzu?
Es wäre weder viel programmiertechnischer Aufwand noch würde es vorhandene Funktionen einschränken. Es würde allerdings eine Fahigkeit schaffen, die selbst simpelste dynamische Webseiten und Access-Datenbanken bieten können.
Wenn es wirklich keine Lösung ansonsten dafür gibt, finde ich es sehr traurig, dass ein ERP-Programm den Benutzer mit so etwas simplem dermaßen im Regen stehen lässt und BE-Usern gar ohne Mehrkosten unmöglich macht.
Ich freue mich auf Eure Kommentare!
LG
Martin
ich bin neu in diesem Forum da ich mich erst seit wenigen Wochen mit Navision und dessen Einführung in unserem Unternehmen befasse.
Mein Problem ist die Erstellung von Pflichtfeldern bzw. die Datenverwaltung von Navision. Ich habe in der Suche bereits geschaut, und auch versucht über Google Antworten zu finden. Aber bislang konnte ich von niemandem eine machbare Lösung finden. Problem ist u.a. auch, dass wir die Business Essentials einsetzen, wobei so eine einfache Sache keine Advanced Edition erfordern dürfte.
Ich finde es ziemlich merkwürdig, naja, fast schon unglaublich, dass es scheinbar keinen einfachen Weg zur Erstellung von Pflichtfeldern in Dynamics NAV gibt; und das schon offensichtlich seit vielen Versionen. Seit einiger Zeit lässt sich NAV neben dem NAV-Datenbankserver ja auch auf dem richtigen SQL Server verwenden. Man sollte meinen, dass Microsoft hieraus auch alle Vorteile ziehen würde. Was ich aber entdeckt habe, ist für mein Verständniss als Programmierer von Datenbanken völlig unverständlich.
Ein Beispiel:
Im Betrieb mit einem SQL Server sind ja dort in der Datenbank für jeden Mandanten die einzellnen Tabellen hinterlegt. Wenn man sich eine Tabelle einmal ansieht (Beispiel hier: Employee), dann stelllt man fest, dass nur das Feld für das BLOB des Mitarbeiterfotos die Eigenschaft "NULL zulassen" besitzt. Ergo sollte man annehmen, dass alle anderen Felder auszufüllen, somit Pflichtfelder sind; und jetzt macht es sich NAV sehr einfach:
NAV legt beim Erstellen eines neuen Datensatzes sofort den Datensatz in der Datenbank an. Zum Zeitpunkt des Anlegens existiert aber in diesem Datensatz allerdings noch nichts außer der von der Nummernserie vergebenen ID - man konnte ja auch vorher bzw. so schnell noch nix eingeben. Dies stellt eigentlich ein Problem dar, wenn man sich an die vorhin erwähnten fehlenden "NULL zugelassen"-Felder in den DB-Tabellen erinnert. Nun sollte man meinen, dass nur ID in dem Datensatz der Datenbanktabelle ausgefüllt ist, und die restlichen Felder ersteinmal ein NULL enthalten müssten (was ja aber nicht gehen würde, denn NULL ist bei nur dem einem Feld in der Mitarbeitertabelle zugelassen). Daher geht NAV kurzerhand hin und setzt ersteinmal überall, in jedes Feld des Datensatzes (Vorname, Name, ...) einen leeren Eintrag ohne Textinhalt und entfernt somit aber das logisch korrekte NULL. Damit kann der Datensatz gespeichert werden obwohl er unkomplett ist. Mit diesem Zug macht sich Navision die Möglichkeit selber kaputt, SQL-seitig prüfen zu können, ob Felder nicht ausgefüllt wurden. Somit existiert NULL in einem Datensatz bei NAV eigentlich nie!
Alles was NAV machen müsste, wäre den SQL-Error, beim Einfügen von NULL in ein nicht-NULL Feld, abzufangen und in aufbereiteter Form à la "Sie haben das Feld <FELDNAME> nicht ausgefüllt!" an den User weitergeben und erst dann wegschrieben, wenn die als NULL-unzulässigen Felder im Formular ausgefüllt wurden. Dann wäre Konsistenz gesichert und keine unvollständigen Datensätze vorhanden.
Ich denke über diese Praxis bzw. Vorgehensweise nun seit Tagen nach und mir fällt einfach kein Grund ein, wieso dies nicht so gemacht wird.
Wieso lässt man nicht SQL-seitig die Pflichtangaben steuern oder wieso fügt man nicht noch eine Objekteigenschaft "Pflichtfeld JA/NEIN" den Formularfeldern hinzu?
Es wäre weder viel programmiertechnischer Aufwand noch würde es vorhandene Funktionen einschränken. Es würde allerdings eine Fahigkeit schaffen, die selbst simpelste dynamische Webseiten und Access-Datenbanken bieten können.
Wenn es wirklich keine Lösung ansonsten dafür gibt, finde ich es sehr traurig, dass ein ERP-Programm den Benutzer mit so etwas simplem dermaßen im Regen stehen lässt und BE-Usern gar ohne Mehrkosten unmöglich macht.
Ich freue mich auf Eure Kommentare!
LG
Martin
Re: Pflichtfelder in NAV 5.0
5. August 2007 09:45
finius hat geschrieben:Hallo zusammen,
ich bin neu in diesem Forum da ich mich erst seit wenigen Wochen mit Navision und dessen Einführung in unserem Unternehmen befasse.
Und das um 4 Uhr morgens - Respekt! Dann erst einmal viel Spaß bei uns!
Ich finde es ziemlich merkwürdig, naja, fast schon unglaublich, dass es scheinbar keinen einfachen Weg zur Erstellung von Pflichtfeldern in Dynamics NAV gibt; und das schon offensichtlich seit vielen Versionen.
Doch, vom Standard her gibt es eine Möglichkeit: Du kannst jedem einzelnen Tabellenfeld von Navision statt SQL-Server aus die Eigenschaft NotBlank = Yes setzen und dein gewünschter Effekt tritt ein.
Diese Einschränkung gilt dann für ausnahmslos jeden, der auf der Navision-Datenbank agiert. Möchtest du jetzt noch differenzieren (NotBlank nur für einzelne Benutzer setzen), ist Individualprogrammierung notwendig. Diese ist für dieses spezielle Problem aber sicherlich schon fertig erhältlich.
Wieso lässt man nicht SQL-seitig die Pflichtangaben steuern oder wieso fügt man nicht noch eine Objekteigenschaft "Pflichtfeld JA/NEIN" den Formularfeldern hinzu?
Gibts doch schon, wie wir also eben festgestellt haben
- nur halt nicht SQL-seitig. Wozu auch? Die Eigenschaft muss schließlich auch Kunden zur Verfügung stehen, die Navision nicht SQL-seitig nutzen.Onlinehilfe hat geschrieben:NotBlank
Use this property to force the user to make an entry into this field, if the user has selected this field.
Applies to
Fields, text boxes
Comments
If you want to force the user to make an entry into this field before saving the record to the database, use the OnBeforePutRecord trigger for that purpose.
You can use this property together with the InitValue property to make sure an entry is made into this field. The system checks this setting for both the control and field during validation.
See also MinValue, MaxValue, and Numeric.
Ich gebe zu: Die Lösung ist nicht ganz so einfach und elegant wie dein Weg über den SQL-Server, aber ich wollte damit nur widerlegen, dass es die Möglichkeit vom Standard her schon gibt
5. August 2007 13:20
Auch von mir ein herzliches Willkommen in unserer Community!
Mit der Boardsuche hättest du unter dem Suchbegriff "Pflichtfeld" (unter anderem) eine umfangreiche Diskussion zum Thema "Pflichtfelder" gefunden, wo die verschiedenen Lösungswege aufgezählt wurden:
Pflichtfelder in Navisionmaske
Die Philosophie von Navision sieht keine Pflichtfelder vor, da Stammdaten auch unvollständig erfasst werden können dürfen.
Erst, wenn die Daten verwendet werden, prüft Navision bestimmte Felder.
Mit der Boardsuche hättest du unter dem Suchbegriff "Pflichtfeld" (unter anderem) eine umfangreiche Diskussion zum Thema "Pflichtfelder" gefunden, wo die verschiedenen Lösungswege aufgezählt wurden:
Pflichtfelder in Navisionmaske
Die Philosophie von Navision sieht keine Pflichtfelder vor, da Stammdaten auch unvollständig erfasst werden können dürfen.
Erst, wenn die Daten verwendet werden, prüft Navision bestimmte Felder.
5. August 2007 14:58
zu Natalie:
Hi und vielen Dank für den Willkommensgruß. Das mit dem NotBlank-Property habe ich natürlich in der Pflichtfeld-Diskussion hier im Forum schon gelesen gehabt. Aber ich gebe mich mit der Lösung deswegen nicht zufrieden, weil es für mich kein wirkliches Pflichtfeld ist. Ich kann doch vom User (wir erinnern uns an den DAU) nicht verlangen, dass er erst einmal alle Felder der Maske durchklickt, die er vielleicht ja gar nicht erst ausfüllen möchte, um dann festzustellen, dass er ein Feld nicht leerlassen darf. Mit dem NotBlank-Property können also nicht wirklich Pflichtfelder erreicht werden. Spätestens mit der neuen 5.1er Version im kommenden Jahr stünde zumindest einer SQL-seitigen Prüfung nichts mehr im Weg. Denn wirklich datenbankkonform sind diese Leereinträge m.E. nicht.
Wenn man bei den NotBlank-Feldern bleiben möchte, müsste man zumindest schon im Standard (für BE User) für Formulare eine Logik hinterlegt haben, welche beim Wechsel oder Schließen eines Formulars prüft, ob alle NotBlank-Felder der Maske wirklich ausgefüllt wurden und evtl. dann das Wechseln verweigert. Das hilft zwar noch immer nicht gegen die Dateninkonsistenz (denn ich kann ja den Navision-Prozess einfach abschließen, obwohl der halbleere Datensatz weiterhin in der DB existiert), aber es wäre zumindest ein erster Schritt der es dem User schwerer Macht NotBlank-Felder "blank" zu lassen. Am saubersten wäre es aber, erst dann einen Datensatz anzulegen, wenn die NotBlank-Felder ausgefüllt sind.
zu Timo:
Auch dir einen guten Tag!
Naja, ich hatte ja erwähnt dass ich schon danach gesucht habe. Ich habe die von dir erwähnte Diskussion auch gefunden. Aber ich wollte zum Einen wissen ob es bei Version 5.0 evtl. Änderungen hierbei gab (Schließlich nutzen mir Programmierungen nix wenn ich nur die BE einsetze). Außerdem finde ich es nunmal schwer zu glauben, dass es eine richtige Pflichtfeld Funktionalität nicht existiert. Ich habe kürzlich den Produktmanager von Microsoft Ole Fjordside (ein sehr netter Däne mit einem sympathischen "S"-Fehler) in einem Roadshow Seminar in Bad Homburg gesprochen und habe vor ihn in der kommenden Woche einmal auf diese Sache anzusprechen.
Hi und vielen Dank für den Willkommensgruß. Das mit dem NotBlank-Property habe ich natürlich in der Pflichtfeld-Diskussion hier im Forum schon gelesen gehabt. Aber ich gebe mich mit der Lösung deswegen nicht zufrieden, weil es für mich kein wirkliches Pflichtfeld ist. Ich kann doch vom User (wir erinnern uns an den DAU) nicht verlangen, dass er erst einmal alle Felder der Maske durchklickt, die er vielleicht ja gar nicht erst ausfüllen möchte, um dann festzustellen, dass er ein Feld nicht leerlassen darf. Mit dem NotBlank-Property können also nicht wirklich Pflichtfelder erreicht werden. Spätestens mit der neuen 5.1er Version im kommenden Jahr stünde zumindest einer SQL-seitigen Prüfung nichts mehr im Weg. Denn wirklich datenbankkonform sind diese Leereinträge m.E. nicht.
Wenn man bei den NotBlank-Feldern bleiben möchte, müsste man zumindest schon im Standard (für BE User) für Formulare eine Logik hinterlegt haben, welche beim Wechsel oder Schließen eines Formulars prüft, ob alle NotBlank-Felder der Maske wirklich ausgefüllt wurden und evtl. dann das Wechseln verweigert. Das hilft zwar noch immer nicht gegen die Dateninkonsistenz (denn ich kann ja den Navision-Prozess einfach abschließen, obwohl der halbleere Datensatz weiterhin in der DB existiert), aber es wäre zumindest ein erster Schritt der es dem User schwerer Macht NotBlank-Felder "blank" zu lassen. Am saubersten wäre es aber, erst dann einen Datensatz anzulegen, wenn die NotBlank-Felder ausgefüllt sind.
zu Timo:
Auch dir einen guten Tag!
Naja, ich hatte ja erwähnt dass ich schon danach gesucht habe. Ich habe die von dir erwähnte Diskussion auch gefunden. Aber ich wollte zum Einen wissen ob es bei Version 5.0 evtl. Änderungen hierbei gab (Schließlich nutzen mir Programmierungen nix wenn ich nur die BE einsetze). Außerdem finde ich es nunmal schwer zu glauben, dass es eine richtige Pflichtfeld Funktionalität nicht existiert. Ich habe kürzlich den Produktmanager von Microsoft Ole Fjordside (ein sehr netter Däne mit einem sympathischen "S"-Fehler) in einem Roadshow Seminar in Bad Homburg gesprochen und habe vor ihn in der kommenden Woche einmal auf diese Sache anzusprechen.
Re: Pflichtfelder in NAV 5.0
6. August 2007 19:48
finius hat geschrieben:Daher geht NAV kurzerhand hin und setzt ersteinmal überall, in jedes Feld des Datensatzes (Vorname, Name, ...) einen leeren Eintrag ohne Textinhalt und entfernt somit aber das logisch korrekte NULL. Damit kann der Datensatz gespeichert werden obwohl er unkomplett ist. Mit diesem Zug macht sich Navision die Möglichkeit selber kaputt, SQL-seitig prüfen zu können, ob Felder nicht ausgefüllt wurden. Somit existiert NULL in einem Datensatz bei NAV eigentlich nie!
Hallo,
um es kurz zu machen, du bedenkst nicht, dass NAV nur für den SQL-Server adaptiert wurde. Und du vergisst, dass für NAV ein Datensatz, der einen vollständigen Primärschlüssel hat, kein unkompletter Datensatz ist. Warum auch? Wie nervig ist es doch in anderen Datenbanken, wenn man anfängt einen Datensatz anzulegen, dann möchte man ihn speichern, man bekommt die Meldung, dass ein Feld nicht leer sein darf. Und nun? Ich breche die Aktion ab, um nachzusehen, welcher Wert in das Feld rein muss und fange von vorne an Daten einzugeben. Oder ich muss meinen Kollegen holen, weil der eigentlich für das Befüllen des entsprechenden Feldes zuständig ist. Alles nicht optimal!
NAV hat einfach als Grundprinzip: ich prüfe so spät wie möglich und so früh wie nötig. Genau aus diesem Grund werden viele Prüfungen erst vorgenommen, wenn ich einen Artikel in einem Beleg nutzen möchte bzw. wenn ich eine Buchung des Beleges vornehme. Warum auch früher? Ich finde diesen Ansatz bis heute innovativ und sinnvoll.
Daten nachpflegen kann ich immer. Aber manchmal fehlt mir einfach eine Information, um einen Datensatz genau jetzt anzulegen.
Gruß
Tim
6. August 2007 22:04
Hallo Tim,
das mag alles schon sein.
Aber ist mein Denkansatz wirklich so abwägig?
Der Punkt ist der, dass wir so ein System extra einführen wollen um Klarheit zu schaffen und Datenleichen aus unserer Firma zu verbannen. Und unserer Ansicht nach macht dieses fehlende Feature dort leider wieder Tür und Tor auf. Was für dich bis heute sinnvoll und innovativ ist, empfinde ich (und wie ich in den Ein oder Anderen Foren lese noch mehr User) einfach als fehlendes Zusatzfeature.
Eine Massenmarkt-Software sollte immer die Interessen aller Nutzer abdecken. Mit Programmen der Office-Line hat Microsoft es -zugegeben in einem etwas längeren Entwicklungszeitraum als es bei Navision bislang der Fall ist- geschafft so ziemlich alle Bedürfnisse der User abzudecken. Manchmal wirken vielleicht sogar die Programme ein wenig überladen. Aber das finde ich persönlich immernoch besser als würden Funktionen fehlen.
Für mich ist ein Datensatz der bis auf ne ID nur aus NULL bestehen würde (wenn NAV dies nicht umnödeln würde) nunmal inkomplett. Wozu auch einen leeren Datensatz erstellen? Interessant wird's erst wenn die essentiellen Angaben drinstehen. Sonst brauche ich gar keinen Datensatz. Und genau diese Angaben sollen bei uns eben Pflichtfelder sein.
Das NotBlank-Property ist ja eigentlich der richtige Ansatz; irgendjemand hat sich ja wohl irgendetwas dabei gedacht. Nur meiner Ansicht nach ist es in dieser Form absolut sinnlos und leider nicht konsequent zuende gedacht. Man sollte wenigstens formularweit Trigger aktivieren können, die bei allen möglichen Events die Felder eines Formulars mit NotBlank-Property auf Inhalt abtestet und zumindest den User benachrichtigt. Denn manchmal kann auch einfach was vergessen werden.
In den Prozessen deines Unrternehmens weisst du doch, welche Infos du für welches Form als verpflichtend anlegen könntest und welche nicht.
Grundsätzlich grenzt ja von einer Individualsoftware ab, dass Anwender entscheiden können, ob sie eine bestimmte Funktion aktivieren möchten oder nicht.
Naja, vielleicht braucht NAV einfach noch ein wenig mehr Entwicklungszeit.
Ich arbeite schon länger mit Microsoft Produkten und bin daher etwas "verwöhnt" und deswegen ein wenig enttäuscht was den Funktionsumfang von Microsoft-Software angeht.
Und wenn Microsoft mit seiner neuen 5.1 Version NUR noch auf SQL-Server als Datenspeicher baut, wird dass seinen Grund haben. Dann müsste sich aber NAV daran adaptieren lassen, nicht umgekehrt.
Gruß
das mag alles schon sein.
Aber ist mein Denkansatz wirklich so abwägig?
Der Punkt ist der, dass wir so ein System extra einführen wollen um Klarheit zu schaffen und Datenleichen aus unserer Firma zu verbannen. Und unserer Ansicht nach macht dieses fehlende Feature dort leider wieder Tür und Tor auf. Was für dich bis heute sinnvoll und innovativ ist, empfinde ich (und wie ich in den Ein oder Anderen Foren lese noch mehr User) einfach als fehlendes Zusatzfeature.
Eine Massenmarkt-Software sollte immer die Interessen aller Nutzer abdecken. Mit Programmen der Office-Line hat Microsoft es -zugegeben in einem etwas längeren Entwicklungszeitraum als es bei Navision bislang der Fall ist- geschafft so ziemlich alle Bedürfnisse der User abzudecken. Manchmal wirken vielleicht sogar die Programme ein wenig überladen. Aber das finde ich persönlich immernoch besser als würden Funktionen fehlen.
Für mich ist ein Datensatz der bis auf ne ID nur aus NULL bestehen würde (wenn NAV dies nicht umnödeln würde) nunmal inkomplett. Wozu auch einen leeren Datensatz erstellen? Interessant wird's erst wenn die essentiellen Angaben drinstehen. Sonst brauche ich gar keinen Datensatz. Und genau diese Angaben sollen bei uns eben Pflichtfelder sein.
Das NotBlank-Property ist ja eigentlich der richtige Ansatz; irgendjemand hat sich ja wohl irgendetwas dabei gedacht. Nur meiner Ansicht nach ist es in dieser Form absolut sinnlos und leider nicht konsequent zuende gedacht. Man sollte wenigstens formularweit Trigger aktivieren können, die bei allen möglichen Events die Felder eines Formulars mit NotBlank-Property auf Inhalt abtestet und zumindest den User benachrichtigt. Denn manchmal kann auch einfach was vergessen werden.
In den Prozessen deines Unrternehmens weisst du doch, welche Infos du für welches Form als verpflichtend anlegen könntest und welche nicht.
Grundsätzlich grenzt ja von einer Individualsoftware ab, dass Anwender entscheiden können, ob sie eine bestimmte Funktion aktivieren möchten oder nicht.
Naja, vielleicht braucht NAV einfach noch ein wenig mehr Entwicklungszeit.
Ich arbeite schon länger mit Microsoft Produkten und bin daher etwas "verwöhnt" und deswegen ein wenig enttäuscht was den Funktionsumfang von Microsoft-Software angeht.
Und wenn Microsoft mit seiner neuen 5.1 Version NUR noch auf SQL-Server als Datenspeicher baut, wird dass seinen Grund haben. Dann müsste sich aber NAV daran adaptieren lassen, nicht umgekehrt.
Gruß
7. August 2007 07:31
Martin, dein Wunsch nach einem deiner Ansicht nach "sauberen" System ist verständlich. Was du dabei aber nicht ausßer Acht lassen solltest ist folgendes:
Wie du selbst für andere MS Produkte beschreibst ist es auch für NAV: Alle Leute müssel zufriedengestellt werden. Deshalb ist es nicht immer sinnvoll schon zu Anfang eine definierte Liste von Pflichtfeldern zu haben, da bestimmte Felder nur in einigen Szenarien aus Nutzersicht Pflichtfelder sind. Wenn eine Firma z.B. mit den auf der Artikelkarte befindlichen Feldern für die Beschaffung arbeitet und nicht die Tabelle "Item Vendor" benutzt, so sollten diese Pflichtfelder sein. Im anderen Fall müssten diese außer Acht gelassen werden und halt die Felder der anhängenden Tabellen geprüft werden. Das gint ebenso für das Gewicht. Und es gibt in anderen Bereichen ebensolche Konstrukte. Je nachdem wie umfangreich der Nutzer zu arbeiten gedenkt.
Wenn ich deine Ausführungen weiterspinne, so müsste dann jeweils entsprechend der speziellen Kundenanforderung das Design auf dem SQL Server angepasst werden. Und jetzt unterstelle ich einfach mal, ein Nutzer entwickelt sich weiter. Daten sollen überführt werden von der Artikelkarte in die Zusatztabellen. Das soll aber im Betrieb nach und nach passieren und nicht von jetzt auf gleich. Und dann? Welches Design soll dann benutzt werden?
Das Nutzen von NULL als Initialisierung von Feldern würde auch etwas an der Performance nagen. Beim Datenaustausch müssten alle Felder jeweils umgesetzt werden, also NULL Felder in leer oder auch gerne "(null)" oder sowas anstatt das einmal bei der Neuanlage zu machen. Das wäre sicherlich zu spüren.
Ein System zur Feldprüfung könnte für euch sehr einfach implementiert werden um eure speziellen Wünsche zu erfüllen, aber tausend Andere würden sich über den Performanceverlust aufregen. Ein System für zehntausende von Benutzern zu entwerfen und es jedem in allen Punkten Recht zu machen ist leider nicht immer möglich. Klar klingt deine Anforderung auf einer gewissen Ebene logisch, aber die Philosophie hinter NAV wäre damit unterwandert.
Die Implementierung eines solchen Prüfsystems könnte auf Applikationsbasis in viel weniger als einem Tag implementiert werden. Sicherlich nicht für alle Tabellen, aber für die wichtigsten. DAS ist der Vorteil von NAV
Wie du selbst für andere MS Produkte beschreibst ist es auch für NAV: Alle Leute müssel zufriedengestellt werden. Deshalb ist es nicht immer sinnvoll schon zu Anfang eine definierte Liste von Pflichtfeldern zu haben, da bestimmte Felder nur in einigen Szenarien aus Nutzersicht Pflichtfelder sind. Wenn eine Firma z.B. mit den auf der Artikelkarte befindlichen Feldern für die Beschaffung arbeitet und nicht die Tabelle "Item Vendor" benutzt, so sollten diese Pflichtfelder sein. Im anderen Fall müssten diese außer Acht gelassen werden und halt die Felder der anhängenden Tabellen geprüft werden. Das gint ebenso für das Gewicht. Und es gibt in anderen Bereichen ebensolche Konstrukte. Je nachdem wie umfangreich der Nutzer zu arbeiten gedenkt.
Wenn ich deine Ausführungen weiterspinne, so müsste dann jeweils entsprechend der speziellen Kundenanforderung das Design auf dem SQL Server angepasst werden. Und jetzt unterstelle ich einfach mal, ein Nutzer entwickelt sich weiter. Daten sollen überführt werden von der Artikelkarte in die Zusatztabellen. Das soll aber im Betrieb nach und nach passieren und nicht von jetzt auf gleich. Und dann? Welches Design soll dann benutzt werden?
Das Nutzen von NULL als Initialisierung von Feldern würde auch etwas an der Performance nagen. Beim Datenaustausch müssten alle Felder jeweils umgesetzt werden, also NULL Felder in leer oder auch gerne "(null)" oder sowas anstatt das einmal bei der Neuanlage zu machen. Das wäre sicherlich zu spüren.
Ein System zur Feldprüfung könnte für euch sehr einfach implementiert werden um eure speziellen Wünsche zu erfüllen, aber tausend Andere würden sich über den Performanceverlust aufregen. Ein System für zehntausende von Benutzern zu entwerfen und es jedem in allen Punkten Recht zu machen ist leider nicht immer möglich. Klar klingt deine Anforderung auf einer gewissen Ebene logisch, aber die Philosophie hinter NAV wäre damit unterwandert.
Die Implementierung eines solchen Prüfsystems könnte auf Applikationsbasis in viel weniger als einem Tag implementiert werden. Sicherlich nicht für alle Tabellen, aber für die wichtigsten. DAS ist der Vorteil von NAV
7. August 2007 09:30
finius hat geschrieben:Für mich ist ein Datensatz der bis auf ne ID nur aus NULL bestehen würde (wenn NAV dies nicht umnödeln würde) nunmal inkomplett. Wozu auch einen leeren Datensatz erstellen? Interessant wird's erst wenn die essentiellen Angaben drinstehen. Sonst brauche ich gar keinen Datensatz. Und genau diese Angaben sollen bei uns eben Pflichtfelder sein.
Also es ist ja nicht so, dass wir noch nie Pflichtfelder programmiert hätten, aber die Erfahrung zeigt eben: irgendwann fehlt einem User die Information, die er aber genau jetzt eintragen soll. Was macht er? Er trägt (Beispiel NAV) irgendeine Buchungsgruppe ein. Der nächste denkt: na super! Der Datensatz ist ja vollständig und benutzt den Artikel. Die Buchungen laufen falsch und ein Anruf beim NAV Partner ist fällig.
finius hat geschrieben:Das NotBlank-Property ist ja eigentlich der richtige Ansatz; irgendjemand hat sich ja wohl irgendetwas dabei gedacht. Nur meiner Ansicht nach ist es in dieser Form absolut sinnlos und leider nicht konsequent zuende gedacht. Man sollte wenigstens formularweit Trigger aktivieren können, die bei allen möglichen Events die Felder eines Formulars mit NotBlank-Property auf Inhalt abtestet und zumindest den User benachrichtigt. Denn manchmal kann auch einfach was vergessen werden.
In den Prozessen deines Unrternehmens weisst du doch, welche Infos du für welches Form als verpflichtend anlegen könntest und welche nicht.
Auch die Philosophie der NotBlank-Property ist eine andere. Die Property ist vor allem für Primärschlüsselfelder gedacht.
Mal ein Beispiel aus der Praxis: unser Service-Desk (also Support-System) ist vollständig in unsere NAV-DB integriert. Es gibt nicht ein Pflichtfeld auf der Support-Karte. Warum auch? Wenn der Kontakt noch nicht angelegt ist, kann ich ihn auch nicht auswählen. Also lass ich das Kontaktnr.-Feld leer und trage per Hand den Namen ins Feld ein. Ich weiß noch nicht, ob es ein Anwendungsfehler, ein Anwenderfehler oder eine Anpassung ist? Dann lasse ich das Feld eben leer und trage es ein, wenn ich es weiß. Ich habe keine E-Mail-Adresse des Anrufers? Warum nachfragen, mit dem einen Telefonat war ja alles erledigt.
Als Consulter kann ich nur immer wieder sagen: es ist sinnvoller mehr Geld in die Schulung der Mitarbeiter zu investieren, damit diese wissen, was sie ausfüllen müssen, als Geld zu investieren um Fehlermeldungen anzuzeigen mit denen der Benutzer nichts anfangen kann und/oder immer frustrierter wird.