Copy from und to - falsches Binärdatenformat

Servus,

hatte die Frage schon mal gestellt, ist leider immer noch aktuell. Aus meiner Anwendung heraus müssen Tabellen zwischen 2 Datenbanken zwischen 2 PG-Installationen abgeglichen / kopiert werden.
Eigentlich ganz einfach: copy table1 to \\blalba\table1 (format BINARY, ENCODING "UTF8"). Funktioniert.
Aber das copy table1 from \\blalba\table1 (format BINARY, ENCODING "UTF8") dann nicht, obwohl bei meinem Test sogar mit derselben PG-Installation, nur versch. Datenbanken.
Bekomme die Fehlermeldung:

falsches Binärdatenformat CONTEXT: copy table1, Zeile 1, Spalte daten_lock.

daten_lock ist boolean.

Was mache ich falsch?

kann ich grad nicht nachvollziehen, also hier klappt es.

  • Du hast Windows?
  • der Pfad müßte in ’ eingeschlossen sein
  • mal hast Du \ und dann nur \
  • Encoding ‘UTF8’, mit einfachen ’

Servus,

danke für die schnelle Antwort. Ja, Windows und so sieht der Befehl genau aus:

copy ticketsystem TO ‘D:\PostgreSQL\Test\ticketsystem’ (format BINARY, ENCODING ‘UTF8’, HEADER FALSE)
und so das Gegenstück:

copy ticket FROM ‘D:\PostgreSQL\test\ticket’ (format BINARY, ENCODING ‘UTF8’, HEADER FALSE)

Ich hatte das nur schnell aus dem Kopf getippt, sorry.

Servus,

da ich dringend eine Lösung brauche (Offline-Betrieb auf Notebooks), hab ich mich jetzt deswegen an pg_dump rangemacht.
Das ist ja übel, man muss dann mit seiner Anwendung 12 fremde Dateien ausliefern und ein automatischer Modus ist nur extrem eingeschränkt möglich?

Hat mich jetzt 4 Std. Recherche und Tests gekostet bis ich an dem Punkt bin, dass pg_dump nicht mittels shellexecute oder ähnlichem aufgerufen werden kann, da ansonsten jede Art eines User-Passwortes ignoriert wird.
Weder das Erzeugen einer pgpass.conf im Appdata\postgresql - Verzeichnis noch das setzen der Umgebungsvariable PGPASSFILE werden bei shellexecute berücksichtigt. Beides funktioniert nur mittels einer Eingabekonsole. Also eine cmd?

Wieso musst Du “12 fremde Dateien” ausliefern? Wenn auf beiden Rechner Postgres installiert ist, dann ist auch auf beiden Rechnern pg_dump bzw. psql und pg_restore verfügbar.

Keine Ahnung wie genau Du shellexecute aufrufst, aber %AppData%\postgresql\ppgpass.conf ist natürlich Benutzer spezifisch. Wenn Du bei shellexecute() also sowas wie “RunAs” machst, dann muss das natürlich unter dem %AppData% des “anderen” Benutzers zu finden sein.

Was ist so schlimm an einem einfacher Bachdatei?

1 „Gefällt mir“

Servus castorp,

danke, daran hab ich gar nicht gedacht. Mal sehen, wie ich den Pfad der PG-Installation rausbekomme.
Das mit runas bei shellexecute ist logisch, danke für den Tipp!

Eine cmd öffnet ein hässliches Eingabefenster, das sieht nicht schön aus. Wäre interessant, wie pgAdmin das macht…

Hab jetzt alles versucht, aber über shellexecute bekomme ich es nicht hin, da es hier nur mit “runas” geht und das fordert Admin-Rechte an. Es bringt auch nichts, ob die pgpass.conf in %appdata%\postgresql ist, oder mittels pgpassfile in einem anderen Pfad.
Es geht nur mittels einer CMD. Die kann ich über shellexecute und SW_HIDE doch versteckt ausführen, das funktioniert dann.

Danke castorp!!!
Das ist

Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.