SQLlite Datenbank mit return in einer Zelle

Startseite Foren Deutsches LiveCode-Forum SQLlite Datenbank mit return in einer Zelle

Schlagwörter: , ,

Ansicht von 11 Antwort-Themen
  • Autor
    Beiträge
    • #19605
      Jochen
      Teilnehmer

      Hallo zusammen,
      ich programmiere eine App in LC die Daten aus einer SQLlite Datenbank liest, die ich mit dem DB Browser erstellt habe. Soweit kein Problem. Jetzt gibt es aber Zellen in der Datenbank die über mehrere Zeilen gehen (mit return). Beim Einlesen der Daten aus der Datenbank in eine Variable springt natürlich alles nach einem return in die nächste Zeile und die gesamte Tabelle verliert die Struktur.

      Ich verwende zum Einlesen der Datenbank
      put revDataFromQuery(tab, return, dbid,sql) into Daten

      Ein Ansatz von mir wäre ein besonderes Zeichen (z.B. §) als „Ersatz-return“ in der Datenbank zu verwenden und dann nach dem Auslesen in einen Zeilenumbruch zu ändern.

      Weiß jemand von Euch wie ich das Problem eleganter lösen könnte?
      Im Voraus schon mal besten Dank!

    • #19607
      Klaus Major
      Verwalter

      Die Vorgehensweise hängt auch davon ab, wie Du die Daten in LC darstellen möchtest?
      Mit einem Datagrid vom Typ TABLE hättest Du hier natürlich schon arge Probleme.

      Aber zuerst vielleicht mal in LC einen Datensatztrenner angeben, der KEIN CR = RETURN ist! 😀
      Dann brauchst Du die Daten in der DB nicht anzutasten!

      ...
      ## put revDataFromQuery(tab, return, dbid,sql) into Daten
      
      ## Einen Trenner wählen, der NICHT in den Daten selber vorkommt!
      ## Vielleicht Semikolon?
      put revDataFromQuery(tab, ";", dbid,sql) into Daten
      
      ## Oder sowas:
      put revDataFromQuery(tab, numtochar(2), dbid,sql) into Daten
      ...

      Musst Du natürlich später beim „Aufdröseln“ der Daten zur Anzeige berücksichtigen.

    • #19609
      Klaus Major
      Verwalter

      Auch hier zeigt sich wieder, daß es extrem wichtig ist, nicht nur die Befehle von LC, sondern auch das Prinzip dahinter zu verstehen!

      put revDataFromQuery(tab, return, dbid,sql) into Daten
      Hier sagen wir LC, es soll uns durch den SQL Teil bestimmte Daten aus der Datenbank holen und die einzelnen FELDER eines Datensatzes mit TAB trennen, aber jeden DATENSATZ selber mit einem CR, also RETURN! Was ja hier das Problem ist. 😀

      Das sind aber nur die Defaultwerte von LC, das hier macht das selbe:
      put revDataFromQuery(,, dbid,sql) into Daten
      Also ohne Angabe der Trenner nimmt LC den TAB und CR.

      Aber wir haben die Möglichkeit diese beiden Trenner selber zu definieren, solange es sich um EINEN Buchstaben handelt! Und genau das sollten wir hier auch machen, wie ich oben gezeigt habe.

    • #19613
      Axwald
      Teilnehmer

      Hi,
      Zeilenumbrüche in Datenbankfeldern sind böse. Sie werden kommen, unausweichlich, wenn Du sie am wenigsten erwartest, um Dich in den Hintern zu beißen!

      Eine einfache & schnelle Methode, sie zu vermeiden, bieten die Funktionen „base64Encode“ und „base64Decode“ – also den Inhalt Deiner langen Textfelder „encoden“, bevor Du ihn in die Datenbank schreibst, und „decoden“, nachdem Du ihn wieder geholt hast, bevor Du ihn anzeigst.

      Nur 1 Problem: „base64Encode“ liefert Zeilen mit 72 Zeichen Länge, also wieder Zeilenumbrüche!
      Lösung: „base64Decode“ braucht die nicht, wir können sie also entfernen!

         put myTextMitCR into myVar
         get base64Encode(myVar)
         replace CR with empty in it
         --  it: "VGhlIFByb2plY3QgR3 ...", ab in die DB!
      
         put myEncodedDbFld into myVar
         get base64Decode(myVar)
         --  it: "Der Text mit den Zeilenumbrüchen ..."

      Laufzeit: ein paar wenige Millisekunden für ein Buch mit 3K Zeilen 😉

      Viel Spaß!

    • #19616
      Jochen
      Teilnehmer

      Hallo Klaus,

      danke schon mal für deine Antwort. Zum Thema das Prinzip der Befehle verstehen. Ich habe das sehr gute Buch von Hauke Fehrs durchgearbeitet, aber leider ist in der ersten Auflage noch nichts mit Datenbanken enthalten.
      Denn Rest hab ich mir halt aus dem Netz beigebracht.

      Aber zurück zum Problem.
      Ich habe jetzt in der Datenbank hinten eine neue Spalte hinzugefügt, wo in jeder Zeile ein „§“ steht und den Code beim Einlesen der Daten wie folgt geändert:
      put revDataFromQuery(tab, "§", dbid,sql) into Daten

      Im weiteren Verlauf lese ich die eingelesenen Daten aus der Variable aus um sie dann in Feldern darzustellen.

      Jetzt findet LC aber kein Zeilenende mehr und schreibt alles hintereinander.

      Schöne Grüße
      Jochen

    • #19617
      Jochen
      Teilnehmer

      Hallo Axwald,

      danke für deine Idee. Ich schreibe aber die Daten nicht mit LC in die Datenbank sondern unter Windows mit DB Browser for SQLLite. Die Datenbank möchte ich mit der App verbreiten bzw. die App könnte Sie auch vom Server laden aber nicht ändern.

      Schöne Grüße
      Jochen

    • #19618
      Klaus Major
      Verwalter

      Ich habe jetzt in der Datenbank hinten eine neue Spalte hinzugefügt, wo in jeder Zeile ein „§“ steht und den Code beim Einlesen der Daten wie folgt geändert:
      put revDataFromQuery(tab, „§“, dbid,sql) into Daten

      Eine neue Spalte?

      Im weiteren Verlauf lese ich die eingelesenen Daten aus der Variable aus um sie dann in Feldern darzustellen. Jetzt findet LC aber kein Zeilenende mehr und schreibt alles hintereinander.

      Bitte den kompletten Code posten, Gedanken lesen klappt immer noch nicht, aber wir arbeiten daran!

      Klingt so, als hättest Du meinen letzten Satz nicht so ganz beherzigt:

      Musst Du natürlich später beim „Aufdröseln“ der Daten zur Anzeige berücksichtigen.

    • #19620
      Axwald
      Teilnehmer

      Jochen,
      „revDataFromQuery(tab, „§“, dbid,sql)“ heißt, daß LC Deine Daten so ausgibt:

      11 [tab] Jochen [tab] 13 [§]
      12 [tab] Klaus   [tab] 28 [§]

      Also ein Tab zwischen den Feldern, und § zwischen den Records.
      Replace "§" with CR in myWhatEver sollte helfen 🙂

      Es geht aber auch anders. Laß SQLite Dein Feld „encoden“:
      SELECT hex(TextMitCRFeld) FROM t_demo where ...
      => 417877616C646E20483242 …

      Und das löst Du so wieder auf, in LC:
      put H2B("417877616C64")
      => Axwald

      Natürlich brauchst Du die Funktion zum Dekodieren:

      function H2B pString
         --  from libHash-Hmac V 2.3, http://marksmith.on-rev.com/revstuff/
         repeat with n = 1 to length(pString) - 1 step 2
            put numtobyte(baseconvert(byte n to n + 1 of pString, 16, 10)) after tBin
         end repeat
         return tBin
      end H2B

      Viel Spaß!

    • #19627
      Klaus Major
      Verwalter

      Um genau zu sein, und um es zu veranschaulichen:

      „revDataFromQuery(tab, „§“, dbid,sql)“ heißt, daß LC Deine Daten so ausgibt:
      11 [tab] Jochen [tab] 13 [§]12 [tab] Klaus [tab] 28 [§]13 TAB noch jemand TAB 42§14 TAB etc…

      Also in EINER Reihe, abgesehen von den CR im Text der Datenbankfelder, da die Daten NICHT durch CR sondern durch den Buchstaben ->§ getrennt sind. Es gibt also hier im Moment keine LINES in DEM Sinne.

      Um die Daten „aufzudröseln“ solltest Du:

      ...
      put revDataFromQuery(tab, "§", dbid,sql) into tData
      ## ITEMDELIMITER setzen ist klar:
      set itemdel to TAB
      
      ## Hier der notwendige Trick:
      ## Wir können und MÜSSEN den LINEDELIMITER auch setzen, 
      ## um die einzelnen Datensätze auseinanderhalten zu können
      set LINEDEL to "§"
      
      ## Nun können wir die Daten verteilen:
      repeat for each LINE tDatensatz in tData
         repeat for each ITEM tDatenbankFeld in tDatensatz
          ## Hier jetzt als Beispiel die Daten in Felder auf verschiedene Karten verteilen
          ## Oder was auch immer...
         end repeat
      end repeat
      ...
    • #19629
      Klaus Major
      Verwalter

      Also ein Tab zwischen den Feldern, und § zwischen den Records.
      Replace „§“ with CR in myWhatEver sollte helfen ?

      Au contraire, mes amis!

      Das macht alles wieder kaputt, wir machen das doch hier nur wegen eventuellen CRs in den Daten in der Datenbank!

    • #19631
      Axwald
      Teilnehmer

      Klaus,
      Ouch. Ertappt. Gleich 2 Fehler :/

      Ich wußte doch, es gab einen Grund, wieso ich ausschließlich tab/CR benutze, und die Encode/ Decode-Methode …
      Damit erschlage ich nämlich auch die Probleme mit Hochkomma, Anführungszeichen, Graves, Klammern etc. im Text.

      Viel Spaß!

    • #19633
      Jochen
      Teilnehmer

      Hallo Klaus,

      Also mit deiner Lösung hat es geklappt. Vielen Dank dafür. Auch einen herzlichen Dank an Axwald.

Ansicht von 11 Antwort-Themen
  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.