none
Textbox-Anzeige korrupt

    Frage

  • Ich habe ein unangenehmes Problem mit einer Access-Anwendung. (MS Access 2010 auf Win7 Enterprise)

    Die Access Datenbank ist das Frontend zu einer SQL Server-Datenbank. Das Problem tritt  bei Multiline-Textboxen und langen Datenfelder  (Access: Memo, SqlServer:ntext) auf.

    Wenn ein Benutzer den Text in der Textbox auf einem Endlosformular editiert, kann es vorkommen, dass die Anzeige die Änderungen nicht korrekt darstellt.

    Typischerweise wird ein <Backspace> nicht korrekt dargestellt. Ein Fragment des gelöschten Zeichen bleibt sichtbar. Auch beim Hinzufügen von Text werden teilweise Zeichfragmente dargestellt.

    Datenseitig werden die Änderungen korrekt verarbeitet, aber die Anzeige ist unbrauchbar. Es sieht so aus als würde  Access mit dem Repaint Probleme haben.

    Hat jemand dieses Problem schon mal gehabt. Was war die Lösung? Hat jemand eine Idee?

    Vielen Dank schon mal im voraus!

    Ralf

    Mittwoch, 12. Juni 2013 05:43

Alle Antworten

  • Hallo Ralf

    Ich hatte das gleiche Verhalten auch schon beobachtet. Es hing mit ungünstigen Server Datentype und einem unpassenden ODBC Treiber zusammen. Verwendest Du NTEXT auf dem Server, oder NVARCHAR(MAX) für diese Felder.

    Versuche mal mit dem SQL Server Native Client die Tabellen einzubinden. Hast Du das gleiche Verhalten dann auch noch?

    Gruss

    Henry

    Mittwoch, 12. Juni 2013 08:12
  • Hallo Henry,

    Danke für Deine schnelle Antwort. Ich benutze den NTEXT Datentyp im SQL Server Backend.

    Ich habe Deinen Vorschlag befolgt und den SQL Server native Client in der ODBC-Datenquelle eingebunden und die Tabellen relinkt (Tabellenverknüpfungsmanager). Leider nicht mit den gewünschten Erfolg.

    Schon beim Setzen des Cursors wird dieser Mitten im Zeichen gesetzt.

    Inzwischen bin ich mir ziemlich sicher, dass es das Textbox- Control ist. Was nicht heissen soll, dass das Zusammenspiel mit dem ODBC-Treiber eine Rolle spielt.

    Ich habe mal das MS RichTextBox Control anstelle der TextBox eingebunden. Da kann ich das Problem nicht beobachten. Doch leider lassen sich ActiveX Steuerelemente nicht auf Endlosformularen einsetzen.

    Pest oder Cholera.

    Gruß

    Ralf

    Mittwoch, 12. Juni 2013 08:53
  • Ich bin ziemlich sicher, es hängt damit zusammen, dass Access den Datentypen NText wie ein Memo einliest und nicht erkennt dass da vorne dran ein N ist, es also 2 Byte pro Zeichen einlesen müsste.

    Ich kann mich aber auch täuschen. Ich kann es unter Win7 und Office 2010 nicht mehr reproduzieren.

    Versuche mal einen anderen Zeichensatz für die Textbox zu verwenden.

    Falls Du die Möglichkeit hast, kannst Du auch den Typen in der Datenbank versuchshalber auf NVARCHAR(MAX) setzen, dann die Tabelle neu einlinken und nochmals versuchen. Es könnte aber sein, dass Dein ODBC Treiber auch mit NVARCHAR(MAX) noch nicht zurecht kommt. Dazu müsstest Du dann eben den Native Client des betreffenden SQL Servers benutzen.

    Ich vermute sogar Folgendes: Es passiert vor allem dann, wenn Du mehr als 255 Zeichen drin hast und es könnten sogar bei einer Änderung Zeichen ab der Position 255 abgeschnitten werden.

    Dass es mit einem AcvtiveX funktioniert heisst noch nicht viel. Das ActiveX kann die Daten durchaus korrekt einlesen, abhängig von der Programmierung dahinter, wenn es mit getChunck und appendChunk arbeitet, was bei Memo Feldern gemacht werden müsste.

    Gruss

    Henry

    Mittwoch, 12. Juni 2013 09:29
  • Ich habe die SQLServer ODBC Treiber den SQL Native Client (10.0 und 11.0) ausprobiert.Ich habe den Datentyp von nText auf nvarchar(max) auf varchar(max) geändert.

    Leider ohne Erfolg.

    Mittwoch, 12. Juni 2013 10:51
  • Hallo Ralf

    Unschön.

    Ich gehe davon aus, dass Du jeweils die Tabelle neu eingebunden hast.

    Hast Du schon versucht, eine andere Schriftart einzustellen?

    Gruss

    Henry

    Mittwoch, 12. Juni 2013 11:05
  • Henry,

    Ja, ich habe die Tabellen jeweils neu eingebunden.

    An die Schriftart habe ich auch gedacht. Ich habe eine nicht proportinale Schrift (Courier, MS Sans Serif) eingesetzt.
    Das sah erst etwas weniger chaotisch aus, aber im Resultat war es leider immer noch falsch.

    Schöne Grüße

    Ralf

    Mittwoch, 12. Juni 2013 11:22
  • Ich habe nochmals überall gesucht, wo es aufgetreten sein könnte, kann aber keinen Hinweis finden, wie ich es behoben habe.

    Hast Du evtl. Bedingte Formattierung auf dem Feld? Anzeigeformat ist auf "Plain Text"?

    Gruss

    Henry

    Mittwoch, 12. Juni 2013 11:26
  • plain-Text oder Nur-Text ;)
    Das Formatproperty ist nicht gesetzt.

    VBA-seitig bearbeite ich das Locked- und Background-Property.

    Schöne Grüße

    Ralf

    Mittwoch, 12. Juni 2013 11:35
  • Ich kann das Problem auch mit einem Memofeld in einer Access-Tabelle reproduzieren

    Hier sieht man sehr schön, dass schon der Cursor nicht richtig plaziert wird.
    Nach drücken von Backspace sieht es dann so aus

    Geisterhaft!

    Donnerstag, 13. Juni 2013 05:44
  • Ja, ich weiss, wie das damals ausgesehen hat. Finde aber wirklich nicht mehr, wie ich es behoben habe.

    Ohne es wieder reproduzieren zu können, kann ich leider nicht mehr herausfinden, woran es gelegen hat. Ich wage mich nur daran zu erinnern, dass es mit dem Datentypen einen Zusammenhang hatte.

    Gruss

    Henry

    Donnerstag, 13. Juni 2013 07:44
  • Ich bin auf meinen Untersuchungen auf einen Hinweis gestossen.

    Wenn der Text ein Tab (\t) enthält, kann ich das Verhalten reproduzieren. Auf normalen Weg kann ein solcher Whitespace in Access auch nicht reinkommen. Der Tab würde von der Form verarbeitet werden und der Focus zum nächsten Control springen.  Ich werde mir die Text jetzt mal im Hexeditor anschauen.

    Freitag, 14. Juni 2013 09:24
  • Das kann durchaus reinkommen, wenn Du z.B. Daten importierst oder dann per Copy/Paste einfügst. Habe das gerade getestet. Der Tab (vbTab) wird in einer Textbox, die an ein Memofeld gebunden ist, unterdrückt und ich kann das verhalten nicht reproduzieren.

    Aber vielleicht ist es ein anderes Sonderzeichen, wie z.B. Chr(11). Den Text im Feld in einem Hex Editor genauer anzuschauen ist sicher eine gute Idee. Evtl. reicht es bereits aus, wenn Du den Inhalt des Textfeldes in ein Word Dokument einfügst. Vielleicht siehst Du da irgendwelche Merkwürdigkeiten im Text und weisst dann, wo zu suchen.

    Gruss

    Henry

    Freitag, 14. Juni 2013 09:39
  • Das ist es !!!

    Wenn der Text im Datenfeld ein TAB enthält, lässt sich der Text nicht mehr vernüftig editieren.

    Die Daten sind bei der Übernahme vom Altsystem  in den SQL Server 1:1 übertragen worden. Da hat keine Textbox die Daten gefiltert.


    • Bearbeitet RalfE Freitag, 14. Juni 2013 10:14
    Freitag, 14. Juni 2013 09:44