Re: [de-users] Einsteigerfragen zu Base: Sonderzeichen (+ weitere Probleme - Bugs?)
Hallo, Robert! Am 26.10.2011 20:34, schrieb Robert Großkopf: Hallo Thomas, Sonderzeichen habe ich gerade getestet. Geht über Strg-Umsch-S innerhalb eines Textfeldes. Geht auch gegebenenfalls per Makro. Nur müsste dann natürlich auch irgendeine Kombination der Tasten angestrebt werden, die auf Deinen speziellen Fall zutrifft. Gruß Robert Jetzt eben habe ich versucht, Deinen Vorschlag auszuprobieren. Also: Meine Formulare, die ich gestern noch geöffnet, bearbeitet und teilweise ausgefüllt habe, enthalten zwar noch den gestrigen Text, lassen sich aber nicht mehr bearbeiten. Ich kann zwar noch den Cursor ins Feld setzen, aber Tastatureingaben werden nicht mehr angenommen. Ich bin mir sicher, dass ich keinen Schreibschutz-Status gesetzt oder sonstiges dieser Art getan habe. Ich habe auch nirgendwo eine Funktion gefunden, wo ich das ändern könnte. Vielleicht liegt es ja an irgendeiner Dusseligkeit meinerseits, aber das geht mittlerweile in all den anderen Problemen unter. Das mit den Sonderzeichen habe ich dann in der Tabellenansicht versucht (die sich, wie ich ja ausgeführt habe, aufgrund ihrer Nicht-Sortierbarkeit für mich nicht zur Dateneingabe eignet). Da funktioniert die Eingabe von Sonderzeichen per Ctrl+Umsch+S (übrigens nicht per Doppelklick auf Zeichen, sondern nur über Markieren des Zeichens und Anklicken des OK-Feldes - ist das in Ordnung so?). Prinzipiell wären, soweit ich das sehen konnte, alle diakritischen Zeichen, die bei uns benötigt werden, vorhanden. Mir hier Tastatur-Kürzel-Makros zu machen, funktionierte nicht, da die Makro-Aufzeichnungsfunktion im Menü Extras-Makros ausgegraut ist, und ich nicht in der Lage bin, mir einfach so selber Makros zu schreiben. (Anm.: die experimentellen Funktionen sind aktiviert. System (lokal): Win XP SP 3, LO 3.4.3 / OOO340m1, Build:302.) In der Diskussion auf der discuss-Liste hat sich offenbar herausgestellt, dass es bereits vom System her vordefinierte Tastaturkürzel gibt. Jedenfalls habe ich das so verstanden, wenn Thomas Hackert heute morgen um 5.10 Uhr (guten Morgen!) von den ... ... verschiedenen Tastenkombinationen, wie z.B. „AltGr“+„a“ ein „æ“ (oder noch mit Umschalttaste dazu ein „Æ“ ... ) ... schreibt. AltGr hatte ich gestern bereits ausprobiert, aber einen altenglischen Umlaut habe ich dabei nicht bekommen. Egal, jedenfalls brauchen wir sowieso unseren eigenen Satz von Sonderzeichen, den wir uns in meinem Arbeitsbereich für jede Sprache, mit der wir zu tun haben, selbst definieren müssen. Diese Lösung wäre also leider keine für uns. __ Andere Probleme: Ich habe heute morgen auch mehrfach versucht, in der Tabellenansicht meines Datenbank-Entwurfs (die, in der die Werte untereinander in einzelnen Zeilen dargestellt werden) neue Felder hinzuzufügen und alte zu löschen bzw. umzukopieren und zu bearbeiten. Beim Abspeichern nach dem Löschen eines Feldes bekam ich - gelegentlich (!) - die Fehlermeldung Fehler beim Speichern des Tabellenentwurfes - die Spalte '...' konnte nicht gelöscht werden. Beim Klick auf [Mehr] jedesmal diese drei Meldungen: SQL-Status: S1000 Die Spalte '...' konnte nicht gelöscht werden. SQL-Status: 23000 Fehler-Code: -197 Column is referenced in constraint or view: KOHD Tabellenansicht in statement [ALTER TABLE [Name meiner Tabelle] DROP [Name des Feldes]] Manchmal hat es mit demselben Feld aber auch geklappt, ich konnte nicht rausfinden, woran es lag. Die Folge war dann, dass ich die letzten Bearbeitungen nicht abspeichern konnte und die Bearbeitungsansicht der Tabelle ungespeichert und mit Datenverlust beenden musste. Und wenn ich Felder per Ausschneiden und Einfügen an das Ende der Tabelle gesetzt habe, kam es zu folgendem Problem: Das Menü-Icon sowie der Menü-Punkt Speichern sowie Ctrl+S haben sich zwar klaglos bedienen lassen, aber - und das habe ich erst nach mehreren Versuchen und dem Verlust von viel Arbeitszeit gemerkt - es ist dabei offenbar keine Aktion ausgeführt worden (= wurde nicht abgespeichert). Nach dem Klick auf das Icon wurde es nicht mehr ausgegraut, sondern behielt seine Farbe (also: Status = noch nicht abgespeichert). Und als ich die Bearbeitungsansicht dann verlassen wollte, kam die Meldung: Die Tabelle wurde geändert. Sollen die Änderungen gespeichert werden? Ein Klick auf Ja brachte mich - offenbar ohne Abspeichern - wieder zur Bearbeitungsansicht zurück, so, als hätte ich auf Abbrechen geklickt. Aussteigen konnte ich am Ende nur durch Betätigen der Schaltfläche Nein. Das geschah mehrmals = Daten- und Arbeitszeitverlust ca. zwei Stunden. __ Das alles zusammengenommen hat jetzt den kritischen Punkt erreicht, wo ich sagen muss: Umstiegsversuch gescheitert. Kann es mir auch vor meinem Arbeitgeber nicht leisten, hier noch mehr Zeit reinzustecken. Wollte nur noch eine Rückmeldung geben - wer weiß, vielleicht bringt es ja bei der weiteren Entwicklung was. Selber am Quellcode zu arbeiten, wie Du es auf der discuss-Liste an einer Stelle
Re: [de-users] Einsteigerfragen zu Base: Sonderzeichen (+ weitere Probleme - Bugs?)
Hallo Thomas, Das mit den Sonderzeichen habe ich dann in der Tabellenansicht versucht (die sich, wie ich ja ausgeführt habe, aufgrund ihrer Nicht-Sortierbarkeit für mich nicht zur Dateneingabe eignet). Da funktioniert die Eingabe von Sonderzeichen per Ctrl+Umsch+S (übrigens nicht per Doppelklick auf Zeichen, sondern nur über Markieren des Zeichens und Anklicken des OK-Feldes - ist das in Ordnung so?). Prinzipiell wären, soweit ich das sehen konnte, alle diakritischen Zeichen, die bei uns benötigt werden, vorhanden. Mir hier Tastatur-Kürzel-Makros zu machen, funktionierte nicht, da die Makro-Aufzeichnungsfunktion im Menü Extras-Makros ausgegraut ist, und ich nicht in der Lage bin, mir einfach so selber Makros zu schreiben. (Anm.: die experimentellen Funktionen sind aktiviert. System (lokal): Win XP SP 3, LO 3.4.3 / OOO340m1, Build:302.) Wenn ich etwas Lauffähiges zustande bringe (zur Zeit schaffe ich es, jedes Sonderzeichen an vorhandenen Text in einem Textfeld per Makro anzuhängen; was fehlt ist die Möglichkeit, dies an der Cursorposition zu erledigen) kann ich das gerne irgendwo auf meiner Website ablegen. Dann ginge es (im Base-Formular) je nach in den Makros eingesetzten Tastencodes zu bestimmten Sonderzeichen ... In der Diskussion auf der discuss-Liste hat sich offenbar herausgestellt, dass es bereits vom System her vordefinierte Tastaturkürzel gibt. Jedenfalls habe ich das so verstanden, wenn Thomas Hackert heute morgen um 5.10 Uhr (guten Morgen!) von den ... ... verschiedenen Tastenkombinationen, wie z.B. „AltGr“+„a“ ein „æ“ (oder noch mit Umschalttaste dazu ein „Æ“ ... ) ... schreibt. AltGr hatte ich gestern bereits ausprobiert, aber einen altenglischen Umlaut habe ich dabei nicht bekommen. Egal, jedenfalls brauchen wir sowieso unseren eigenen Satz von Sonderzeichen, den wir uns in meinem Arbeitsbereich für jede Sprache, mit der wir zu tun haben, selbst definieren müssen. Diese Lösung wäre also leider keine für uns. Ich nehme auch an, dass diese Lösung mit den Tastenkombinationen eine ist, die nur für Leute Sinn macht, die bestimmte dort vorhandene Zeichen häufiger brauchen. Die können sich dann das Zeichen (wie z.B. €) auch direkt auf die Taste zeichnen - wäre vielleicht noch eine kleine Marktlücke für Tastaturaufkleber. __ Andere Probleme: Ich habe heute morgen auch mehrfach versucht, in der Tabellenansicht meines Datenbank-Entwurfs (die, in der die Werte untereinander in einzelnen Zeilen dargestellt werden) neue Felder hinzuzufügen und alte zu löschen bzw. umzukopieren und zu bearbeiten. Beim Abspeichern nach dem Löschen eines Feldes bekam ich - gelegentlich (!) - die Fehlermeldung Fehler beim Speichern des Tabellenentwurfes - die Spalte '...' konnte nicht gelöscht werden. Beim Klick auf [Mehr] jedesmal diese drei Meldungen: SQL-Status: S1000 Die Spalte '...' konnte nicht gelöscht werden. SQL-Status: 23000 Fehler-Code: -197 Column is referenced in constraint or view: KOHD Tabellenansicht in statement [ALTER TABLE [Name meiner Tabelle] DROP [Name des Feldes]] Du hast irgendwo einen Bezug zu dem Feld hergestellt, das Du jetzt gerade löschen willst. Meinen Schülern passiert das immer, wenn Sie unter Extras-Beziehungen eine Beziehung definiert haben und anschließend versuchen, die Feldeigenschaften der betroffenen Felder zu ändern. Genauso geht es mit eventuell erstellten Ansichten. Das in Base erstellte Abfragen, die als Ansicht unter den Tabellen gespeichert sind. Angenommen Du hast eine Tabelle mit einem Feld Ort und eine Ansicht (view), die das Feld Ort ebenfalls benötigt. Jetzt ist es nicht möglich, das Feld Ort aus der Tabelle zu entfernen ohne die Ansicht zu beschädigen. Folglich widersetzt sich die Datenbank, dies zu tun. Entfernst Du Ort aus der Ansicht (lässt sich in SQL bearbeiten), so kannst Du es anschließend auch aus der Tabelle entfernen. Manchmal hat es mit demselben Feld aber auch geklappt, ich konnte nicht rausfinden, woran es lag. Die Folge war dann, dass ich die letzten Bearbeitungen nicht abspeichern konnte und die Bearbeitungsansicht der Tabelle ungespeichert und mit Datenverlust beenden musste. Und wenn ich Felder per Ausschneiden und Einfügen an das Ende der Tabelle gesetzt habe, kam es zu folgendem Problem: Du arbeitest in der grafischen Benutzeroberfläche. Die tut erst einmal so, als wäre das, was Du machen willst, möglich. Ist aber leider nicht. Wenn Du nur eine Tabelle hast, dann fertige von der Tabelle eine Abfrage an. In der kannst Du dann die Anordnung machen. Dann übernimmt nämlich die grafische Benutzeroberfläche den Vermittler. Oder Du machst anschließend eine Ansicht daraus. Dann übernimmt die interne Datenbank in der Ansicht die andere Feldanordnung. Das, woran meines Erachtens Dein geschildertes Unternehmen auf jeden Fall zur Zeit scheitert ist, dass die Eingaben in Base nicht formatierbar sind (Tabulatoren, teilweise farbig oder fett ...) Ich habe so etwas nur
