Umlaute // Lazarus 1.4.2 mit Datenbank

[manfred_h]

Hallo zusammen

Ich habe ein Problem mit einer Datenbankanwendung.
Alle Umlaute und div. Sonderzeichen éàè werden mit Fragezeichen oder falschen Symbolen dargestellt.
Auf die Datenbank wird schon mittels einer Delphi-Anwendung erfolgreich zugegriffen.
In Delphi werden mit der gleichen Komponente die Umlaute korrekt dargestellt.

Ich verwende die DataAbstract komponenten für den Zugriff auf eine MySQL Datenbank.
http://www.dataabstract.com/da/default.aspx

Ich habe schon sehr viel darüber gelesen:
http://www.delphipraxis.net/157654-t...-inhalt-2.html
http://wiki.freepascal.org/LCL_Unicode_Support/de

Allerdings wird immer wieder geschrieben das ich z.B. dies machen kann:

Delphi-Quellcode:

var
  MyString: string; // ansi encoded
begin
  MyString := SomeRTLRoutine;
  MyTEdit.Text := AnsiToUTF8(MyString);
end;

Bei meiner Datenbank Anwendung setzt ich DBEdit Felder ein die in sehr grosser Zahl vorhanden sind ein... Wie könnte ich das Zentral lösen.

[p80286]

Zitat:

Zitat von manfred_h (Beitrag 1315947)

Alle Umlaute und div. Sonderzeichen éàè werden mit Fragezeichen oder falschen Symbolen dargestellt.
Auf die Datenbank wird schon mittels einer Delphi-Anwendung erfolgreich zugegriffen.
In Delphi werden mit der gleichen Komponente die Umlaute korrekt dargestellt.

Wahrscheinlich bin ich zu wenig flexibel, Darum was denn nun? Geht's oder Geht's nicht?

Erste Frage: Welche Zeichenkodierung wird genutzt?
Zweite Frage: Welcher Font wird genutzt?

Gruß
K-H

[TraumTaenzerDieter]

Dritte Frage: welche Zugriffs-Komponenten?
Vierte Frage: welche MySql-Version?

[manfred_h]

>> K-H

Zitat:

Geht's oder Geht's nicht?

Es geht in Lazarus nicht. :wink: Die Erklärung mit Delphi machte ich um aufzuzeigen das die Verbindung Serverseitig ok ist.

Zitat:

Erste Frage: Welche Zeichenkodierung wird genutzt?

DEFAULT_CHARSET

Zitat:

Zweite Frage: Welcher Font wird genutzt?

default ( muss noch nachschauen was default ist... Sorry )


>> TraumTaenzerDieter

Zitat:

Dritte Frage: welche Zugriffs-Komponenten?

Steht doch oben... :wink: DataAbstract

Zitat:

Vierte Frage: welche MySql-Version?

Database server version 5.5.44

[p80286]

Zitat:

Zitat von manfred_h (Beitrag 1315968)

default ( muss noch nachschauen was default ist... Sorry )

:thumb: Gute Idee.
Es gibt einige Fonts, die sind Über die US-ASCII-Zeichen nie hinaus gekommen.

Ebenfalls ein guter Ansatz, welche (Byte)Werte sollen angezeigt werden? Wenn die in Ordnung sind, kann man sich Frage 3 und 4 und die nach dem DB Zeichensatz sparen.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1315981)

Zitat:

Zitat von manfred_h (Beitrag 1315968)

default ( muss noch nachschauen was default ist... Sorry )

:thumb: Gute Idee.
Es gibt einige Fonts, die sind Über die US-ASCII-Zeichen nie hinaus gekommen.

Wenn der Font nicht passt wird oft ein leeres Rechteck angezeigt.
Fragezeichen und falsche Symbole deuten darauf hin das in der gewählten Kombination noch ein UTF8-Wandlungsproblem (Zu Viel/Zu wenig/Falscher Stringtyp) vorliegt.
MySQL hat AFAIK ab V4 keine Probleme mehr mit Unicode.

[manfred_h]

[QUOTE=p80286;1315981]

Zitat:

Zitat von manfred_h (Beitrag 1315968)

Es gibt einige Fonts, die sind Über die US-ASCII-Zeichen nie hinaus gekommen.

Ebenfalls ein guter Ansatz, welche (Byte)Werte sollen angezeigt werden? Wenn die in Ordnung sind, kann man sich Frage 3 und 4 und die nach dem DB Zeichensatz sparen.

Der Default Font ( hiermit ermittelt: Form1.Caption:=GetFontData(Form1.Font.Handle).Name ; )
Segoe UI
Ist mir nicht klar wo dieser angepasst werden könnte...

Zitat:

Ebenfalls ein guter Ansatz, welche (Byte)Werte sollen angezeigt werden?

Sorry, Diese Frage verstehe ich nicht ganz.
Also dargestellt werden könne sollte eingentlich Europäische Zeichen:
Alle Umlaute und div. Sonderzeichen éàèçöäü

[manfred_h]

Habe eben noch einen Test gemacht.

Wenn ich folgende Werte in Der Lazarus Anwendung eingebe:
Test öäü éàèç
Werden diese in MySQL wie folgt gespeichert:
Test öäü éÃ*èç

In Der Lazarus-Anwendung erscheinen sie aber korrekt als Test öäü éàèç.

Edit: Mit einem Online UTF8 decoder erhalte ich wieder die richtigen Zeichen...
Wo könnte dies generell umgestellt werden..

[p80286]

Zitat:

Zitat von manfred_h (Beitrag 1315991)

Zitat:

Ebenfalls ein guter Ansatz, welche (Byte)Werte sollen angezeigt werden?

Sorry, Diese Frage verstehe ich nicht ganz.
Also dargestellt werden könne sollte eingentlich Europäische Zeichen:
Alle Umlaute und div. Sonderzeichen éàèçöäü

Es werden keine Zeichen gespeichert sondern ihre Kodierung z.B. x20 für das Leerzeichen. Je nach verwendetem Zeichensatz kann der gleiche Wert unterschiedlich dargestellt werden, wenn Du Dich bzw. Dein Programm sich auf 8Bit-Codierung beschränkt. UTF8 ist eine Erweiterung der 8Bit-Kodierung. Hier entsprechen die Werte von 0-127 der ANSI-Kodierung. Höhere Werte leiten meist eine Wertesequenz ein, bei der zwei oder mehr Werte ein Zeichen darstellen.
hier findest Du mehr dazu.
Der nächste Schritt ist dann UTF16 bei dem jedes Zeichen durch zwei Byte bzw. ein Word (oder ein mehrfaches falls nötig)repräsentiert wird.

Zeichen (dargestellt oder nicht) sind nur die Interpretation von Werten. Im Zweifel kommst Du an einem Hex-Editor nicht vorbei.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von manfred_h (Beitrag 1315996)

Habe eben noch einen Test gemacht.

Wenn ich folgende Werte in Der Lazarus Anwendung eingebe:
Test öäü éàèç
Werden diese in MySQL wie folgt gespeichert:
Test öäü éÃ*èç

In Der Lazarus-Anwendung erscheinen sie aber korrekt als Test öäü éàèç.

Edit: Mit einem Online UTF8 decoder erhalte ich wieder die richtigen Zeichen...
Wo könnte dies generell umgestellt werden..

Schaut danach aus als würde deine Kombination Lazarus + DB-Treiber einmal zu viel UTF8-Wandeln.

[manfred_h]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1316103)

Schaut danach aus als würde deine Kombination Lazarus + DB-Treiber einmal zu viel UTF8-Wandeln.

Danke für Deine Antwort.
Habe das ganze auch schon mal mit dem Dev. Team vom RemObjects angeschaut. Sie meinten es wäre ein Problem in Lazarus selber...
http://talk.remobjects.com/t/german-...lazarus/6041/6

Hoffe wirklich das ich das irgendwie zum laufen kriege...
Bin zu Lazarus "gezogen" da mir Delphi für meine zwecke ein wenig teuer wurde....Nicht kommerzieller Einsatz
( Was nicht heisst das es das nicht wert ist... Möchte keine Diskussion vom Zaun brechen :pale:)

[IBExpert]

lazarus selbst hat ganz sicher kein Problem mit UTF8, das kann ich sehr sicher sagen und im Zusammenspiel mit Firebird und Anbindung über die serienmäßigen SQLDB Komponenten gilt das auch für diese Kombination. Auch Tests mit sehr exotischen Inhalten sind da sowohl in Blob und varchar Felder korrekt gespeichert und im TEdit oder TMemo auch 100% sauber dargestellt.

Ich hatte aber mal Versuche mit den devart Komponenten für lazarus gemacht, und auch da gab es seltsame Doppelcodierungen bei Blobs, d.h. ein Euro Zeichen zum Beispiel wurde beim speichern erst mal in den 3 Byte langen code übersetzt und die daraus resultierenden Zeichen wurden vor dem Eintrag in die DB noch mal codiert, so das am Ende 9 Byte in der DB standen. Beim Auslesen hat die devart Komponente immerhin den gleichen Mist wieder umgekehrt doppelt dekodiert udn das richtige angezeigt. In allen anderen Programmen wie zum Beispiel IBExpert stand in der DB dann aber nur Müll.

Ich bin dann schnell wieder zurück zu SQL DB und hab seitdem auch nie wieder andere Komponenten gebraucht, was auch deshalb praktisch ist, weil die SQLDB in jeder Lazarus Version auf jeder Plattform enthalten ist.

Ich würde also bei deiner Kombination auch mal die benutzte DB Komponente hinterfragen

[manfred_h]

Danke für Deine wirklich sehr ausführliche und sicher kompetente Antwort. Die RemObjects Komponenten sind einfach sehr praktisch....
Werde beim Support nochmals nachfragen. Ich habe da halt ein wenig Ein Problem wenn der Support mir mitteilt das dies an Lazarus liegt und sie da nichts machen können.. (siehe link im letzten Post)
Shalom Manfred

[IBExpert]

Dem würde ich einfach mal in einem Beispiel auf Basis der SQLDB Komponenten widersprechen, in dem du deine MySQL Datenbank mit UTF8 Daten ansteuerst, was sicherlich auch fehlerfrei sein wird. Die Aussage, daß das an Lazarus liegen würde, wäre damit widerlegt. Es liegt ziemlich sicher an den benutzten Komponenten oder an dem Unverständnis des Architekten dahinter für die Lazarus Architektur.

[manfred_h]

Zitat:

Zitat von IBExpert (Beitrag 1316146)

Dem würde ich einfach mal in einem Beispiel auf Basis der SQLDB Komponenten widersprechen, in dem du deine MySQL Datenbank mit UTF8 Daten ansteuerst, was sicherlich auch fehlerfrei sein wird.

Danke für Deinen Tipp, habe dies gemacht und dem Support gemeldet.

Shalom
Manfred

[manfred_h]

Kleines Feedback.
Der Support ist nun das ganze am überprüfen.
http://talk.remobjects.com/t/german-...azarus/6041/25

Das Problem ist momentan das die Komponente unter Lazarus eine andere Ausgabe ergibt als unter Delphi.

[ThomasBab]

Hallo!

Versuch doch mal in der dpr-Datei (Lazarus-Projektdatei) direkt nach dem "Threat-Gedöns" folgendes einzugeben: {$IFDEF UNIX}cwstring,{$ENDIF}

(Habe ich aus dem Lazarus-Forum, bei dem es darum ging, dass Umlaute unter Windows/Linux Probleme gemacht haben.

[manfred_h]

Halo Thomas

Habe die .lpr Projektdatei wie folgt angepasst:
vorher:

Delphi-Quellcode:

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}

neu:

Delphi-Quellcode:

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,cwstring,
  {$ENDIF}{$ENDIF}

Leider ohne Erfolg

[ThomasBab]

Versuch es mal so:

Delphi-Quellcode:

{$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
{$IFDEF UNIX}cwstring,
  {$ENDIF}

[manfred_h]

Leider auch kein Erfolg..

[manfred_h]

Hallo zusammen

Wollte Euch nur ein kleines Update über den Stand der Dinge geben:
Leider bis jetzt noch keinen Erfolg. Der Support hat aber ein Problem im FPC gefunden:

Zitat:

As I said earlier, there is a problem in FPC itself.

Delphi-Quellcode:

procedure TDataSet.DataConvert(aField: TField; aSource, aDest: Pointer;
  aToNative: Boolean);

 // There seems to be no WStrCopy defined, this is a copy of
 // the generic StrCopy function, adapted for WideChar.
 Function WStrCopy(Dest, Source:PWideChar): PWideChar;
 var
   counter : SizeInt;
 Begin
   counter := 0;
   while Source[counter] <> #0 do
   begin
     [B]Dest[counter] := char(Source[counter]); //<<< here should be WideChar instead of char , so it loses all unicode chars[/B]
     Inc(counter);
   end;
   { terminate the string }
   Dest[counter] := #0;
   WStrCopy := Dest;
 end;

Hier gehts im Support Forum weiter:
http://talk.remobjects.com/t/german-...azarus/6041/29

Shalom
Manfred

[IBExpert]

Es wird aber auch durch mehrfache Wiederholung von denen nicht richtiger, das die denken, das da Fehler in Lazarus sind. Wahrscheinlich ist da ein Fehler in der zusammenarbeit zwischen deren Komponenten und der Lazarus Funktionsweise, aber das ist dann ganz wo anders zu beheben als irgendwo an den fpc sourcen was zu patchen. Wäre jedenfalls meine Sicht der Dinge.

Siehe Anhang: ist enfach mal UTF8 Inhalt von http://www.columbia.edu/~kermit/utf8.html
in unser ERP System eingefügt und das wird sowohl in BRP (geschrieben mit Lazarus) als auch in IBExpert (geschrieben mit Delphi) korrekt dargestellt.

[manfred_h]

Hier das neueste Update:

Sieht im Moment nicht so gut aus...:pale:

Zitat:

the main difference between Delphi and Lazarus: Delphi uses UTF16 for unicode support in comparing Lazarus that uses UFT8 ...
RO/DA use UTF16 for unicode support because it other our platforms (.NET/Cocoa/etc) also use UTF16.

as a workaround, you can use my suggestion from previous post and manually convert UTF16 into UTF8
another solution is convert UTF16 to UTF8 by request in OnGetText event

Delphi-Quellcode:

procedure TForm1.tbl_test31144_utf8WSTRGetText(Sender: TDACustomField;
  var Text: string; DisplayText: boolean);
begin
  if Sender.DataType = datWideString then Text := UTF8Encode(Sender.asWideString);
end;

Zitat:

in this case, data in grid will be shown correctly, but it will require fix in TDataSet.DataConvert, also manual encoding will be required if you wanted to use UTF16 string in lazarus controls like edit/memo

[Bernhard Geyer]

Zitat:

Zitat von manfred_h (Beitrag 1317552)

Hier das neueste Update:

Sieht im Moment nicht so gut aus...:pale:

Zitat:

the main difference between Delphi and Lazarus: Delphi uses UTF16 for unicode support in comparing Lazarus that uses UFT8 ...
RO/DA use UTF16 for unicode support because it other our platforms (.NET/Cocoa/etc) also use UTF16.

as a workaround, you can use my suggestion from previous post and manually convert UTF16 into UTF8
another solution is convert UTF16 to UTF8 by request in OnGetText event

Delphi-Quellcode:

procedure TForm1.tbl_test31144_utf8WSTRGetText(Sender: TDACustomField;
  var Text: string; DisplayText: boolean);
begin
  if Sender.DataType = datWideString then Text := UTF8Encode(Sender.asWideString);
end;

Zitat:

in this case, data in grid will be shown correctly, but it will require fix in TDataSet.DataConvert, also manual encoding will be required if you wanted to use UTF16 string in lazarus controls like edit/memo

Lazarus geht mit ihren UTF8-Weg schon ziemlich einen ungewöhnlichen Weg. Viele Systeme (.NET/Java/Windows/Delphi) gehen den UTF-16 Weg.
Trotzdem sollte eine Bibliothek die man (kostenpflichtig? Kauft) schon alle Eigenheiten des Unterstützen System berücksichtigen und nicht sagen: "Wir machen es in allen Systemen anders, also passt ihr euch an".

[IBExpert]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1317554)

Lazarus geht mit ihren UTF8-Weg schon ziemlich einen ungewöhnlichen Weg. Viele Systeme (.NET/Java/Windows/Delphi) gehen den UTF-16 Weg.

Einspruch: https://en.wikipedia.org/wiki/UTF-8
"UTF-8 is the dominant character encoding for the World Wide Web, accounting for 85.1% of all Web pages in September 2015"
UTF16 ist durch Windows weit verbreitet, wer sich aber mal eine typische Textdatei im Hex Editor anschaut, sieht sofort die Nachteile von UTF16, denn wie der Name schon beeinhaltet, ist für jedes Zeichen immer mindestens 2 Byte Platz erforderlich, auch wenn da nur Ascii Zeichen wie A-Z und 0-9 drin stehen. Das betrifft im westeuropäischen Sprachraum sicherlich den Großteil aller Daten. Die Dateien sind daher bei gleichem Inhalt fast doppelt so groß. Und für den restlichen Bereich (Asien etc) sind die meisten Zeichen 4 Byte lang. Daher ist UTF8 im Sinne von Übertragung und Speicherung meistens ökonomischer. Das ist zwar eigentlich Haarspalterei, aber UTF8 ist keineswegs ungewöhnlich.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1317554)

Trotzdem sollte eine Bibliothek die man (kostenpflichtig? Kauft) schon alle Eigenheiten des Unterstützen System berücksichtigen und nicht sagen: "Wir machen es in allen Systemen anders, also passt ihr euch an".

Ich frag mich sogar noch mehr, ob die das überhaupt umfassend testen. Den Vorschlag, das dann im GetText zu konvertieren, halte ich für eine komplette Bankrotterklärung. Man sollte nicht vergessen, das Komponenten wie die in Lazarus eingebauten SQL DB Komponenten es auf jeder Plattform (windows, Linux, Mac usw) hinkriegen, ohne manuelles GetText das richtige Zeichen auf den Bildschirm zu bekommen.

Wenn man also als Komponentenhersteller die Komponenten aus reinem Opportunismus auf dieser Plattform "benutzbar" macht, in dem es sich kompilieren lässt und für einige der unterstützten Plattformen bzw Charsets auch benutzen lässt, dann sollten die den potentitellen Käufer doch drauf hinweisen. Wenn manfred_h der erste ist, der das gemerkt hat und man erst Tage später nach intensiven Nachhaken eine unbefriedigende Erklärung dazu geben kann, ist das im Sinne einer Produkthaftung sicherlich Grund genug, das Geld zurückfordern zu können. Ich gehe nämich auch davon aus, das beim Schreiben SetText ebenso behandelt werden müsste und spätestens jetzt macht die Komponente mehr Arbeit als man dadurch einspart, im Vergleich zu den eingebauten SQL DB Komponenten.

[Bernhard Geyer]

Zitat:

Zitat von IBExpert (Beitrag 1317562)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1317554)

Lazarus geht mit ihren UTF8-Weg schon ziemlich einen ungewöhnlichen Weg. Viele Systeme (.NET/Java/Windows/Delphi) gehen den UTF-16 Weg.

Einspruch: https://en.wikipedia.org/wiki/UTF-8
"UTF-8 is the dominant character encoding for the World Wide Web, accounting for 85.1% of all Web pages in September 2015"
UTF16 ist durch Windows weit verbreitet, wer sich aber mal eine typische Textdatei im Hex Editor anschaut, sieht sofort die Nachteile von UTF16, denn wie der Name schon beeinhaltet, ist für jedes Zeichen immer mindestens 2 Byte Platz erforderlich, auch wenn da nur Ascii Zeichen wie A-Z und 0-9 drin stehen. Das betrifft im westeuropäischen Sprachraum sicherlich den Großteil aller Daten. Die Dateien sind daher bei gleichem Inhalt fast doppelt so groß. Und für den restlichen Bereich (Asien etc) sind die meisten Zeichen 4 Byte lang. Daher ist UTF8 im Sinne von Übertragung und Speicherung meistens ökonomischer. Das ist zwar eigentlich Haarspalterei, aber UTF8 ist keineswegs ungewöhnlich.

Mir ging es mit ungewöhnlich um den Faktor Frameworks/OS. Das UTF8 beim Speichern oder im web (Kein Webseite läuft auf UTF16 sondern primär auf UTF8).
AFAIK hat aber auch OSX UTF16 als die primäre/bevorzugte Codierung und auch Android (wegen starker Java-Wurzeln) wird UTF16 haben.
Und dann ist es von vorteil wenn auch die eigene Sprache UTF16 verwendet damit bei jedem API aufruf gewandelt werden muss. Vor einiger Zeit habe ich Lazarus getestet und dort war es nicht möglich (oder nur sehr umständlich) alle File-Funktionen mit Dateien mit Sonderzeichen zu nutzen.

[Bernhard Geyer]

Zitat:

Zitat von IBExpert (Beitrag 1317562)

Ich frag mich sogar noch mehr, ob die das überhaupt umfassend testen. Den Vorschlag, das dann im GetText zu konvertieren, halte ich für eine komplette Bankrotterklärung. Man sollte nicht vergessen, das Komponenten wie die in Lazarus eingebauten SQL DB Komponenten es auf jeder Plattform (windows, Linux, Mac usw) hinkriegen, ohne manuelles GetText das richtige Zeichen auf den Bildschirm zu bekommen.

Wenn man also als Komponentenhersteller die Komponenten aus reinem Opportunismus auf dieser Plattform "benutzbar" macht, in dem es sich kompilieren lässt und für einige der unterstützten Plattformen bzw Charsets auch benutzen lässt, dann sollten die den potentitellen Käufer doch drauf hinweisen. Wenn manfred_h der erste ist, der das gemerkt hat und man erst Tage später nach intensiven Nachhaken eine unbefriedigende Erklärung dazu geben kann, ist das im Sinne einer Produkthaftung sicherlich Grund genug, das Geld zurückfordern zu können. Ich gehe nämich auch davon aus, das beim Schreiben SetText ebenso behandelt werden müsste und spätestens jetzt macht die Komponente mehr Arbeit als man dadurch einspart, im Vergleich zu den eingebauten SQL DB Komponenten.

Diese Methode andere Codierung einer Komponente beizubringen die es nicht kann habe ich so 2002 gemacht als wir unser D6 Programm Unicode bei gebracht haben.
In 2015 sehe ich das als Krücke an. Empfiehlt der Komponentenhersteller das, wäre das für mich ein Argument nach Alternativen zu suchen.

[manfred_h]

Danke für Eure Antworten.

Für mich war RemObjects eine gute Idee, weil ich eine Komponente suchte, mit der ich eine Verbindung auf einen zentralen MySQL Server realisieren kann, ohne dass dieser direkt ansprechbar ist.
RemObject hat für dies eine html Schnittstelle, die dies übernimmt. Die Benutzerverwaltung konnte auch schön mit einem LDAP-Server realisiert werden.

Momentan bin ich mir nicht sicher, wie ich weitergehen soll...
Lazarus habe ich ausgesucht, da dies sehr ähnlich wie Delphi ist. Von Delphi wollte ich aus Kostengründen "weg". Nichts generell gegen Delphi. :wink:
Habe mich auch schon ( die letzten Tage ) mit dem Gedanken beschäftigt, ob Visual Studio eine Option wäre....
Lazarus hat mich auch begeistert, da ich eine Codebasis für Windows / OS X / Linux hatte.

Shalom
Manfred

PS: Der Support von RemObject war immer sehr gut Erreichbar und hat eigentlich immer gute Lösungsvorschläge unterbreitet. Wollte dies nur kommunizieren, da ich kein schlechtes Licht auf den Support werfen möchte. Das aktuelle Problem ist aber trotzdem sehr ärgerlich...

[IBExpert]

Zitat:

Zitat von manfred_h (Beitrag 1317646)

Für mich war RemObjects eine gute Idee, weil ich eine Komponente suchte, mit der ich eine Verbindung auf einen zentralen MySQL Server realisieren kann, ohne dass dieser direkt ansprechbar ist.

Dafür benutzen wir in einem sehr großen Projekt sehr gerne SSH (auf windows mit putty bzw plink) und bauen damit von verbundenen clients aus einen Reverse Tunnel auf. Ohne SSH Key kommt dann eh keine auf die Kiste, der Traffic ist verschlüsselt und komprimiert und über den gleichen Kanal kannst du parallel auch neben deiner DB auch noch ftp,rdp oder sonstwas drauf binden. Aus der Sicht deiner client app kannst du alles machen, was sonst auch per tcp auf der Remotemaschine geht. Ist eine ähnliche Technik mit der auch Teamviewer bzw pcvisit verbindungen aufbaut, wenn man das über ein gateway server macht, dann braucht außer der keiner der anderen beteiligten System eine nach außen erreichbaren offenen Port.

Ergänzend nutzen wir in anderen Projekten einen 30 Zeiler in php, mit dem wir dann (in dem Falle aber mit Firebird) via http bzw https request sql abfragen an einen apache webserver senden und der uns dann die resultate in einem csv format zurücksendet (Der Rest ist in einer Firebird SP realisiert).

Leider ist in deiner Aussage aber schon das größte Problem vieler Delphi Programmierer enthalten: man sucht nach einer Komponente!

Die macht dann oft ganz viele tolle Dinge, aber das eigentliche Problem wäre oft ohne Komponente viel einfacher umzusetzen. Remobjects gehört sicherlich neben devexpress und tms zu den besten Herstellern, die noch im Delphi Markt existieren, aber man sollte immer die Alternative Do it yourself im Auge behalten, ist oft weniger schwierig als man denkt.

[manfred_h]

Hallo zusammen
Gute neuigkeiten von remobjects:thumb:. Das ganze wurde als Bug eingestuft wird behoben.

Zitat:

Thanks, logged as bugs://73397
bugs://73397 got closed with status fixed.
it will be in next beta (in a week)

Shalom
Manfred

[manfred_h]

Hallo zusammen

Wollte Euch nur Informieren das mit der allerneuesten Beta das Problem behoben ist:
> RemObjects Data Abstract for Delphi - 9.0.94.1193.exe [Branch: beta] — Fri, Oct 30, 2015
( Es gab heute 2.11.2015 ) noch eine kleine Korrektur.
:-D:thumb:

Shalom
Manfred

@IBExpert: Danke auch nochmal für Deine guten Einwände.:thumb: