Re: Neu dabei und vermutlich -> nur ein Haufen alter Fragen.

Hallo!

Ich habe mich mal bei der Liste neu angemeldet
und hoffe nun, daß ich hier keinen mit zu ein-
fachen Fragen nerve.

Zur Umgebung:

-Immer mehr gemerkt, daß man richtige DB braucht.
-Nach Vergleich und Bauchentscheidung: PostgreSQL
-Erste Anwendung: Hinter Tabellen via ODBC gehängt.
-Frontend: StarOffice 5.2 [ Bin Purist :)]
-Bedarf war:
Daten aus DB in Tabelle importieren...
Weiter bearbeiten und dann Ergebnisse
zu den Daten zurückschreiben.

Stand der Dinge:

-Tabellen für Musteranwendungen sind fertig.
-SQL-Insert, SQL-Update via Makro geht auch.

Nun kommen langsam Fragen auf:

-Einfache Beschreibung aller möglichen Variablen
sind wo zu finden?

-Standard- Frontends sind, d.h. was ist hier
bei Euch so die Erste Wahl für Formulare etc.?

-Client-Server... Datenim- und Export via
Netzwerk steht als nächstes auf dem Zettel.
(via Internet währe mal eine Frage am Rande)

Suchen tut er hier.... Erfahrungsaustausch

-StarOffice- Anwender, die sich auch mit der
PG- Anbindung amüsieren.

-PG- Experten, die sich schon mal mit SO oder
auch OO herum geschlagen haben.

Oder bin ich hier vollkommen falsch und wäre
besser bei _________________ (?) aufgehoben?

Mit freundlichen Grüßen

wW

am 31.05.2006, um 11:17:50 +0000 mailte Wolfram Wahlich folgendes:
> Hallo!
>
> Ich habe mich mal bei der Liste neu angemeldet
> und hoffe nun, daß ich hier keinen mit zu ein-
> fachen Fragen nerve.

Du bist Willkommen!

> -Einfache Beschreibung aller möglichen Variablen
> sind wo zu finden?

Welche Variablen? Ich versteh die Frage nicht.
Konfiguration von PG, also postgresql.conf, pg_hba.conf? Oder Dinge wie
CURRENT_DATE? Oder das, was Du mit 'show all;' in psql sehen kannst?

> -Standard- Frontends sind, d.h. was ist hier
> bei Euch so die Erste Wahl für Formulare etc.?

Ich mache hier z.B. einige kleinere Anwendungen, wo Formulare mit HTTP
bzw. mit TclTK gemacht werden, Ausdrucke mit LaTeX.

> -Client-Server... Datenim- und Export via
> Netzwerk steht als nächstes auf dem Zettel.
> (via Internet währe mal eine Frage am Rande)

Es gibt keine prinzipiellen Unterschiede zwischen lokal, LAN und
Internet. Natürlich gibt es Unterschiede bzgl. der Sicherheit. Frag
einfach.

> Suchen tut er hier.... Erfahrungsaustausch
>
> -StarOffice- Anwender, die sich auch mit der
> PG- Anbindung amüsieren.

Nutze ich nicht. Aber ein Hinweis: http://pgug.de/faq/faq.php, 3. Frage.

> Oder bin ich hier vollkommen falsch und wäre
> besser bei _________________ (?) aufgehoben?

Nein, schon okay. Es gibt noch pgug.de und unseren Chat #postgresql-de.

Mit freundlichen Grüßen, A. Kretschmer
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

Wolfram Wahlich wrote:

> -Client-Server... Datenim- und Export via
> Netzwerk steht als nächstes auf dem Zettel.
> (via Internet währe mal eine Frage am Rande)

Das ist mit dem alten StarOffice wirklich nicht ganz so einfach, wie
es mit OpenOffice ab 1.1 moeglich ist. Fuer letzteres gibt es naemlich
den praktischen SDBC-Treiber:

http://dba.openoffice.org/drivers/postgresql/

Falls das Update auf OpenOffice fuer Dich keine Alternative ist, dann
vergiss diese Mail ;-)

Tschuess,
Martin.
P.S.: Irgendwo wird auch eine JDBC-Anbindung beworben, wobei ich mich
allerdings frage, warum man das moechte, wenn es auch anders
geht ....
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

"A. Kretschmer" wrote:

>> Suchen tut er hier.... Erfahrungsaustausch
>>
>> -StarOffice- Anwender, die sich auch mit der
>> PG- Anbindung amüsieren.
>
> Nutze ich nicht. Aber ein Hinweis: http://pgug.de/faq/faq.php, 3. Frage.

Dank fuer's Suchen ! :-)
Hat jemand eine Vorstellung davon, ob das hier beschriebene Verfahren
den Aufwand lohnt, den es gegenueber der SDBC-Variante erfordert ?

Tschuess,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

am 31.05.2006, um 13:36:48 +0000 mailte Martin Spott folgendes:
> "A. Kretschmer" wrote:
>
> >> Suchen tut er hier.... Erfahrungsaustausch
> >>
> >> -StarOffice- Anwender, die sich auch mit der
> >> PG- Anbindung amüsieren.
> >
> > Nutze ich nicht. Aber ein Hinweis: http://pgug.de/faq/faq.php, 3. Frage.
>
> Dank fuer's Suchen ! :-)
> Hat jemand eine Vorstellung davon, ob das hier beschriebene Verfahren
> den Aufwand lohnt, den es gegenueber der SDBC-Variante erfordert ?

Keine Ahnung, aber ein Nachtrag: in der aktuellen PWN steht:

Native PostgreSQL driver sdbc 0.7.2 for OpenOffice.org released.
http://dba.openoffice.org/drivers/postgresql/index.html

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

Am Mittwoch, 31. Mai 2006 15:07 schrieb Martin Spott:
> P.S.: Irgendwo wird auch eine JDBC-Anbindung beworben, wobei ich mich
> allerdings frage, warum man das moechte, wenn es auch anders
> geht ....

Ich würde aktuell immer den JDBC-Treiber dem SDBC-Treiber vorziehen. Der
JDBC-Treiber ist gut getestet und hat eine große Entwicklergruppe. Der
SDBC-Treiber wurde ein paar Jahre gar nicht aktualisiert, ist wohl aktuell
ein Einzelkämpferprojekt und wenn man ihn jetzt herunterlädt bekommt man ein
paar Binaries ohne Dokumentation. Und was er besser kann weiß ich auch nicht.

Ist vielleicht auch nicht besonders schlüssig, aber ich bin dagegen, dass
jeder seinen eigenen Treiber schreibt, denn das wird immer Mist.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am Mittwoch, 31. Mai 2006 13:17 schrieb Wolfram Wahlich:
> -Standard- Frontends sind, d.h. was ist hier
> bei Euch so die Erste Wahl für Formulare etc.?

Eigentlich gibt's da nur Access und {Open|Star}Office. Natürlich gibt's da
auch noch ne Menge Toolkits fürs Web, aber das ist wohl eine andere
Kategorie.

Wen's interessiert, ich habe dazu in Chemnitz referiert. Kann man sich unter
<http://chemnitzer.linux-tage.de/2006/vortraege/detail.html?idx=289> anhören.
Darauf aufbauend ist auch ein Artikel in der aktuellen (06/06) Linux User
erschienen, wo sich auch noch einige andere Datenbankartikel aufhalten.

Persönlich würde ich das so zusammenfassen, dass für Open-Source-Fanatiker
OpenOffice.org 2 ganz gut ist, ansonsten MS Access.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am 31.05.2006, 14:33:32, schrieb "A. Kretschmer"
<andreas(dot)kretschmer(at)schollglas(dot)com>

Hallo Andreas.

Wir kennen uns auch aus der Newsgroup....

> > Ich habe mich mal bei der Liste neu angemeldet
> > und hoffe nun, daß ich hier keinen mit zu ein-
> > fachen Fragen nerve.

> Du bist Willkommen!

Dennoch?

Schön:)

> Welche Variablen? Ich versteh die Frage nicht.

Mögliche Variablen der Datenbankfelder.
Und deren Nutzen. Einiges kann ich umstellen,
einiges nicht.
Ich lerne zur Zeit durch try & error.

> Konfiguration von PG, also postgresql.conf,
> pg_hba.conf?

Kommt bald, da ich da wohl eintragen muß,
welcher Rechner via Lan zugreifen darf,
korrekt?

> Oder Dinge wie CURRENT_DATE?
> Oder das, was Du mit 'show all;'
> in psql sehen kannst?

Zum Beispiel.

Date.....
Hier habe ich schon einen Fallstrick gehabt.

Man nehme eine Tabelle und trage den Geburtstag ein.
Was kommt raus? Eine Zahl, die auf einen Tag um 1899
herum aufaddiert liegt. Doll.

Wenn ich das Feld in der Tabelle dann als Text
definiere wird das Datum als Text eingefügt.

OK.

Wenn ich dann aber einen Stichtag bezogen auf
irgendeinen Wert errechnet haben will, dann kann
das die Tabelle mit dem TEXT- Feld Datum nicht mehr.

Und... auch ein netter Nebeneffekt:

Vor das Datum wird ein >>>'<<< gestellt.

Wenn dieser Wert dann in die Tabelle zurück
importiert wird kann ich damit so ohne weiteres
nicht rechnen lassen.

Das Problem Datum ist so schon mal <interessant.>

Zur Zeit erlaube ich StarOffice, das Datum in dem
internen Wert in die DB zu schreiben. In die
Tabelle importiert steht in der Spalte, die
als Format DATUM hat wieder der richtige Wert,
das Geburtsdatum.

Das Zahlenformat Geburtsdatum kann ich in der
Textverarbeitung aber so nicht gleich nutzen.
Hier muß ich schon eine Zelle mit weißem Text
haben... und an der Stelle, wo das Datum stehen
soll muß ich mit =DATUM(Zelle-mit-weißem-TEXT)
arbeiten.

Soweit so gut.

Das geht also.

Nur sollen diese Adress- Daten dann auch in eine
gesamt- Adress- Datenbank mit einfließen.

Das habe ich gleich so angelegt, das es den Feldern
des- Palm- Adressbuches entspricht.

Nur spätestens der Palm kann mit
den Werten Datumswerten [1.1.899 + N_Tage] nix anfangen.

Das ist also eine offene Baustelle.
Eine Notlösung mit der ich zur Zeit lebe.

Da ich bestimmt nicht der Erste
mit solchen Fragen bin muß es da
bestimmt eine Lösung geben, die ich
noch nicht kenne.

Wo kann man zu solchen Sorgen etwas finden?

> Ich mache hier z.B. einige kleinere Anwendungen,
> wo Formulare mit HTTP bzw. mit TclTK gemacht
> werden, Ausdrucke mit LaTeX.

Http scheint da auch ein einfacher(?) / möglicher
Weg zu sein. Mal sehen... dahingehend werde ich
auch mal testen und mit Fragen nerven.

> Es gibt keine prinzipiellen Unterschiede zwischen
> lokal, LAN und Internet. Natürlich gibt es
> Unterschiede bzgl. der Sicherheit. Frag
> einfach.

OK.
PostgreSQL 8.1 auf einem eigenen Laufwerk
unter Windoof eingerichtet.

Nichts weiter geändert.

Nun soll ein anderer Rechner auch auf diese
PG- Installation / DB zugreifen

PG auf 192.168.7.21

Andere Rechner, die zugreifen sollen
ab 192.168.7.31

Wo muß was eingestellt werden?
RTFM = wo auf deutsch?

> > Suchen tut er hier.... Erfahrungsaustausch
> > -StarOffice- Anwender, die sich auch mit der
> > PG- Anbindung amüsieren.

> Nutze ich nicht. Aber ein Hinweis:
http://pgug.de/faq/faq.php, 3. Frage.

Danke, das ist aber Open Office.
Aber das werde ich mir trotzdem mal reinziehen.

Die Anbindung ist soweit auch fertig.
Das passiert über Makros, die auf
Knopfdruck oder Freischaltung
aktiviert werden.

> > Oder bin ich hier vollkommen falsch und wäre
> > besser bei _________________ (?) aufgehoben?

> Nein, schon okay. Es gibt noch pgug.de
> und unseren Chat #postgresql-de.

Schau ich mal bei Gelegenheit vorbei....

> Mit freundlichen Grüßen, A. Kretschmer

Mit freundlichen Grüßen

wW

"A. Kretschmer" wrote:

> Keine Ahnung, aber ein Nachtrag: in der aktuellen PWN steht:
>
> Native PostgreSQL driver sdbc 0.7.2 for OpenOffice.org released.
> http://dba.openoffice.org/drivers/postgresql/index.html

Genau den benutze ich schon seit einigen Versionen und ich bin
inzwischen ganz froh damit - die allerersten Ausgaben schaetzungsweise
gegen Ende 2003 waren halt noch etwas hakelig in der Anwendung, wie das
mit ganz 'frischer' Software ja schonmal vorkommt.
Praktisch bei diesem Treiber ist, dass man nicht alleine fuer die
Datenbank-Anbindung gleich eine ganze Java-Runtime mitschleppen muss.

Tschuess,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Am 31.05.2006, 15:07:36, schrieb Martin Spott

Hallo!

> > -Client-Server... Datenim- und Export via
> > Netzwerk steht als nächstes auf dem Zettel.
> > (via Internet währe mal eine Frage am Rande)

> Das ist mit dem alten StarOffice wirklich nicht
> ganz so einfach, wie es mit OpenOffice ab 1.1
> moeglich ist. Fuer letzteres gibt es naemlich
> den praktischen SDBC-Treiber:

Unter SO 5.2 gab und gibt es einen richtigen
DB- Modul, den man auch heute noch benutzen kann.
Abfragen etc. geht gut.
Funzt gut, wenn man ein paar Dinge beachtet.

Ich habe da eine Möglichkeit gezeigt bekommen
und damit einen Daten- Import und Export via Makro
hinbekommen. Das geht soweit zufriedenstellend.

Nur wie in der anderen Mail beschrieben interessiert
mich was da in die DB geschrieben wird und wie es
wieder zurück kommt.

Beispiel: Datum wird verbogen auf irgendeine Zahl.

Will man das verhindern erreicht man, daß ein Text
21.01.2005 hinein geschrieben wird. Heraus kommt aber
'21.01.2005.... und warum?

> http://dba.openoffice.org/drivers/postgresql/

Einen solchen Treiber vermisse ich (noch) nicht :-)

> Falls das Update auf OpenOffice fuer Dich keine
> Alternative ist, dann vergiss diese Mail ;-)

Ist sie nicht.

Wenn ich Dir von den Vorteilen der alten Version
erzähle willst Du vielleicht noch downgraden :-))

> Tschuess,
> Martin.
> P.S.: Irgendwo wird auch eine JDBC-Anbindung beworben,
> wobei ich mich allerdings frage, warum man das moechte,
> wenn es auch anders geht ....

ODBC und gut ist.

Mit freundlichen Grüßen

wW

Hallo zusammen

> Hat jemand eine Vorstellung davon, ob das hier beschriebene Verfahren
> den Aufwand lohnt, den es gegenueber der SDBC-Variante erfordert ?

Als OO2 herauskam, gab es keinen passenden SDBC-Treiber.

Gruesse
Conni
--
http://pgsql.info | http://postgresql.de | http://pgfakt.de
Telefon: 07127 80 961

am 31.05.2006, um 14:50:43 +0000 mailte Wolfram Wahlich folgendes:
> Am 31.05.2006, 14:33:32, schrieb "A. Kretschmer"
> <andreas(dot)kretschmer(at)schollglas(dot)com>
>
> Hallo Andreas.
>
> Wir kennen uns auch aus der Newsgroup....

Woot? Kram...such...

> > Du bist Willkommen!
>
> Dennoch?

Klar ;-)

> Date.....
> Hier habe ich schon einen Fallstrick gehabt.
>
> Man nehme eine Tabelle und trage den Geburtstag ein.
> Was kommt raus? Eine Zahl, die auf einen Tag um 1899
> herum aufaddiert liegt. Doll.

Huch?

>
> Wenn ich das Feld in der Tabelle dann als Text
> definiere wird das Datum als Text eingefügt.

Ein Datum ist aber ein Datum und _KEIN_ Text. Zwei Texte, z.B.
'Pusteblume' und 'Kaffeetasse' kannst Du nicht addieren, zwei
Datumswerte schon.

> Wenn ich dann aber einen Stichtag bezogen auf
> irgendeinen Wert errechnet haben will, dann kann
> das die Tabelle mit dem TEXT- Feld Datum nicht mehr.

Logisch.

> Das Problem Datum ist so schon mal <interessant.>

;-)

>
>
> Zur Zeit erlaube ich StarOffice, das Datum in dem
> internen Wert in die DB zu schreiben. In die

Ich hoffe mal für Dich, daß da jemand mit mehr Ahnung von SO Dir helfen
kann. Ich weiß grad mal, daß es das gibt.

> OK.
> PostgreSQL 8.1 auf einem eigenen Laufwerk
> unter Windoof eingerichtet.

*Seufz* Aber ich soll hier kein WinBashing mehr machen, wurde mir
gesagt...

> Nun soll ein anderer Rechner auch auf diese
> PG- Installation / DB zugreifen
>
> PG auf 192.168.7.21
>
> Andere Rechner, die zugreifen sollen
> ab 192.168.7.31
>
> Wo muß was eingestellt werden?
> RTFM = wo auf deutsch?

In der pg_hba.conf. Da sind Zeilen nach diesem Muster:
# TYPE DATABASE USER CIDR-ADDRESS METHOD

Da legst Du fest, wie Zugriffe erlaubt werden. Die Datei ist kommentiert
(ich hoffe, dies ist auch so unter Deinem OS), da steht alles
wesentliche erklärt. Ansonsten:
http://www.postgresql.org/docs/current/static/client-authentication.html

Deutsch? Auch noch Wünsche? ;-)
http://www.postgresql.org/files/documentation/books/pghandbuch/html/client-authentication.html

Bedanke Dich bei Peter für die Übersetzung ;-)

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

--On Mittwoch, Mai 31, 2006 14:50:43 +0000 Wolfram Wahlich <wW(at)nordcad(dot)de>
wrote:

> Date.....
> Hier habe ich schon einen Fallstrick gehabt.
>
> Man nehme eine Tabelle und trage den Geburtstag ein.
> Was kommt raus? Eine Zahl, die auf einen Tag um 1899
> herum aufaddiert liegt. Doll.
>

Wäre schön wenn du uns mit Informationen deines DB-Schemas versorgen
könntest.
So habe ich keine Ahnung was du da überhaupt treibst.

> Wenn ich das Feld in der Tabelle dann als Text
> definiere wird das Datum als Text eingefügt.
>
> OK.
>

Datumswerte werden immer zunächst als Text geparst, bevor sie entsprechend
gespeichert werden, bspw:

bernd(at)[local]:bernd #= CREATE TABLE date_test(myDate DATE);
bernd(at)[local]:bernd #= INSERT INTO date_test VALUES ('21.01.2005');
bernd(at)[local]:bernd #= INSERT INTO date_test VALUES ('16.04.2005');
bernd(at)[local]:bernd #= select * from date_test ;
mydate
------------
21.01.2005
16.04.2005
(2 rows)

> Wenn ich dann aber einen Stichtag bezogen auf
> irgendeinen Wert errechnet haben will, dann kann
> das die Tabelle mit dem TEXT- Feld Datum nicht mehr.
>
>
> Und... auch ein netter Nebeneffekt:
>
> Vor das Datum wird ein >>>'<<< gestellt.
>

Kommt sicher nicht von der Datenbank

> Wenn dieser Wert dann in die Tabelle zurück
> importiert wird kann ich damit so ohne weiteres
> nicht rechnen lassen.

Mit Timestamp bzw Date lässt sich einfach rechnen, bspw:

bernd(at)[local]:bernd #= select mydate + interval '1 month' from date_test ;
?column?
---------------------
21.02.2005 00:00:00
16.05.2005 00:00:00
(2 rows)

bernd(at)[local]:bernd #= select mydate - interval '1 day' from date_test ;
?column?
---------------------
20.01.2005 00:00:00
15.04.2005 00:00:00
(2 rows)

Man muss nur wissen, dass das Resultat ein Timestamp ist (Datum + Zeit).

--
Thanks

Bernd

Am 01.06.2006, 14:47:18, schrieb Bernd Helmle <mailings(at)oopsware(dot)de>

Hallo!

> Wäre schön wenn du uns mit Informationen Deines
> DB-Schemas versorgen könntest.
> So habe ich keine Ahnung was du da überhaupt treibst.

Das ist noch so primitiv und Einfach, daß ich das
gar nicht zeigen mag. Der Hirnschmalz steckt da
bisher wesentlich mehr in den Tabellen.

Nicht lachen, aber ein unverfängliches Musterbeispiel
könntest Du Dir mal ansehen und herunter laden unter
http://www.nordcad.de/div/__stand060506.zip

Dabei handelt es ich um ein paar Screenshots
mit ein paar kommentaren. Man sieht hier in
erster Linie meine Tabellen aber eben auch
die <Anbindung,> wenn man es denn so nennen
kann, an Postgres.

Nicht wundern, es sind 11,1 MB

Für Verbesserungsvorschläge bin ich immer zu haben.

> > Wenn ich das Feld in der Tabelle dann als Text
> > definiere wird das Datum als Text eingefügt.
> > OK.

> Datumswerte werden immer zunächst als Text geparst,
> bevor sie entsprechend gespeichert werden, bspw:

> bernd(at)[local]:bernd #= CREATE TABLE date_test(myDate DATE);
> bernd(at)[local]:bernd #= INSERT INTO date_test VALUES ('21.01.2005');
> bernd(at)[local]:bernd #= INSERT INTO date_test VALUES ('16.04.2005');
> bernd(at)[local]:bernd #= select * from date_test ;
> mydate
> ------------
> 21.01.2005
> 16.04.2005
> (2 rows)

Nene....

ich inserte direkt aus den Tabellenfeldern.
Auch eben das errechnete Datum.

Folge: Ich muß CALC, sprich StarOffice erlauben mit
seinen internen Werten zu rechnen. Und damit lebe
ich eben mit dem internen Rechenwert, der mir in
der Tabelle als korrektes Datum angezeigt wird.

> Kommt sicher nicht von der Datenbank
Doch... glaube ich schon.

Starmoney macht das auch beim Export der
Daten in DBase- Tabellen, damit Zahlenwerte
als Text ohne automatische Formatierungen
dargestellt werden.

> > Wenn dieser Wert dann in die Tabelle zurück
> > importiert wird kann ich damit so ohne weiteres
> > nicht rechnen lassen.

> Mit Timestamp bzw Date lässt sich einfach rechnen,
> bspw:

> bernd(at)[local]:bernd #= select mydate + interval
> '1 month' from date_test ;
> ?column?
> ---------------------
> 21.02.2005 00:00:00
> 16.05.2005 00:00:00
> (2 rows)

> bernd(at)[local]:bernd #= select mydate - interval _
> '1 day' from date_test ;
> ?column?
> ---------------------
> 20.01.2005 00:00:00
> 15.04.2005 00:00:00
> (2 rows)

> Man muss nur wissen, dass das Resultat
> ein Timestamp ist (Datum + Zeit).

Hmmm....

Damit pflanzt Du mir greade die Idee ein,
das ich mit Date= 31.12.1899 + meine Werte
auch in der DB dann richtige Datumsangaben
vorhalten könnte....

> --
> Thanks

> Bernd

Mit freundlichen Grüßen

wW