Benutzer mit den meisten Antworten
SSRS - Abo - Datumsparameter Client deutsch - Server englisch - Änderung nicht möglich

Frage
-
Hallo,
habe mehrere Reports, welche von Usern per ABO als E-Mail täglich bekommen.
Problem ist, das die Reports variable Datumsauswahlen haben, diese beim ABO auf einen festen Wert eingestellt werden müssen.
Sobald ich einen Standardwert ändere von 5/16/2017 12:00:00 AM --> 5/20/2017 12:00:00 AM funktioniert der Bericht nicht mehr.
Thema wo ich denke das es ein "Feature" ist,
der Client ist deutsch, damit wird das Datum auch deutsch angezeigt,
der Server ist englisch, damit wird das Datum englisch angezeigt.Setz ein User an seinem Client das Datum auf einen festen Wert (wird er das deutsche Format nutzen)
Kommt es auf dem Server an, kann dieser nichts damit anfangen.
Ändere ich als Admin das Datum auf dem Server auf Standard ist alles gut.
Ändere ich dsa Datum wie oben im Bild dargestellt auf ein anderes englisches Datum gehts auch nicht mehr.
Ist doch irgendwie ganz schön nervig, das wir im 21. Jahrhundert dsa mit den Datumsfeldern immer noch nicht hinbekommen.
Danke
Martin
thx Martin
Antworten
-
Hallo an alle
gelinde gesagt ging mir das Teil wirklich auf den Senkel.
Habe die Parameter umgeändert, das ich in die Prozedur nur noch Strings übertrage (Format Befehl genutzt)
Dennoch selbes Fehlerbild.
Habe den Server auf Deutsch umgestellt und siehe da, es geht auf anhieb.
Kann dieses Problem nur nicht nachvollziehen, das es hier keine "einfache" Lösung gibt.
Alles auf Datumsfeld und die Systeme kommen damit nicht klar, weils andere Sprachen haben.
Danke Euchthx Martin
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Mittwoch, 31. Mai 2017 06:00
Alle Antworten
-
Hallo Martin,
setze in den Berichts-Eigenschaften unter Lokalisierung die Language auf "de-DE" und stelle den Bericht neu bereit.
Als Standardwert für solche Parameter verwende ich in der Regel einen Ausdruck, z B.
= DateAdd("d",-8,Today())
Dann entfällt die Notwendigkeit den Parameter täglich manuell zu ändern.
Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu
-
Wie trägst du das Datum in den SQL ein?
Das Problem ist sicherlich, dass du für die Abfrage das Datum als Textkonstante in den SQL einbettest.
Das ist natürlich sprachabhängig.
Um sprachneutral zu arbeiten, muss man entweder:
a) ein Datum als Parameter übergeben @MyDate
b) in der where-Klausel per Funktion convert in den Typ Date umwandeln
Bei b) kann man dann das Quellformat des Textes wiederum angeben.https://msdn.microsoft.com/de-de/library/ms187928.aspx?f=255&MSPPError=-2147217396 -
Hallo Christoph,
lokalisierung steht auf: =User!Languagesollte das nicht auch passen oder ist mit de-DE dann der Serverseitig auch deutsch eingestellt?
Standardwert ist selbstverständlich wie du beschreibst variable hinterlegt.
Für die nächsten 3 Wochen brauchen die den Bericht aber für einen exaten Zeitraum, das Datum darf sich also nicht ändern.
Danke
Maritn
thx Martin
-
Hallo bfurchau,
wenn man ein Abo erstellt, will er natürlich alle Parameter gefüllt haben.
Wir benutzen für so gut wie jeden Parameter default werte die genutzt warden, damit der User nicht viel machen muss.
wie beim Christoph beschrieben, muss ich in diesem Fall aber die Default Werte mit festen Werten überschreiben.Das Datum wird als Datumsfeld der Prozedur übergeben. Am Client werden diese auch deutsch angezeigt:
Mehr weis ich jetzt auch nicht was ich noch schreiben kann ;-)
Martin
thx Martin
-
"Das Datum wird als Datumsfeld der Prozedur übergeben"
Wie genau wird dieses gemacht?
Erfolgt die Übergabe tatsächlich als Typ Datum oder doch eher als Typ String (bzw. Zeichenklette)?
Gibt es ein Codesnippet, wie es denn gemacht wird?
Das Datumfeld selber liefert einen Wert vom Typ DateTime, das ist also nicht das Problem sondern irgendwo in der Schnittstelle zwischen Programm und Prozedur erfolgt eine Umwandlung als Zeichenkette.Wer stellt die Prozedur zur Verfügung und wie arbeitet diese?
Wie sind die sog. Parameter der Prozedur definiert? -
Hallo
Prozedur, welche der Report aufruft. Als Kommentar ein Beispiel an Feldern die übergeben werden.
ALTER PROCEDURE [dbo].[BEDARF_KUNDE_REPORT] --'1', '7521', ' 61', '06/01/2015', '06/30/2015', 'T', 0, 0
@firm as nvarchar(1), @kunde AS nvarchar(10), @venr as NVARCHAR(3), @datvon as date, @datbis as date, @basis as nvarchar(1), @pack as int, @gemein as int
ASin der Prozedur selbst wird das Datum in ein NVARCHAR feld konvertiert
SET @datvon_str=CONVERT(NVARCHAR(12), @datvon, 112)Wenn man den Report mit dem Browser öffnet un dParameter mitgibt, gibt es auch keinerlei Probleme, der Report funktioniert einwandfrei.
DAs Problem besteht nur bei einer Subscription, das er damit einfach nicht klar kommt.
thx Martin
-
"SET @datvon_str=CONVERT(NVARCHAR(12), @datvon, 112)"
Warum wird dies gemacht?
Wenn das Feld doch als Date erwartet wird, sollte man nicht in eine Zeichenkette konvertieren!
SQL will dann nämlich die Zeichenkette wieder in ein DateTime zurückwandeln.Wenn deine Scriptsprache es unterstützt, solltest du eben ein Date-Feld statt einer Zeichenkette übergeben.
Ansonten sollte das ISO-Format (JJJJ-MM-TT) beim Convert eigentlich immer funktionieren.
-
Nun ja, 1/1/2017 ist ja insoweit eindeutig.
Versuche mal 15/2/2017 (Deutsch), das ist was anderes als 2/15/2017 (EN-US).Wenn also in der DB das Feld als JJJJMMTT (numerisch oder Char) gespeichert ist, solltest du die Prozedur auf dasselbe Format definieren und bereitstellen.
Dies passiert aber nicht innerhalb der Prozedur sondern muss beim Aufruf der Prozedur erfolgen.
- Bearbeitet Der Suchende Dienstag, 16. Mai 2017 12:57
-
Hi
Versuche mal 15/2/2017 (Deutsch), das ist was anderes als 2/15/2017 (EN-US).
das läst er nicht zu. Das hatte ich auch schon getestet. Ich habe aber das Gefühl, das bei der eingabe des Paramters, die Prozedur noch gar nicht involviert ist.
Echt komisch.
Keine Ahnung was ich noch machen kann.
thx Martin
-
Das ist korrekt. Also muss doch Scriptmäßig noch was anderes passieren.
Noch mal meine Frage:
Wie und wo rufst du die Prozedur auf, also wie kommt die Verknüpfung zwischen Eingabefeld und Prozeduraufruf zu stande?
Hier musst du ansetzen und den Inhalt als Datum bereitstellen. -
Hallo,
Prozeduraufruf kommt durch die DataSets im Report zu stande, welche Parameter beinhalten.
hier mal ein Bild vom SSRS Berichtsmanager
Serververbindung-Datenbank: DSAuswertungen
Prozedur aus der Datenbank: BEDARF_KUNDE_REPORT
Dieser Stored Prozedure muss ich die Parameter (links oben) übergeben.
Der Parameter @datvon ist beispiel so definiert:
Kann man eine bestimmte Collation nutzen, die für ein DAtumsfeld immer gleich sind, egal welche Sprache?
dankethx Martin
-
Das scheint soweit alles zu passen.
Dann konzentrieren wir uns wieder auf die Prozedur selber, denn der Convert scheint ja zu funktionieren, da dies keinen Fehler gibt.Da du auf jeden Fall ein Datum in JJJJMMTT benötigst, verwende statt convert die Format-Anweisung:
Format(MyDate, 'jjjjMMdd')
Näheres siehe hier: https://msdn.microsoft.com/de-de/library/hh213505.aspx
Das Ergebnis sollte dann für deine Datenbank passen, könnte also ggf. auch noch in number/decimal usw. konvertiert werden. -
Guten morgen
das werde ich jetzt mal testen, wobei ich immer noch glaube, das die Prozedur nicht das Thema sein kann, da "date" in der Prozedur mit beiden Datumsformaten deutsch/English umgehen kann.
Der Parameter in der Subscription hat aber das Problem, das ich nicht deutsch oder englisch eintragen kann, sondern nur die Sprache in der der Rechner läuft.
Aber ich versuche das mit dem Format trotzdem, den was neues ausprobieren tu ich gerne :-D
thx Martin
-
Hallo an alle
gelinde gesagt ging mir das Teil wirklich auf den Senkel.
Habe die Parameter umgeändert, das ich in die Prozedur nur noch Strings übertrage (Format Befehl genutzt)
Dennoch selbes Fehlerbild.
Habe den Server auf Deutsch umgestellt und siehe da, es geht auf anhieb.
Kann dieses Problem nur nicht nachvollziehen, das es hier keine "einfache" Lösung gibt.
Alles auf Datumsfeld und die Systeme kommen damit nicht klar, weils andere Sprachen haben.
Danke Euchthx Martin
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Mittwoch, 31. Mai 2017 06:00