Zugriff aus postgis Datenbanken mit FireDac

[MichaelP]

Ich nutze Firedac zum Zugriff auf Postgres Datenbanken.
Ich habe jetzt versucht auf Datenbanken mit der POSTGIS Erweiterung zuzugreifen. Jedoch erhalte ich beim Zugriff auf Datenbanken mit Geometriefeld immer eine Fehlermeldung.
Ist ein Zugriff mit FireDAC auf Tabellen mit Geometrie möglich?

UTF( Fehler
Hat jemand von eunch hiermit Erfahrungen?

Gruß
Michael

[jobo]

Zitat:

Zitat von MichaelP (Beitrag 1361273)

..Jedoch erhalte ich beim Zugriff auf Datenbanken mit Geometriefeld immer eine Fehlermeldung.
Ist ein Zugriff mit FireDAC auf Tabellen mit Geometrie möglich?

UTF( Fehler

Ich habe damit keine Erfahrung.
Beim Zugriff auf die Datenbank oder beim Zugriff auf eine spezifsiche Tabelle?

Soll ..UTF(Fehler.. die Fehlermeldung sein?

[RSF]

Ich gehe davon aus das der Zugriff auf eine Tabelle mit Geometriefelder gemeint ist.
Versuche einmal ein Testprojekt mit ZEOS Komponenten zu erstellen.
Benutze selber eine Postgres DB damit (aber ohne Geometrie, deshalb nur ein Versuch).
Ich hatte ein Projekt mit einer ADS Datenbank und dieses wollte ich mit FireDAC betreiben.
Ergebnis war, dass die Kommunikation zwischen ADS und FireDac Umständlich und Unvollständig war.
Danach mühevoll die originalen Advantage Komponenten per Hand installiert (kein Installer für Delphi Berlin vorhanden). Damit waren alle Funktionen verfügbar.

[MichaelP]

Habe jetzt eine andere fehlermeldung:
Firedac phys pg 1505 falscher komlexer Typ

Code:

CREATE TABLE public.points
(
  gid integer NOT NULL DEFAULT nextval('points_gid_seq'::regclass),
  osm_id character varying(11),
  "timestamp" character varying(20),
  name character varying(48),
  type character varying(16),
  geom geometry(Point),
  CONSTRAINT points_pkey PRIMARY KEY (gid)

Ich gehe davon aus das FIREDAC nicht mit den geometry felder umgehen kann

[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:

Zitat von RSF (Beitrag 1361300)

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.:roll:

Gruß
K-H

[jobo]

Zitat:

Zitat von RSF (Beitrag 1361300)

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.

[RSF]

Zitat:

Zitat von p80286 (Beitrag 1361319)

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:

Zitat von RSF (Beitrag 1361346)

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.