OpenOffice.info

Ich kann zum Thema Timestamp Entwarnung geben (LO 4.2, MySql Server 5.6, MySql Connector 1.0.2)
Alle meine Datumsroutinen arbeiten einwandfrei, die Timestamps sind stimmig und richtig formatiert.
Gruss,
WSO

Hi Robert,
danke fuer den Hinweis, ich werde das testen.
Timestamp-Felder verwende ich, sie haben aber keinen Einfluss auf die Datenintegrität.
Bei Datumsfeldern gäbe es schon Probleme ...
Melde mich die Tage dazu, wenn ich schlauer bin.
Habe derzeit nur eingeschränkt Zeit.
Gruss, Wolfram

Hallo Wolfram,

ich habe nachgefragt, weil ich davon ausgehe, dass es keinen komplett funktionierenden Connector außer für manche Linux-Distributionen gibt. Ich zitiere wieder einmal aus dem Handbuch:
[quote]Ein Kontakt zu LO 4.1.* kommt zwar mit dem AOO-Connector zustande, aber da
sich ab der Version LO 4.1 die Beschreibung der Sekundenbruchteile von LO und
AOO unterscheiden, werden falsche Werte im Bereich der Zeiten und auch von
kompletten Timestamp-Feldern angezeigt.
Verwenden sie also bitte immer die Version, die lt. Beschreibung auch zur LO-
Version passt. Achten sie besonders beim Wechsel auf LO 4.1 darauf, ob überhaupt
ein entsprechender Connector zur Verfügung steht.
[/quote]

Ich hoffe, dass Du keine Timestamp-Felder verwendest. Vielleicht macht auch das Datum Probleme. Das weiß ich nicht aus dem Stand.

Gruß

Robert

Hi Robert,
ja ich nutze LO 4.2 (win 7) mit dem Mysql-Connector 1.0.2.
Ich erinnere mich nicht, wo ich das Plugin runtergeladen habe.
Hier ist es:
https://www.dropbox.com/s/ss98o67jbvt2yi4/mysql-connector-ooo.oxt
Funktioniert bislang gut, Performance ist super.
Das Problem mit dem ungültigen Feldnamen beim kopieren der Tabellen hat sich geklärt:
In der HSQL-Tabelle hatte ein Feldname als letztes Zeichen ein blank.
War unter HSQL nie aufgefallen, MySql hat das verständlicherweise nicht gefallen.
Gruss,
Wolfram

Hallo Wolfram,

welche direkte Verbindung nutzt Du? Du hast die Version LO 4.2, richtig? Wenn ich auf die Extensions-Liste sehe, dann kann ich dort nur einen Connector für Linux rpm und die Version 4.0 entdecken:
[url]http://extensions.libreoffice.org/extension-center/mysql-native-connector/releases/1.0[/url]

Gruß

Robert

stSql_ZAE = "SELECT * FROM  tZaehler WHERE zae_id = 0 "
stSql_ZAEUPD = "UPDATE  tZaehler SET zae_rechnung = " & iZaehler

Hi Robert,
ich teste gerade die direkte Verbindung zu MySql und die Portierung meiner Anwendung.
Der Aufwand ist geringer als gedacht, insbesondere was die Makros betrifft.

Tabellen können der drag and drop übertragen werden, wobei im Namen auch der Datenbankname vorangestellt werden muss.
Die Funktion hat noch einige "Macken" bei der Feldtypzuordnung (timestamp, boolean und varchar > 255).

Views müssen von Hand neu angelegt werden, wobei die SQL-Syntax per copy und paste übernommen werden kann.

Queries können ohne weiteren manuellen Eingriff per drag and drop kopiert werden.

Formulare: per drag and drop kopieren.
Die Datenquellen (sofern es Tabellen sind) müssen neu zugeordnet werden. (dbname vorangestellt)
Bezieht das Formular die Daten aus queries oder views sind keine Anpassungen erforderlich.

Makros: Die SQL-Syntax ist wesentlich einfacher als vermutet:
Es ist nicht erforderlich auf den Namen der Datenbak zu referenzieren und auf das "gefuddel" mit den Anführungszeichen kann gänzlich verzichtet werden, z.B.:
[code]
stSql_ZAE = "SELECT * FROM tZaehler WHERE zae_id = 0 "
stSql_ZAEUPD = "UPDATE tZaehler SET zae_rechnung = " & iZaehler
[/code]
funktioniert einwandfrei!
Gruss,
Wolfram

FROM "Tabelle" ...

FROM `Datenbank`.`Tabelle` AS `Tabelle` ...

Hallo WSO,

ich kann in MySQL nicht mit dem direkten Treiber testen - habe dafür keinen Treiber zur Verfügung. Unter JDBC-Verbindung ist dort aber auf jeden Fall mehr an Eingriffen notwendig als bei PostgreSQL.

Aus
[code]FROM "Tabelle" ...[/code]
wird dort
[code]FROM `Datenbank`.`Tabelle` AS `Tabelle` ...[/code]

Alle Feldnamen werden statt in doppelten Anführungszeichen in «`» eingefasst.
Das scheint mir dann doch deutlich mehr Aufwand zu sein.

Gruß

Robert

ups, das ist ja noch richtig Arbeit.
Ist der Aufwand bei Verwendung von MySQL auch so gross?
Könnte auch auf MySQL gehen.
Gruss,
WSO

FROM "Tabelle" ...

FROM "public"."Tabelle" AS "Tabelle" ...

Hallo WSO,

[quote="WSO"]
Was muss alles nach PostgeSql rüber:
- Tabellen, klar
- Views ?
- Queries ?

Sind Anpassungen an der SQL-Syntax in den Makos notwendig?
[/quote]

Du musst die Ansichten und Abfragen anpassen. Allein schon in dem Punkt, dass dort nirgendwo
[code]FROM "Tabelle" ...[/code]
steht sondern
[code]FROM "public"."Tabelle" AS "Tabelle" ...[/code]
Mit der Aliaszuweisung machst Du es möglich, dass Du nicht bei allen Feldern neben dem Tabellennamen auch "public." hinzufügen musst.

Ich würde das folgendermaßen regeln:
SQL-Code der Ansicht kopieren, in der PostgreSQL-Datenbank "Abfrage in SQL-Ansicht erstellen" wählen und dann die notwendigen Änderungen bei der Tabellenbezeichnung durchführen. Fange mit den Ansichten an, und dort dann auch mit einer Ansicht, die sich nicht auch noch auf eine andere Ansicht bezieht.

Gruß

Robert

Hi Robert,
genau so :D
Danke, mal wieder ne Hürde weiter ...
Dann lege ich mal los.
Was muss alles nach PostgeSql rüber:
- Tabellen, klar
- Views ?
- Queries ?

Sind Anpassungen an der SQL-Syntax in den Makos notwendig?
Gruss,
WSO

Hallo WSO,

Du hast also erst einmal testweise probiert, ob sich überhaupt Tabellen in "public" anlegen lassen? Das klappt mit Erfolg, dort lassen sich auch Daten eingeben? So verstehe ich jedenfalls
[quote]Eine neue Tabelle läßt sich problemlos im Verzeichnis "public" manuell anlegen.[/quote]
Jetzt versuchst Du die gleiche Methode mit einer kopierten Tabelle und die Kopie wird ohne Kommentar nicht ausgeführt?
Ich habe gerade auch noch einmal probiert und erst einmal gestaunt. Du musst vor den vorgeschlagenen Tabellennamen ein "public." einfügen. Dann kommt die Tabelle auch in dem Unterordner "public" zum Vorschein.

Gruß

Robert

Hi Robert,
soweit verstanden, aber das System verhält sich merkwürdig:
Eine neue Tabelle läßt sich problemlos im Verzeichnis "public" manuell anlegen.
Per copy/paste startet ein Assistent, die Feldtypen lassen sich anpassen,
aber die einzufügende Tabelle wird [color=#BF0000]nicht gespeichert[/color].
Das passiert unabhängig davon, ob ich die einzelnen Schritte des Assistenten durchlaufe, oder
direkt auf "fertigstellen" klicke.
Guss,
WSO

Hallo WSO,

die Tabellen in PostgreSQL gehören in das Tabellenverzeichnis "public".
Markiere die Tabelle, die Du kopieren willst. Rechte Maustaste über der Tabelle → kopieren.
Öffne in PostgreSQL den Ordner "public".
Rechte Maustaste auf "public" → Einfügen.
Dann dem Assistenten folgen und die entsprechenden Feldbezeichnungen abgleichen.
Aus dem Handbuch:
[quote]Bei der Erstellung von Tabellen kann es vorkommen, dass Base Datentypen vorschlägt, die die
aktuelle PostgreSQL-Installation nicht verarbeiten kann. So werden standardmäßig die Felder mit
dem Feldtyp «Text [character_data]» vorgeschlagen. Den kann PostgreSQL aber nicht verarbeiten.
Eine Änderung auf den Typ «Text [varchar]» schafft hier Abhilfe.
[/quote]

Gruß

Robert

Hallo Robert,
danke sieht einfach aus, komme aber nicht ganz zum Ziel.
Habe jetzt 2 Datenbanken:

eine leere in Postgre:
[attachment=1]pic0.png[/attachment]

und die HSQLDB mit den zu übertragenden Tabellen:
[attachment=0]pic1.png[/attachment]

Und jetzt ?
Wie bekomme ich denn den Datenbank-Container zum paste da rein?

Gruss,
WSO

Hallo WSO,

warum willst Du die Datenbanken mit einem anderen Programm öffnen? Du hast doch Base. Darin kannst Du beide Datenbanken lesen und beschreiben. Rechter Mausklick über einer Tabelle, kopieren. Rechter Mausklick über dem Tabellencontainer von PostgreSQL, einfügen. Gegebenenfalls genauer auf die Feldtypen achten - siehe Handbuch.

Gruß

Robert