Jein,

Between macht

a≤ x ≤b

was dann zu zwei Treffern führt. Daher besser wie beschrieben

a≤ x <b

Nennt sich rechtsoffens Intervall und hat den Vorteil, dass man eine nahtlose Kette von Gültigkeiten erhält. Wenn bis des Vorgängers ungleich von des Nachfolgers sein soll (wie bei BETWEEN nötig) muss man die kleinstmögliche Differenz der beiden Werte kennen (Zeitatom), und das kann sich durchaus mal ändern, wenn der DB-Hersteller eine neue Version auf den Markt bringt, oder man die Datenbank wechselt.

Bzgl. des setzens des Zeitstempel_bis hast Du das natürlich richtig verstanden.

Gruß
f_igy

Hi,

Dein Problem liegt m.E. darin, dass Du statt Zeiträumen nur Zeitpunkte hast. Entweder Du füllst Deine Tabelle schon mit Zeitstempel_von und Zeitstempel_bis, oder aber du musst das im SQL mit eínem (oft langsamen) Subselect und nachfolgender nested Table Expression machen.

Etwa so:

SELECT *
FROM ( SELECT Kabine
, Zeitstempel as Zeitstempel_von
, (select min(Zeitstempel) from Kabine T2 where T1.Kabine = T2.Kabine and T1.Zeitstempel < T2.Zeitstempel) AS Zeitstempel_bis
, Farbe
from Kabine T1
) KABI
JOIN Zeitstempel ZEIT
ON ZEIT.Zeitstempel ≥ KABI.Zeitstempel_von
AND ZEIT.Zeitstempel < KABI.Zeitstempel_bis

Das ist zwar wahrscheinlich auch nicht sonderlich perfomant, spart aber das GROUP BY und das große Zwischenergbnis im JOIN.

Ach ja: Evtl. Index Kabine ASC (od. DESC) , Zeitstempel DESC auf Kabine

Hi,

kann es sein, das der Fehler bei Deinem Parameter liegt? Welches Format hat denn das Tabellenfeld S1?

Gruß
f_igy

Hi,

das ganze dauert so lange, weil da Du für jedes einzelne Element eine eigene DB-Verbindung aufbaust (Overhead Verbindungsaufbau), dann einzelne Datensätze abfragst (synchrone SQLs), das SQL nicht per Parameter Variabilisierst (Schlecht für den Optimizer) und alle Spalten selektierst, auch wenn Du möglicherweise nicht alle brauchst (verhindert Index-only Zugriffe).

Falls dt auch aus der gleichen Datenbank kommt solltest Du die Tabellen am besten Joinen (geht z.B. auch mit einer View, aber auch ohne). Wenn nicht kannst Du auch alle Daten aus der Tabelle in eine DataTable laden und per Linq Joinen.

Allerdings halte ich die Schleife auch für etwas komisch; Jede Datarow r bekommt nacheinander die Werte aller Rows von dr zugewiesen! Der Sinn erschließt sich mir nicht. Sollten nicht die für jede Row von dr eine neue Row von r erzeugt werden (eben ein inner join)?

Gruß
f-igy

Stimmt,

mit dem Reportgenerator erlebt man schon mal 'ne Überraschung wie Speicherüberläufe und eine Rakete ist das Ding auch nicht grade...

Gruß
f_igy

Hm,

vielleicht ist es am einfachsten die Objekte in eine denormalisierte DataTable zu schreiben, d.h. übere alle Hersteller, Modelle und SpritTypen zu iterieren und dann für jeden Durchlauf eine Row mit allen Attributen zu schreiben. Damit kann der Reportvierwer dann was anfangen und Du must dich nicht mit dem generieren von Layout und PDF herumägern.

Gruß
f_igy

Hi,

warum nimmst Du nicht die Reporting Komponente von Visual Studio. Die ist m.E. etwas mächtiger als Crystal, mit RDLC kann man Berichte auf Datasets und Objekte erzeugen, aber ggf. auch gegen SQL-Server (bzw. andere DBs)

Mein Buch-Tipp:

Datenbank-Programmierung mit Visual C# 2010
Grundlagen, Rezepte, Anwendungsbeispiele
Auf CD: Beispiel-Code für Visual Studio 2010 und dieses Buch als eBook-Version.
1426 Seiten (Hardcover)
inkl. 1 CD-ROM PC
erschienen 11/2010 bei Microsoft-Press
ISBN-13: 978-3-86645-446-0

s.A:

Reporting – Suche gutes Buch

Un ein paar Links:
http://www.gotreportviewer.com/
ReportViewer-Steuerelemente (Visual Studio): Beispiele und Anleitungen
SQL Server 2008 R2 Report Builder 3.0
ReportBuilder: Page Layout and Rendering (Report Builder 3.0 and SSRS)
LocalReport-Klasse
Microsoft.Reporting.WinForms-Namespace

Hallo,

ich schließe mich mal der Selbsthilfgruppe an. Auch ich hatte das Problem mit den Unterberichten. Da meine Reports aber teileweise über 10.000 Seiten hatten und jeder Unterbericht ein neues Dataset aufmacht kamen dann noch Speicherprobleme dazu.

Lange Rede schwacher Sinn: ich habe auf Unterberichte verzichtet und mehrere neue Einzelberichte gemacht, auch wenn ich dadruch mehre Pflegeaufwand habe.

Offenbar ist sind Unterberichte entweder nicht ganz fehlerfrei umgesetzt, oder so schwer zu benutzen, dass ich es nicht hinbekommen habe.

Gruß
f_igy

Hi,

probier mal

SELECT MAX(ID) FROM tbl_Tabelle

und leg eine Index auf die ID (ist ja für uniquness eh ganz gut). Viele DB-Systeme werten dann nur noch den letzten Index-Eintrag aus, was in aller Regel sehr schnell geht.

Vergleichen musst Du dann natürlich im Code...

Gruß
f-igy

Hi,

analog zu SQL bietet Linq auch eine "Except" Methode, mit der man die Unterschiede zweier Listen erhält. Könnte auch eine Lösung sein, wenn man keinen Timestamp zur Abgrenzung hat.

http://msdn.microsoft.com/en-us/library/bb397894.aspx

Gruß
Jens

Beim Hinzufügen eines Datasets als eingebettete Ressource in Form einer gzip komprimierten xml-Datei bin ich auf zahlreiche kleine Probleme gestoßen, deren Umschiffung ich kurz erläutern will.

1. Erstellen der komprimierten Datei:

Zuerst fülle ich einem anderen Projekt ein Dataset aus eine Datenbank und schreibe es dann als kompriemierte xml Datei. Dabei ist des Problem, dass solange der gzipStream noch offen ist die Kompression nich beendet werden kann. Da ein Close auch den FileStream schließt muss man die (wie ich finde recht unauffällige) Option „leaveOpen“ setzen. Ich habe im Netz diverse Lösung mit Byte Arrays gesehen, was m.E. unnötiger Aufwand ist und die Lesbarkeit reduziert.

//Der GZipStream muss durch Dispose() mitgeteilt bekommen, dass der zu komprimierende Datenstrom zu Ende ist. 
//Damit der von ihm abhängige Stream nicht auch geschlossen wird muss die Eigenschaft "leaveOpen" true sein.
FileStream fi = new FileStream(dlg.FileName + @".gzip", System.IO.FileMode.Create);
using (GZipStream dStr = new GZipStream(fi, CompressionMode.Compress, true))
{
    ds.WriteXml(dStr, XmlWriteMode.WriteSchema);
}
fi.Flush(true);

Erhellend war: BCL Blog: Using a MemoryStream with GZipStream [Lakshan Fernando]

2. Einlesen der Datei:

Zum einfügen der Ressource muss man im Projektmappen Explorer mit rechter Maustaste, „hinzufügen vorhandenes Element“ auswählen. ++Was ich aber lange gesucht habe war der Hinweis, dass die Eigenschaft Buildvorgang der Ressource auf „Eingebettet Ressource“ geändert werden muss. ++Dann kann man sich einen Verweis auf die Assambly holen und einfach die Ressource als Stream lesen:

//Um aus der Assembly die Manifest Ressource auslesen zu könnnen muss bei der Ressource die Eigenschaft Buildvorgang "Eingebettete Ressource" ausgewählt sein!
Assembly _assembly = Assembly.GetExecutingAssembly();

//Lesen aus dem gzip gepackten Datenstrom der Resource
GZipStream gzipStr = new GZipStream(_assembly.GetManifestResourceStream("Project.Resources.ds.xml.gzip"), CompressionMode.Decompress);
_ds.ReadXml(gzipStr);

Hallo, ich nochmal...

Mittlerweile habe ich einen Bericht erzeugt, der das Deckblatt und die gemeinsame Kopf- und Fußzeile enthält. Darin habe ich Unterbericht eingefügt, die Abhängig von Parametern sichtbar sind oder eben nicht.

Leide finde ich mein Lösung nicht sonderlich elegant. Schöner fände ich es, wenn ich von einem Ausgangsbericht, in dem ich Schriftarten, Deckblatt Kopf- und Fußzeile etc. definiere die anderen Berichte ableiten könnte (so was wie Vererbung wäre natürlich toll).

Hat da einer von Euch nicht doch noch eine gute Idee?

Gruß
Jens

Hi,

das Buch

Datenbank-Programmierung mit Visual C# 2010
Grundlagen, Rezepte, Anwendungsbeispiele
Auf CD: Beispiel-Code für Visual Studio 2010 und dieses Buch als eBook-Version.
1426 Seiten (Hardcover)
inkl. 1 CD-ROM PC
erschienen 11/2010 bei Microsoft-Press
ISBN-13: 978-3-86645-446-0

habe ich vorliegen. Ich finde es bietet einen guten Einstieg und ist für den Preis empfehlenswert.

Gruß
Jens

Hallo,

ich möchte mehrere Reports mit gleichem Deckblatt sowie gleicher Kopf- und Fußzeile erzeugen. Dazu würde ich gerne diese Elemente in einen Master Report einbauen, und aus diesem Report per Parameter das RDLC File mit dem eigentlichen Report auswählen. Leider scheint das nicht möglich zu sein.
Geht das doch bzw. gibt es Alternativen? Der einzige Weg, der mir noch einfällt ist einen gemeinsamen Report zu erstellen und die Sichtbarkeit der einzelnen Detailbereiche per Parameter zu steuern, was mir aber missfällt.

Gruß
Jens