Entitäten nach Wizard Fehler nicht mehr nutzbar!

[Markus Glitzner]

Hallo!

Der Entitäten Wizard ist zwar recht nett, aber leider extrem Fehlernfällig sodass manche Entitäten danach nicht mehr nutzbar sind. Die Probleme treten vor allem dann auf, wenn Änderungen an einer Entität gemacht werden oder bei fehlerhafte Eingaben.

1. Problem:
Es ist nie ganz klar, was der Wizard macht, wenn man den Zurück Button betätig. Mal bleiben die Werte enthalten, mal nicht was wiederum zu einem Folgefehler führen kann. Kann jetzt kein konkretes Beispiel nennen, fällt mir aber in den Zusammenhang immer wieder auf.

2. Problem:
Wird der Tabellenspaltennamen geändert, wird die komplette Spalte gelöscht und neu erstellt. Ich weis zwar mittlerweile dass das historisch bedingt ist, doch wäre zumindest ein Hinweis hilfreich um nicht gleich alle Daten zu verlieren, so wie es mir passiert ist.

3.Problem:
Als Standartwert kann alles drinnen stehen, was aber z.B. bei Datumsfelder später zum Problem wird. Ok, muss man halt wissen, trotzdem blöd.

4.Problem:
Wird ein Attribut nachträglich als Pflichtfeld gesetzt, muss ein Standardwert eingetragen werden. Mir war bis jetzt nicht klar, dass dieser Wert bei allen leeren Feldern eingetragen wird, was im Zusammenhang mit dem vorigen Problem wiederum die ganze Entität zerstören kann. (Grund folgt beim Problem 6)

5.Problem:
Werden Attribute gelöscht, hinzugefügt, deren Anzeigenamen oder der Datenbankfeldname geändert, ist die Gefahr groß dass dies zu einem Fehler führt und somit der Zugriff auf die gesamte Entität nicht mehr möglich ist und zwar aus folgendem Grund …

6.Problem:
Kommt es beim Fertigstellen des Wizards zu einem Fehler, werden zwar einige Teile erledigt, aber nicht alle. So wird zuerst immer die View gelöscht und danach erst die Kritischen Änderungen ausgeführt was letztens zu einer Inkonsistent der Datenbank führt und die Entitäten somit nicht mehr nutzbar sind. Um das Problem zu beheben, muss erst die View manuell in der Datenbank erstellt werden, danach muss die Entity_Field Tabelle bereinigt werden und noch der Tomcat Server neu gestartet werden. Wenn man Glück hat, kann man danach wieder auf die Entität zugreifen, denn ohne View kein Zugriff auf die Entität! Es kann aber sein dass das Probem viel weitreichender ist und erst später beim Bearbeiten von anderen Entitäten auffällt z.B: in Verbindung mit Beziehungen, Indexes oder bei Statusmodellen oder Referenzfelder, usw.

Das alles wäre nicht weiter tragisch, wenn sämtliche SQL Beehle in einer Transaktion ausgeführt werden. Somit könnte in einen Fehlerfall ein Rollback ausgelöst werden. Sicher ist es dann ärgerlich, wenn man gerade 30 Attribute mühselig definiert hat und dann wieder alles weg ist (ist mir passiert), aber besser so als es geht danach gar nichts mehr.

Hoffe dass es diesmal eine Antwort darauf gibt!

Schöne Grüße

[Markus Glitzner]

7. Problem:
Wenn bei einem Referenzfeld als Suchfeld ein Attribut mit einer Berechnungsvorschrift angegeben wird, schlägt die Erzeugung der View fehl, weil auf das Feld zugegriffen wird, als wenn es ein echtes Attribut der Entität wäre.

Ih löse dieses Problem jetzt mit einem Trigger, ist zwar kein TEil mehr von nuclos, aber es funktioniert.

[Markus Glitzner]

8. Problem:
Wenn ein Datumsfeld nachträglich als Pflichtfeld deklariert wird, führt dies am SQL Sever zu einem Konvertierungsfehler, auch wenn der Standardwert für das Pflichtfeld über den Datechooser ausgewählt wurde.

SQL Statement:
UPDATE nuclos.T_EO_TERMINE SET DATUMBIS = ‚2011.04.27‘ WHERE DATUMBIS is null

Fehlermeldung am SQL Server:
Bei der Konvertierung eines char-Datentyps in einen datetime-Datentyp liegt der datetime-Wert außerhalb des gültigen Bereichs.

Im Gegensatz dazu liefert HEUTE bzw. TODAY als Standardwert das richtige Ergebnis und führt bei einem neuen Datensatz zu keinen Fehler.

[Ramin Goettlich]

Hallo hugo,

vielen Dank für die Meldung auftretender Fehler. Einige der aufgeführten Punkte sind bereits behoben und stehen mit nächstem Update zur Verfügung.

Erlauben Sie mir den Hinweis, dass uns grundsätzlich sehr geholfen wäre, wenn auftretende Fehler direkt in unserem Bugtrackingsystem (http://support.novabit.de) erfasst werden. Nur dort ist uns eine strukturierte Herangehensweise an die Fehlerbehebung (Priorisierung von Bugs, Zuweisung zu Bearbeitern, Abwicklung von Rückfragen, Statusmeldungen, Austausch von Zusatzinformationen wie Screenshots, etc.) sinnvoll möglich. Mit Abschluss der Subscription sollte Ihnen eigentlich ein Zugangspassword zum Bugtrackingsystem zugegangen sein, falls dies nicht der Fall ist, geben Sie uns bitte kurz Bescheid.

Allgemeine Anmerkung zum in Ihrer Auflistung wohl entscheidenen Punkt 6: Welches DB-System nutzen Sie? Wir haben leider mit dem prinzipiellen Problem zu kämpfen, dass einige der von Nuclos unterstützen DBs (z.B. Oracle) kein Rollback von SQL-DDL-Statements (ALTER TABLE, DROP COLUMN, etc.) unterstützen (kaum zu glauben, aber wahr) und sich SQL-DDL-Statements auf diesen DBs daher nicht in Transaktionen kapseln kassen. Sobald man in einer laufenden Transaktion, in der vielleicht bereits auch einige SQL-DML-Statements (INSERT, DELETE, UPDATE, etc.) ausgeführt wurden, ein SQL-DDL-Statement absetzt, wird die gesamte Transaktion(!) implizit committed und man kann das nicht unterbinden.

Das ist fatal und disqualifizert solche DBs (z.B. Oracle…) in unseren Augen eigentlich. Die einzige Chance, die wir haben, sinnvoll damit umzugehen, ist die, zu versuchen, nach Möglichkeit vorher zu erkennen, ob gewisse Eingaben zu einem Fehler führen würden und entsprechende Validierungen bereits im Client durchzuführen. Das ist natürlich beliebig komplex. Die Alternative wäre, auf Mechanismen wie den Entitätenwizard gänzlich zu verzichten, aber das ist natürlich keine Alternative. Um ganz sicher zu gehen, bleibt uns eigentlich in letzter Konsequenz nur die Möglichkeit, die Unterstützung von DBs auf unseren Ansprüchen genügende DBs zu beschränken. Dann wiederum rebellieren verständlicherweise Unternehmen, die aus bestimmten Gründen politisch / strategisch / warumauchimmer bereits auf ein bestimmtes DB-System eingeschossen sind und auf einer entsprechenden Unterstützung bestehen. Ein Dilemma.

Übrigens hilft in konkreten Fällen der Inhalt des Verzeichnisses /logs/database-structure-changes, in dem alle SQL-DDL-Statements mit Rückmeldung der DB protokolliert werden. Wenn Sie uns den Inhalt dieses Verzeichisses zur Verfügung stellen, können wir konkret analyisieren, welche Statements in Ihren Fall fehlschlugen und daraus die Implementierung ggf. noch fehlender Validierungsprüfungen ableiten.

Anmerkungen zu übrigen Punkten:

Punkt 1: Da haben wir einiges verbessert, ob Ihr Fall damit erschlagen ist, können wir erst beurteilen, wenn wir Ihren Fall reproduzieren können.

Punkt 2: offen, wird noch durch ein Umbenennen der Spalte auch in der DB ersetzt.

Punkt 3: Behoben

Punkt 4: Ein im Entitätenwizard definiertes Pflichtfeld wird auch in der DB als „NOT NULLABLE“ definiert, legt man ein existierendes Feld also nachträglich als Pflichtfeld fest, ist die Eingabe eines Standardwertes, der in Datensätzen, in denen das betroffene Feld leer ist, gesetzt wird, unumgänglich. Fehlerhaft war hier bisher, dass ein Standardwert auch dann gefordert wird, wenn das Pflichtfeld schon immer ein Pflichtfeld war.

Punkt 5,6: s.o. Für die Ermittlung der genauen Ursache benötigen wir die Logs.

Punkt 7: Bisher unbekannter Fehler, wird behoben

Punkt 8: Behoben

Grüsse,
nuclosian

[Ramin Goettlich]

> Hoffe dass es diesmal eine Antwort darauf gibt!

Gibt es eines Forumsbeitrag, zu dem Sie eine Antwort vermissen? Bitte einen kurzen Hinweis und wir schaffen diesen bedauerlichen Umstand aus der Welt 😉

[Markus Glitzner]

Hallo nuclosian!

Danke für die ausführliche Antwort.

Es müsste noch zwei unbeantwortete Einträge geben, allerdings hat sich das meiste mittlerweile geklärt.

Dass Oracle hier so eigen mit den Transaktions ist, war mir nicht bekannt. Für nuclos 3.0.3 verwende ich aktuelle den SQL Server 2005.

Habe mir die Logs durchgesehen, Fehler stehen ale drinnen. Dabei ist mir noch ein Fehler aufgefallen, der zum Verlust der View einer Entität geführt hat. Ich wollt ein berchenendes Attribut für das Alter einer Person eingeben und habe den Spaltennamen auch Alter genannt, war aber ein Keyword und hat somit zum Fehler führt. Am SQL Server könnte man solche Spaltennamen in eckige Klammer setzen, dass würde wieder eine Fehlerquelle ausschließen. Ich weis, standardmäßig wird ein Präfix gesetzt, nur nervt mich das total, weil die Datenbank unlesbar wird.

Ich werde künftig das Backtrackingsytem nutzen.

Wann wird vorraussichtlich die nächste Beta bzw. Release Version veröffentlicht?

[file name=database_structure_changes.zip size=7794]https://www.nuclos.de/media/kunena/attachments/legacy/files/database_structure_changes.zip[/file]

Attachments:

• database_structure_changes.zip

[Autor]

Beiträge