Zugriff aus postgis Datenbanken mit FireDac

[jobo]

Ja, in welchen Typ sollte das eingetütet werden?
Du wirst es entweder zerlegen müsssen:
schau mal hier die "API"
http://postgis.net/docs/manual-2.0/r...etry_Accessors

Für Dich vielleicht hilfreich
st_x, st_y,
oder st_astextx (unter Geometry Outputs)

Ähnlich wirst Du wohl vorgehen müssen, wenn Du Werte eintragen willst.

Oder:
Alternativ musst Du den Point binär abfragen, seinen Aufbau kennen und dann in Delphi eine Zugriffsmethode bauen.
Hat wahrscheinlich auch schon mal irgendjemand irgendwo gemacht.

[RSF]

Einen Konstrukt aus Eigenbau einer Zugriffsmethode aus API und .. herzustellen ist nach meiner Ansicht unwirtschaftlich.
Wenn eine Komponente (FireDAC) vorgibt mit mit Postgres DB umgehen zu können erwarte ich auch eine aktuelle Unterstützung.
Besser nach einer funktionierenden DB Komponente suchen wenn die vorhandene Ihren Zweck nicht erfüllt.
Es ist immer ärgerlich wenn man wertvolle Zeit in Dinge steckt die sich später als Flopp entpuppen.
PS: Ich habe nichts gegen FireDAC, aber in manchen anspruchsvollen Aufgaben macht diese einen unvollständigen und aufwendigen Eindruck.

[p80286]

Zitat von RSF:

Einen Konstrukt aus Eigenbau einer Zugriffsmethode aus API und .. herzustellen ist nach meiner Ansicht unwirtschaftlich.
Wenn eine Komponente (FireDAC) vorgibt mit mit Postgres DB umgehen zu können erwarte ich auch eine aktuelle Unterstützung.
Besser nach einer funktionierenden DB Komponente suchen wenn die vorhandene Ihren Zweck nicht erfüllt.
Es ist immer ärgerlich wenn man wertvolle Zeit in Dinge steckt die sich später als Flopp entpuppen.

Rein theoretisch hast Du ja recht, aber in der Praxis können diese Komponenten ja alles, bis auf das, was eigentlich niemand bisher gebraucht hat.

Gruß
K-H

[RSF]

Zitat von p80286:

Rein theoretisch hast Du ja recht, aber in der Praxis können diese Komponenten ja alles, bis auf das, was eigentlich niemand bisher gebraucht hat.

Genau das ist was ich meine. Die allgemeinen „Universal- Komponenten“ (hier FireDac) versagen einfach wenn es spezifisch wird. Deshalb ist es besser (wirtschaftlicher) nicht das Fahrrad nochmal zu erfinden stattdessen spezialisierte darauf abgestimmte Komponenten zu verwenden/suchen.
Natürlich kann man selbst Hand anlegen. Wer die Zeit und Geduld hat.

@ jobo

Zitat:

Dass PostGIS oder der POINT Typ ein Flopp wird, kann ich mir auch kaum vorstellen.

Das PostGIS ein Flopp wäre habe ich nie geschrieben. Bitte immer schön bei der Wahrheit bleiben!
(Flopp stand im Bezug zu Komponenten und Funktionsinhalt)

Ronald

[jobo]

Zitat von RSF:

Die allgemeinen „Universal- Komponenten“ (hier FireDac) versagen einfach wenn es spezifisch wird. Deshalb ist es besser (wirtschaftlicher) nicht das Fahrrad nochmal zu erfinden stattdessen spezialisierte darauf abgestimmte Komponenten zu verwenden/suchen.

Ok, damit der TE nicht so lange suchen muss:
Welche Komponente empfiehlst Du?

Und nochmal zu Deiner Kritik (ich will es nicht tot reiten und ich sage auch nicht die Wahrheit, schon gar nicht die absolute). Ich kann es meinem Auto nicht vorwerfen, wenn die neuen hightech Niederqueschnitts- Nachhaltigkeitsreifen nicht auf die alten Felgen passen.

[RSF]

Du bist nicht der TE Ersteller. Er wird sich selbst zu Wort melden wenn er etwas wissen möchte.
Ende OT

[mkinzler]

Zitat von RSF:

Du bist nicht der TE Ersteller. Er wird sich selbst zu Wort melden wenn er etwas wissen möchte.
Ende OT

Das wird er hoffentlich. Aber trotzdem ist die Nachfrage von jobo legitim.

[jobo]

Zitat von RSF:

Du bist nicht der TE Ersteller. Er wird sich selbst zu Wort melden wenn er etwas wissen möchte.
Ende OT

Mir ist bekannt, dass ich nicht der TE bin.
Ich habe dem TE bereits gezeigt, wie er ohne die Hilfe jeglicher Zusatzkomponenten die gewünschten Werte abfragen kann und noch viel mehr, konsistent aus POSTGIS heraus.
Da Du seine Frage nicht beantwortet hast, sondern die verwendeten Komponenten kritisiert hast und von besseren Möglichkeiten und Wirtschaftlichkeit geschrieben hast, habe ich das aufgegriffen und Dich lediglich gefragt, was konkret an Komponenten zu nennen wäre.

[jobo]

Zitat von RSF:

Einen Konstrukt aus Eigenbau einer Zugriffsmethode aus API und .. herzustellen ist nach meiner Ansicht unwirtschaftlich.
Wenn eine Komponente (FireDAC) vorgibt mit mit Postgres DB umgehen zu können erwarte ich auch eine aktuelle Unterstützung.
Besser nach einer funktionierenden DB Komponente suchen wenn die vorhandene Ihren Zweck nicht erfüllt.
Es ist immer ärgerlich wenn man wertvolle Zeit in Dinge steckt die sich später als Flopp entpuppen.
PS: Ich habe nichts gegen FireDAC, aber in manchen anspruchsvollen Aufgaben macht diese einen unvollständigen und aufwendigen Eindruck.

Also ich weiß nicht, ob es in dem Fall für die Umsetzung eines Point Types so unwirtschaftlich wäre. Kommt auf die eigenen Fähigkeiten an.

Zum Rest Deines Beitrages:
Ich denke, dass man das so nicht sehen kann.
PostgreSQL ist sehr typstark. Man kann minütlich neue Typen produzieren und ausspucken. Wer soll die dann bitte alle in Delphikomponenten umwandeln?
Die Sache läuft anders. Die Erfinder der neuen Typen (wie z.B. point) liefern eine Zugriffs API mit, die mit bekannten Standardtypen arbeitet.
Nett oder?
Damit greift man dann bspw. nicht den Point ab, sondern dessen "Einzelteile".

Dass PostGIS oder der POINT Typ ein Flopp wird, kann ich mir auch kaum vorstellen.

Ich kann mir aber vorstellen, dass ein "POINT" oder andere Geometrietypen es irgendwann auch mal in das Standardrepertoire von Delphi schaffen, aber das dauert bestimmt noch.