Neu: SQL-Felder in OpenOffice-Vorlagen

[marlovitsh]

Neu ist es nun möglich (ab Version 2), in einer Office-Vorlage eine direkte SQL-Abfrage auf die Datenbank im Dokument einzubinden.
Damit können nun jegliche Daten aus der Datenbank in jeglicher Formatierung dargestellt werden.

Der Platzhalter für diese SQL-Felder sind ebenfalls in eckige Klammern gesetzt

Format des Platzhalters, drei Varianten:

[SQL:<Hier kommt die SQL-Abfrage hin>]
[SQL|<FeldTrenner>:<Hier kommt die SQL-Abfrage hin>]
[SQL|<FeldTrenner>|<DatensatzTrenner>:<Hier kommt die SQL-Abfrage hin>]

Die Feldtrenner können beliebige Strings sein.
Wird kein FeldTrenner respektive kein DatensatzTrenner angegeben, so werden folgende Defaults verwendet:

für FeldTrenner: Tab \t
für DatensatzTrenner: newLine \n

In den Trennern können die escape characters \n (newline), \r (return), \t (Tabulator), \f (formfeed), \b (backspace) verwendet werden.
Octal-Escapes werden zur Zeit nicht unterstützt.

In der SQL-Abfrage können alle üblichen direkten und indirekten Platzhalter verwendet werden,
zBsp [Patient.ID] oder [Fall.ID], [Mandant.Vorname], [Konsultation.Datum] etc.
Diese werden zuerst ersetzt. Danach wird die eigentliche SQL-Abfrage durchgeführt, so dass in der Abfrage die aktuellen IDs verwendet werden können.

Um die im Datenbankfeld "ExtInfo" gespeichterten Daten abzurufen, ist die folgende Hilfssyntax als Feldabfrage vorgesehen:
extinfo:<TabellenName>.<FeldNameInnerhalbDerHashtableAusDerExtinfo>
Bsp: extinfo:KONTAKT:Beruf
Das Feld Beruf wurde in den Einstellungen "Zusatzfelder in Patient-Detail-Blatt" definiert


Auf diese Weise lässt sich so ziemlich alles in ziemlich jeglicher Form zur Darstellung extrahieren - der Phantasie sind eigentlich keine Grenzen gesetzt.


Beispiele:
Abfrage:
[SQL:select chr(9) || prozent || '%', to_char(to_date(datumvon, 'yyyymmdd'), 'dd.mm.yyyy'), '-',
to_char(to_date(datumbis, 'yyyymmdd'), 'dd.mm.yyyy') from auf where fallid='[Fall.ID]']
Resultat:
100% 01.01.2010 - 07.01.2010
50% 08.01.2010 - 15.01.2010

Abfrage:
[SQL|_\t_|\n%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%\n:
select extinfo:KONTAKT.Beruf, extinfo:KONTAKT.Ledigname, Bezeichnung1, Bezeichnung2
from KONTAKT where id ='[Patient.ID]' or id='1029']
Resultat:
Schreiner_ _Bünzli_ _Hagenmüller_ _Margrit
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Lehrer_ _Germann_ _Marlovits_ _Annegret


Viel Vergnügen!
Gruss an alle, Harry

[marlovitsh]

Ach ja - Änderungsabfragen jeglicher Art sind hier nicht möglich.

Noch n Gruss

[gweirich]

Das finde ich eine äusserst brauchbare Erweiterung, auch wenn whs. nicht jeder spontan was damit anfangen kann. Aber da die SQL-Statements ja einfach per cut&paste übernommen werden können, können wir uns ja eggenseitig helfen. Zum Beispiel die vielgewünschte Möglichkeit, die Krankenkasse als Feld auszugeben, müsste mit einer Konstruktion wie etwa dieser machbar sein (wenn der aktuelle Fall markiert ist):

[SQL:select k.bezeichnung1 from KONTAKT as k, FAELLE as f where k.ID=f.GarantID and f.ID='[Fall.ID]'];

Herzlichen Dank!

Gerry

[ursberner]

bis jetzt kann ich die obigen Beispiele nicht nachbauen. Welche Voraussetzungen müssen dazu erfüllt sein? Dass damit spannende neue Möglichkeiten existieren, ist für mich ganz toll. Danke

[gweirich]

Sollte eigentlich ohne weitere Voraussetzungen mit dem aktuellen update von elexis 2.0 gehen.
Ich würde erstmal was ganz einfaches probieren wie

[SQL:select Bezeichnung1 from KONTAKT WHERE ID='[Patient.ID]']

Das müsste einfach den Namen des aktuell markierten Patienten ausgeben, also dasselbe wie [Patient.Name]

Wenn das nicht geht, dann scheint was Grundsätzliches nicht zu klappen, dann müsste man im Logfile schauen.

[ursberner]

java.sql.SQLException
FEHLER: Wert zu lang für Typ character varying(25)
22001
19.02.2010, 12:57:59 |ERROR| - PersistentObject: Fehler bei UPDATE LOGS SET OID=?,datum=?,typ=?,userID=?,station=?,lastupdate=? WHERE ID='Wb6970ae670c21625394879'
Felder:
OID=ch.elexis.data.Brief::Jbca574d7f49f6136113143
Datum=19.02.2010
typ=DELETE
userID=a8ebc5f1fac4b22f2a56
station=fe80:0:0:0:d12b:19c5:70cd:2d87%11

hilft dies weiter?

[gweirich]

hilft dies weiter?

Jein. Deine Postgresql-Datenbank hat ein update nicht mitgekriegt, deshalb kommt die Logtabelle nicht mit IPV6-Adressen zurecht. Ändere die Länge des Feldes "station" in der Tabelle "Logs" manuell auf Varchar(40).

Das ist allerdings nicht das Problem, um das es hier geht, sondern dieser Fehler ist beim Löschen eines Briefs aufgetreten (typ=DELETE).

[marlovitsh]

Läuft es jetzt denn?

Gruss, Harry

[ursberner]

ich habe noch keine Zeit gefunden, den Server upzudaten so, dass ich auf Postgresql 8.4 umstellen kann. Werde mich anschliessend melden.

[ursberner]

Liebe[Adressat:mwn:r [Adressat.Vorname]/ [Adressat.Vorname]/ Damen und Herren]
gibt mir wie immer und wie gewünscht entweder den weiblichen oder den männlichen Vornamen.

nach einer Korrektur gibt
Sehr [Adressat:mwn:geehrter Herr [Adressat.Name]/geehrte Frau [Adressat.Name]/geehrte
Damen und Herren]
alle 3 Varianten Herr NAME/Frau NAME/geehrte Damen und Herren gleichzeitig aus.

ich sehe meinen Fehler nicht. Wer sieht in stattdessen ? Vielen Dank

[marlovitsh]

Der Fehler ist mir nicht unmittelbar ersichtlich - scheint ja alles gut zu sein.
Ich habe das Teil bei mir reinkopiert-und es ging NICHT.
Ich habe mal einfach das Ganze abgeschrieben - und - es läuft ALLES.

Kann es sein, dass ein Return oder ein Linbreak oder so etwas reingerutscht ist? Das schluckt der Matcher nämlich nicht.

Gruss, Harry

[ursberner]

ich habe nochmals alles abgetippt. Sowohl bei m wie w wie n kommen alle 3 Varianten: Sehr [Adressat:wmn: geehrter Herr xy/Frau xy/ geehrte Damen und Herren]

das ganze auf Postgresql. Und eine Variante mit Du klappt. Im Moment sehe ich nicht durch

[ursberner]

ok, gelöst. Ich habe die DU-Variante abgeändert und mit Sichern als gespeichert. Ev. hat sich irgendwo im vorherigen Dokument ein Käfer versteckt. Jetzt gehts wieder. Danke