Oracle sql eclipse birt

[StephanH]

Hallo liebe Entwicklergemeinde,

ich habe ein Problem mit SYSDATE. Ein im SQL-Developer geschriebenes Script läuft einwandfrei. Übertrage ich es in Eclipse/Birt und lasse es direkt aus dieser Umgebung laufen, läuft es auch einwandfrei. Schiebe ich das Script bzw. den .rptdesign dann in die Webumgebung, werden die auf SYSDATE basierenden Daten verschoben.
Hintergrund ist, ich möchte Dinge immer bezogen auf das letzte Wochenende ausgeben, also brauche ich eine Routine, die unabhängig vom aktuellen Tag, mich abfragetechnisch immer am letzten Freitag absetzt.
Der fragliche Ausschnitt sieht folgendermaßen aus:

and 
(
  ( 
    (to_char(xtime, 'D') in '5')
    and (to_char(xtime, 'hh24') >= '18')
   )
  or
    (to_char(xtime, 'D') in '6' and (xtime < SYSDATE -2))
  or
    ((to_char(xtime, 'D') in '7' ) and (to_char(xtime, 'hh24:mi') <='23:59'))
  or
    ((to_char(xtime, 'D') in '1' ) and (to_char(xtime,'hh24:mi') <= '06:00'))
)
and xtime between sysdate -(
  case
    when to_char sysdate, 'D') in ('5', '6, '7') then 10
    else 7
    end)
    and sysdate -(
  case
    when th_char(sysdate, 'D') in ('5', '6', '7') then 3
    else 0
    end)

Diese Script bzw. dieser Teil soll nichts weiter tun, als mir die Dinge auszugeben, die Freitags ab 18 Uhr bis Monatgs 06 Uhr in die Datenbank eingegeben worden sind.
Im Developer und in der Eclipse/Birt Umgebung funktioniert das einwandfrei.
Bezogen auf das letzte Wochenende heißt dies, korrekte Abfrage wäre von Fr. 18:00 Uhr bis Montag (06:00 uhr). Über das Web wird der Freitag auf den 12.01. gesetzt, Samstag auf den 13.01. Sontag entsprechend auf den 14.01 und heute ist dann der 15:01.

Die Wochentage sind also korrekt ausgegeben, aber einem falschen Datum zugeordnet. Bei Abfragen, die sich auf ein konkretes Datum beziehen, erfolgt die Abfrage korrekt.

Kennt jemand dieses Phänomen und kann mir bitte sagen, wie man dem begegnet? Oder hat jemand eine sinnige Vermutung?

Grüße,
Stephan

[Wernfried]

Mal abgesehen von ein paar Tippfehlern liegt das Problem vermutlich hier:

to_char(sysdate, 'D')

'D' gibt den Tag der Woche zurück aber der Wochenanfang wird durch das NLS_TERRITORY bestimmt. In Deutschland ist Montag der erste Tag der Woche, in den USA ist es der Sonntag.


Entweder du machst vor deinem Code

ALTER SESSION SET NLS_TERRITORY = 'GERMANY';

bzw.

DBMS_SESSION.SET_NLS('NLS_TERRITORY', '"GERMANY"');

oder du gehst über den Wochentag

TO_CHAR(sysdate, 'fmDy', 'NLS_DATE_LANGUAGE = GERMAN') in ('Fr','Sa','So')

Evtl. geht es auch viel einfacher wenn du die Funktion NEXT_DAY nimmst, z.B. :

NEXT_DAY(SYSDATE, 'Friday')

Gruss

[defo]

Ergänzend zu Wernfried möchte ich Dir noch raten, das gesamte System gegen diese Territory Geschichte zu prüfen.
Implizite Datumkonvertierung bspw. kann so nach hinten losgehen.
Ziemlich sicher arbeitet Dein Entwicklungssystem (Testserver) und das Produktivsystem mit unterschiedlichen Einstellungen und das ist Grundlage für die unterschiedlichen Ergebnisse. Dein Code ist Teil 2 des Problems, er arbeitet in Abhängigkeiten zu diesen NLS Settings und produziert dadurch unterschiedliche Ergebnisse, je nach Einstellung.
Sind alle Umgebungen gleich eingestellt, fällt das Problem nicht auf. Bei Dir "knallt" es.

[StephanH]

Hallo Wernfried, hallo defo,

sorry, wenn es etwas länger gedauert hat, bis ich mich hier wieder melde.
Ja, die lieben Tippfehler. Liegt halt daran, daß ich auf zwei voneinander abgeschotteten Systemen arbeite und die Guttenberg-Tastatur nicht funktioniert. Hätte mir zwar ne eMail schicken können, aber bei den paar Zeilen hielt ich das nicht für nötig. Daher die Tippfehler.

Da Wernfried reichlich Lösungen angeboten hatte, habe ich mich für

TO_CHAR(sysdate, 'fmDy', 'NLS_DATE_LANGUAGE = GERMAN') in ('Fr','Sa','So')

entschieden. Es lief auf Anhieb.
Das wiederum spricht auch für defo's These, das es hier an den Einstellungen der Systeme mangelt.
Mein Problem ist, die Umgebung wird benutzt "as it is" sprich, sie wurde eingerichtet und fertig. Admin-Rechte sind schon gar keine vorhanden. An den vorhandenen Installationen herumzubasteln oder basteln zu lassen, ist schon gar nicht, das gibt das Budget nicht her. Außerdem stellt man sich auf den Standpunkt, die Installation stimmt und es gibt keinen Grund da was zu ändern.
Ich sehe förmlich euer Kopfaschütteln und kann euch auch da nur beipflichten...

Wie dem auch sei, man versucht, aus der Not eine Tugend zu machen und wenn gar nichts mehr geht, kann man sich hier im Forum auf gute Leute mit fundierten Kenntnissen verlassen, die einen wieder in die Spur bringen.
Jetzt, wo ich weiß, wie man diesem Fehler begegnen kann, kann man ihn zukünftig vermeiden. Dokumentation ist halt alles.

Vielen Dank euch!

Grüße,
Stephan

[defo]

Schön, dass Du Dich noch mal dazu meldest.

Eine Sache noch mal zur Verdeutlichung.
Es "mangelt nicht an der Einstellung", es gibt genug und zwar verschiedene. Das ist nicht ungewöhnlich, wenn man von einem Entwicklersystem auf die Produktion wechselt.
Damit kann man nun unterschiedlich umgehen, z.B. die Einstellungen angleichen oder aber einstellungungsunabhängig implementieren.
Mit dem angleichen bist Du nicht durch gekommen, auch das ist nicht ungewöhnlich. Ein Produktionssystem wird nicht ohne weiteres an die Wünsche eines Entwicklers angepasst. Eine flexible Implementierung, hier eine Implementierung, die eine saubere / wasserdichte Datumskonvertierung macht, indem alle benötigten Parameter in sich stimmig mitgegeben werden, ist der beste Weg.

[fanderlf]

Da muss ich Defo recht geben. Dein Fehler hätte mit Code verhindert werden können und auf das Serverdatum sollte man sich grundsätzlich NIE verlassen. Ich weiß z.B. dass wir in der Arbeit einen Timeserver haben, der die Uhrzeit auf allen Server regelt. Trotzdem graut es mir immer davor, wenn ich Code bauen muss der sich darauf verlässt. Ländereinstellungen wie Dein Problem sind fast noch schlimmer. Wenn Du es im Code selbst regeln kannst, dann verlass Dich NIE drauf, dass auf dem Server irgendwelche bestimmten Settings vorhanden sind. Falls Du Dich doch drauf verlassen musst, dann stelle wenigstens irgendwie sicher, dass das richtige eingestellt ist und ggfs. kannst Du dann auch im Code eine Exception werfen falls dem nicht so ist.

[StephanH]

"Du kannst alt werden wie 'ne Kuh, lernst immer noch dazu" oder "Lerne aus den Fehlern Anderer, du lebst nicht lange genug, sie alle selbst zu begehen"...
Was ich aus dieser Sache mitnehme, ist, daß man nichts als gegeben voraussetzen darf, sondern für die Voraussetzungen selbst sorgen muß, um unliebsame Überraschungen (wie diese) zu vermeiden.
Ich habe hier zumindest alles, was momentan auf BIRT läuft entsprechend umgestellt und eine Info hinterlassen, warum es in den Code eingebaut wurde. So banal der Hintergrund ist, so weitreichend seine Folgen.
An dieser Stelle darf ich mal ausdrücklich positiv betonen, wie sachlich und informativ in diesem Forum miteinander umgegangen wird.

Daher nochmals meinen Dank!

Grüße,
Stephan