Mit der Version 5.7.04 hat die Datensatzverwaltung Einzug in den Designer von CONZEPT 16 erhalten.
In einem vorherigen Artikel haben wir die Grundfunktionen der Datensatzverwaltung bereits vorgestellt.
Die darin angekündigten Funktionen zum Exportieren, Importieren und Abfragen (Filtern) von Datensätzen möchte ich im folgenden Artikel näher erläutern.
Exportieren und Importieren
Das Ex- und Importieren dient primär der Übertragung von Datensätzen zwischen Datenbanken. Es kann aber auch verwendet werden, wenn die Struktur einer Tabelle angepasst werden soll (Felder hinzufügen, ändern oder löschen). Dies ist nämlich nur bei leeren Tabellen möglich. Dazu werden die Datensätze der Tabelle exportiert und die Tabelle geleert. Anschließend kann die Struktur angepasst und die Datensätze wieder importiert werden.
Als Transfermedium dient eine Datei, in der neben den Datensätzen auch die Feldnamen, -typen und -längen gespeichert sind.
In der Datensatzverwaltung können die Assistenten zum Ex- und Importieren über das Kontextmenü der Tabellenliste aufgerufen werden.
Beim Exportieren werden die in die Datei zu exportierenden Felder ausgewählt. Dabei können der Name und die Reihenfolge, in der die Felder gespeichert werden sollen, angepasst werden.
Feldzuordnung beim ExportierenBeim Importieren werden die aus der Datei zu importierenden Felder ausgewählt und den Feldern in der Tabelle zugeordnet. Felder mit gleichem Namen und Typ werden automatisch zugeordnet. Existiert für ein Feld in der Datei kein solches Feld in der Datenbank, wird es einem Feld des gleichen Typs zugeordnet. Die Zuordnung kann – unter Berücksichtigung der Feldtypen und -längen – geändert werden.
Feldzuordnung beim ImportierenIm nächsten Schritt kann über Optionen gesteuert werden, ob die Tabelle vor dem Importvorgang geleert und innerhalb einer Transaktion durchgeführt werden soll.
Optionen beim ImportierenAbfragen
Neben der Anzeige aller Datensätze einer Tabelle kann auch nur eine Teilmenge davon angezeigt werden, indem irrelevante Datensätze ausgefiltert werden. Dazu wird ein logischer Ausdruck – ähnliche der WHERE-Klausel in SQL – definiert, der die anzuzeigenden Datensätze beschreibt. Der Ausdruck muss nach dem folgenden Schema aufgebaut sein:
<Feldname> <Vergleichsoperator> <Wert> [[<Verknüpfungsoperator> ... ]]
Der Ausdruck und die gefilterten Datensätze werden als temporäre dynamische Selektion innerhalb der Datenbank gespeichert.
In der Datensatzverwaltung können Datensätze über die Schaltfläche „Abfragen“ des Tabellenfensters gefiltert werden.
DatensatzabfrageFeedback
Wir haben vereinzelt bereits Resonanz zur Datensatzverwalung erhalten, würden gerne aber weitere Anregungen oder Verbesserungsmöglichkeiten von Ihnen als CONZEPT 16-Entwickler erfahren. Sei es über unseren Support oder über einen Kommentar hier im Blog :).
29 Antworten
Alles gute Punkte.
Die Suche in der Tabellenliste kenne ich schon, die war in einer der letzten oder vorletzten VRA-Dateien plötzlich mit dabei. Habe ich bereits extensiv eingesetzt.
Dass man einzelne Datensätze nicht exportieren kann, hat mich nur gewundert (ich habe es vorher eben auch noch nicht probiert), weil der CSV-Export ja im Rahmen der Diskussion über die Möglichkeit Datensätze zu vergleichen hinzugekommen ist. Ich schätze mal, dass es eher nicht praktikabel ist, dass man, um zwei Datensätze via CSV-Export mit anschliessendem diff zu vergleichen, jeweils die komplette Tabelle exportieren muss.
Wir haben nicht beschlossen, dass der Export bestimmter Datensätze nicht möglich sein soll, bisher wurde das einfach noch nicht gewünscht =).
Zu den neuen Funktionen gehören neben dem CSV-Export und kleineren Verbesserungen:
– Suche in der Tabellenliste
– Feldliste (auch mit Suche) im Tabellenfenster zum schnellen Einfügen von Feldern in Abfragen
– Anzeige der Anzahl selektierter Datensätze im Tabellenfenster
– Anzeige des sperrenden Benutzers beim Bearbeiten von Datensätzen
Klingt gut, insbesondere der CSV-Export ist sicher ziemlich nützlich, vor allem solange man noch nicht alle Felder in der Datensatzverwaltung anzeigen kann.
Eine c16r-Datei mit Hilfe der Spezifikation zu lesen, werde ich bei nächster Gelegenheit auch mal probieren.
Aus welchem Grund kann man eigentlich nicht einen einzelnen Datensatz exportieren?
Welche weiteren neuen Funktionen haben Sie denn integriert?
Mit der kommenden Version wird die Datensatzverwaltung um einige Funktionen erweitert, darunter auch der Datensatzexport als CSV-Datei. Außerdem werden wir das Format der c16r-Dateien dokumentieren.
Die Idee, auch textbasierte Formate für den Export anzubieten, hatten wir auch bereits. Wir nehmen Ihre Vorschläge gerne auf und diskutieren sie.
Eine naheliegende Möglichkeit, so etwas hinzubekommen, wäre über die Exportfunktion, die ja die Datenverwaltung bereits beinhaltet.
Würde die Datensatzverwaltung z.B. CSV oder XML als Exportformate unterstützen, könnte für den Vergleich der exportierten Datensätze ein Standard-Vergleichstool verwendet werden (etwa diff oder WinMerge usw.).
Momentan unterstützt die Datensatzverwaltung aber nur ein internes Format, die exportierten Dateien enden auf "c16r".
Schaut man in diese Dateien hinein, so sieht es m. E. aber so aus, als ob der auch innerhalb von C16 zur Verfügung stehende MSX-Befehlssatz zum Einsatz kommt. Folglich könnte sich jeder Anwender ein eigenes Vergleichstool (oder was auch immer er braucht) schreiben, wenn die Spezifikation des Exportformats offen gelegt werden würde.
Und das wären demzufolge die nächsten beiden Vorschläge 🙂
1) Unterstützung von gängigen auch ausserhalb von C16 bekannten Dateiformaten (CSV, XML usw.) beim Export
2) Bekanntmachung der Spezifiikation des Formats der c16r-Dateien, damit die Daten in solch einer Datei mit dem MSX-Befehlssatz gelesen werden können.
Ein interessanter Vorschlag – ist notiert =). Ich kann Ihnen aber leider nicht versprechen ob und bis wann eine solche Funktion eingebaut wird.
Was ich schon mal brauche: Ich muss 2 Datensätze innerhalb
einer Tabelle vergleichen.
Könnte man einen Mechanismus etablieren, der die Unterschiede
markiert?
Idealerweise würden die beiden Sätze in
unterschiedlichen ca1-Dateien liegen.
Wunderbar, das ist genau das, was ich brauche. Vielen Dank!
Hallo Kilian, das ist bereits möglich: Über <Umschalt> + Doppeklick, <Umschalt> + Eingabe oder über das erweiterte Kontextmenü (<Umschalt> + Rechtsklick) und "Öffnen (neues Fenster)" können Sie ein unabhängiges Fenster für die Tabelle öffnen.
Ein weiterer Vorschlag:
Es sollte möglich sein, dieselbe Tabelle mehrmals zu öffnen, derzeit wird statt dessen beim erneuten Doppelklick auf eine bereits geöffnete Tabelle nur deren (bereits offene) Detailansicht in den Vordergrund geholt.
Ich suche manchmal mehrstufig nach bestimmten Datensätzen und die Suche würde sich erheblich vereinfachen, wenn ich mehrmals dieselbe Tabelle öffnen könnte, weil ich dann die Ergebnisse der vorherigen Suche(n) offen behalten könnte, um sie in die nächste Suche einzubinden.
Danke für die Vorschläge Kilian =)
Zwei weiterere Vorschläge:
1) Ich benutze die Datensatzverwaltung beim Arbeiten im Designer, d.h. ich möchte meistens etwas nachschauen, dann eine Änderung im Quelltext machen o.ä., dann wieder etwas nachschauen usw. Dabei erweist es sich als unpraktisch, dass die Verwaltung ein modales Fenster ist, denn man muss sie so ständig schliessen und wieder öffnen.
Sehr viel praktischer wäre es m. E., wenn man die Verwaltung als zusätzliches Werkzeug (wie Assistent usw.) neben dem Editor im Designer offen behalten könnte.
2) Bei einer grossen Anzahl von Tabellen (in einem Fall habe ich z.B. über 600) wäre es sehr praktisch in der Tabellenliste, die nach dem Start der Datensatzverwaltung angezeigt wird, eine Filtermöglichkeit nach Tabellenname zu haben.
Nachdem ich die Verwaltung nun ein wenig verwendet habe, hätte ich noch einen Vorschlag:
Es wäre unheimlich praktisch (vor allem bei grossen Tabellen mit dutzenden oder mehr Spalten), wenn man irgendwie auswählen könnte, welche Spalten man sehen möchte.
Dann wäre das aber ein Administrationsbenutzer und kein "Darf alles"-Benutzer, den der Superuser letztendlich darstellt. Der Superuser ist für CONZEPT 16 das, was für Linux der root-Benutzer ist. Der darf eben immer alles.
Die von Ihnen aufgezählten Funktionen können alle auch von Nicht-Superusern durchgeführt werden.
Ein System-Administrator oder ein Support-Mitarbeiter muß als
Superuser gewisse Dinge machen können (Diagnose, Prozeduren einspielen, ausführen, …), programmieren kann er aber deswegen noch lange nicht.
Vielleicht könnte man den Menupunkt durch ein Passwort a la Dienstprogramme schützen, das dann eben nur die Entwicklung kennt.
@tsauter: Meinen Sie, dass es etwas bringt, den Menüpunkt auszublenden? Ihr Kunde mit Superuserrechten könnte ihn doch einfach wieder einblenden, oder?
M. E. ist es ok, wenn die Datenverwaltung im Designer über das Menü leicht erreichbar ist, sie ist eben Bestandteil der Entwicklungsumgebung und die sollte möglichst praktisch für uns Entwickler sein und nicht durch Nebenüberlegungen verkompliziert werden.
@Florian: Nunja, was aussagekräftig ist und was nicht, das wird von der jeweiligen Situation bestimmt.
Natürlich wäre es manchmal optimal, wenn man eine bestimmte Änderung komplett nachvollziehen könnte. MSSQL z.B. besitzt neuerdings ein Feature namens "Change Tracking", das in verschiedenen Varianten z.B. den vollständigen inhallichen Nachvollzug einer Datenmanipulation oder aber auch nur den Nachweis, dass eine (und auch die wievielte) Manipulation an einer bestimmten Stelle geschehen ist, ermöglicht.
Aber soweit muss man vielleicht nicht immer und vor allem nicht sofort gehen.
Was ich aber in jedem Fall gerne im Log sehen würde, wäre, welcher Benutzer, die Datenverwaltung wann verwendet hat, interessant wäre wohl auch, was er ungefähr in Bezug auf welche Objekte gemacht hat (z.B. Benutzer Willi hat 1231241 Datensätze der Tabelle Auftragspositionen gelöscht).
Natürlich wäre es gelegentlich auch praktisch, wenn ich wüsste, dass ein bestimmter Benutzer einen ganz bestimmten Datensatz verändert hat, aber wenn diese Informationen das Log zu überschwemmen drohen, dann muss man sich hier vielleicht eine Alternative überlegen, z.B. eine eigene (System-)Tabelle in der Datenbank, in der diese Informationen abgelegt werden, oder ein eigenes Logfile nur für die Datenverwaltung, das mit Hilfe automatisierter Tasks regelmässig gesichert und geleert werden kann, oder etwas anderes.
@Florian: Natürlich, wenn jemand mehre Hundert Sätze löscht, sollte dies auch protokolliert werden. Wir praktizieren dies übrigens schon seit langem in unserer Applikation. Die Identifizierung geschieht sehr einfach über einen String, der aus dem Primärschlüssel gebildet wird. Das hat uns schon einige Male "das Leben gerettet". Solange keine Möglichkeit besteht den Menüpunkt auszublenden, werden wir diese Version nicht einsetzen …
Wie stellen Sie sich die Aufzeichnung im Datenbanklog denn konkret vor? Angenommen ein Benutzer ändert oder löscht mehrere hundert Datensätze auf einmal. Wird jede einzelne Datensatzänderung protokolliert? Wie werden die gelöschten Datensätze im Protokoll identifiziert? Um das Protokoll aussagekräftig machen zu können, müsste es schon sehr ausführlich sein.
Ich glaube die Anforderungen an eine solche Protokollierung sind zu variabel, als das man dafür eine allgemeine und einfache Lösung finden könnte.
@tsauter: Da haben Sie sicher recht, je nachdem, wie verantwortungsvoll oder -los jemand mit den Daten umgeht, kann es sicher zu Inkonsistenzen und staistischen Abweichungen kommen.
Da Florian angemerkt hat, dass eine von uns gewünschte Trigger-Funktionalität aufwändig zu realisieren ist – ich denke man darf zwischen den Zeilen lesen: und daher in absehbarer Zeit auch nicht realisiert werden wird 🙂 – wäre es sicher zu begrüssen, wenn die Datenstrukturaktivität im Datanbanklog vermerkt wird, damit man hier ggf. nachschauen kann, wer eine bestimmte Manipulation der Daten zu verantworten hat.
@Kilian: Natürlich gehören die Daten dem Kunden. Solange er
uns nicht für die Konsistenz und Richtigkeit aller Daten (Bestände,
Statistiken, usw…) verantwortlich macht, kann er auch ändern und
löschen. Die Praxis sieht aber wohl anders aus…
Natürlich wird es immer Mittel und Wege geben das auch zu tun
(ODBC, Prozeduren, Datenstruktureditor …). Doch ganz so einfach
sollte das nicht möglich sein.
Die Funktionalität an sich haben wir übrigens schon mit eigenen
Routinen gelöst. Ist aber immer schön, wenn es direkt von VS gepflegt wird …
Die Datensatzverwaltung berücksichtigt die Rechte, die auf Tabellen vergeben werden können. Wir haben aber auch zuätzliche Rechte für den Zugriff auf die Entwicklungswerkzeuge geplant.
Der Superuser hat generell alle Rechte, die auch nicht eingeschränkt werden können. Dem Kunden sollte ein Benutzer mit eingeschränkten Rechten zur Verfügung gestellt werden, für den dann z. B. auch die Datensatzverwaltung deaktiviert werden kann.
Die Datensatzverarbeitung per Trigger (Ereignis od. Callback-Funktion) überwachen und steuern zu können, ist zwar eine wünschenswerte, aber aufwendig zu realisierende Funktionalität.
@tsauter: Die Daten gehören ja auch Ihren Kunden, oder nicht? In gewisser Weise sollten sie also damit machen können, was sie wollen.
Aber Sie haben natürlich recht mit der Forderung, die Zugriffsstufe auf die Datensatzverwaltung (Lesen, Schreiben usw.) sollte über die Benutzerrechte regelbar sein.
Allerdings sollte der Superuser diese Rechte auf jeden Fall besitzen bzw. das Recht, diese Rechte zu verwalten, so dass dies in der beschriebenen Situation auch nichts nützen würde, da die betreffenden Kunden sich ja als Superuser anmelden können.
Auch die angesprochene Idee der Call-Back-Funktionen möchte ich unterstützen. Ich würde den Wunsch allerdings so auslegen, dass ganz generell die Events der Datensatzverwaltung bei Bedarf in selbstgeschriebenen Prozeduren abgefangen werden können sollten. Dies wiederum müsste aber irgendwo einstellbar sein, so dass der Superuser diese Einstellung wieder ausser Kraft setzen könnte. Demnach wäre dies ebenfalls keine Lösung für das angesprochene Problem.
Insgesamt finde ich dieses neue Feature grossartig, auch wenn ich es noch nicht ausgiebig testen konnte. Endlich gibt es die Möglichkeit, Daten roh zu betrachten und zu ändern usw. Diese neue Datensatzverwaltung vergleichbar mit einem Abfragetool in der SQL-Welt. Auch dort kann der Benutzer, wenn er über einen entsprechenden Zugang zu Datenbank verfügt, mit Hilfe eines solchen Programms beliebige Informationen über die Daten in Erfahrung bringen und die Daten auch ändern, ohne dass dies vom Programmierer einer evtl. dazugegörigen Anwendung verhindert werden könnte.
Ich habe jedenfalls die Funktionalität, die die Datensatzverwaltung jetzt bietet schon immer vermisst und freue mich, dass es sie jetzt gibt.
Die Funktionen sind grundsätzlich zu begrüßen.
Sehr bedenklich finde ich die fehlenden sicherheitsrelevanten Aspekte. Gibt es ein Benutzerrecht für die Datensatzverwaltung?
Einige unserer Kunden haben das SU-Kennwort. Damit können
sie nun sowohl Daten verändern, als auch löschen. Im Extrem-
fall sogar ganze Tabellen leeren, ohne daß wir das kontrollieren
können. Ideal wären Callback-Funktionen (Events) vor und nach
jeder Aktion, die man selbst gestalten kann und mit denen man
ggf. die Aktion abbrechen, bzw. protokollieren kann.
Danke für die schnellen Rückmeldungen, weiter so ;).
@ J. Schmiedel: Die vorgestellten Funktionen sind in der aktuellen Version (5.7.04) bereits vorhanden. Verknüpfte Datensätze kann man ebenfalls über Abfragen einschränken.
@ Th.Eichele: Die maximale Dateigröße beträgt theoretisch 8 Exabyte (2 hoch 63 Byte), wird also wohl eher durch das verwendete Dateisystem (bei NTFS ca. 16 Terabyte) beschränkt. Den Export in mehrere Dateien aufzuteilen ist eine gute Idee.
Vielen Dank für das Feature. Mir gefällt das Design!
gibt es Grenzen bzgl. der Dateigrößen (wie beim "Transfer") ?
Schön wäre es auch, wenn man den Export automatisch in mehrere Dateien splitten und den Import prozedural beauftragen könnte (für Massen-Export/Import bei Prímewert-Überlauf)
Finde ich sehr gut, dass das Abfrageprogramm integriert wird.
So kann man seine selbst erstellten Selektionen gegenprüfen.
Werden denn auch Selektionen mit Verknüpfung möglich sein?