Mit default erfolgt eine Initialisierung mit dem Standardwert des jeweiligen Typ.
In den Fall ist aber keine Initialisierung notwendig, diese oder eine Zuweisung ist nur vor dem ersten Lesezugriff notwendig.
Mit welchen Wert eine Initialisierung ist eher fachlicher Natur und nicht technischer Natur.
Als Vorschlag was kürzer ist (ungetestet):
// public DateTime NextBuisinessDay(DateTime date, Dictionary<DateTime, string> holidays)
public DateOnly NextBuisinessDay(DateOnly date, Dictionary<DateOnly, string> holidays)
{
while (IsWeekend(date) || IsHoliday(date, holidays))
{
date = date.AddDays(1);
}
return date;
}
PrintPageEventArgs bietet doch die Eigenschaften für die Seitengröße.
Diese musst Du entsprechende verwenden und umrechnen, für das Zeichnen der Linien.
Eine Bitmap hat eine andere DPI z.B. 96, als ein Drucker (z.B. 300 oder 600).
Wenn ich das richtig sehe wird erst eine Bitmap erstellt, welche dann auf das PrintDocument gezeichnet wird.
Warum der Umweg über das Bitmap und nicht direkt auf e.Graphics zeichnen?
Ich bin mit jetzt auch nicht ganz sicher, aber ich meine wenn das Programm aus Visual Studio gestartet wird ist das aktuelle Verzeichnis in dem die Projektdatei liegt.
Ich habe ewig nichts mehr mit Winforms und dem DGV gemacht.
Aber kann es sein das die NullReferenceException beim zweiten Durchlauf kommt.
Ich meine wenn die Rows durchlaufen werden sind alle dabei, auch die Zeile um eine neue zustellen dabei.
Sie können diesen Konstruktor nicht verwenden, um schreibgeschützte Dateien zu öffnen. Stattdessen müssen Sie einen Konstruktor verwenden, der einen- FileAccess Parameter akzeptiert, dessen Wert auf festgelegt ist FileAccess.Read .
Wir suchen nun eine performante Möglichkeit, die es ermöglich das gewünschte Feature umzusetzen.
Dazu habe ich einen alternativen Vorschlag gemacht.
Aber mir persönlich ist dieses Feature relativ egal, da ich es nicht brauche.
Ich kenne nicht die Post pro Zeit und was so gelesen wird pro Zeit.
Ich kann mir nur vorstellen wenn die Forenübersicht aufgerufen wird, das es schneller geht da weniger Tabellen betroffen sind.
Aber dafür müsste man es testen.
dass wir bei jeder Registrierung sofort für 117.000 Themen Dateneinträge erzeugen müssen
Wenn für einen neuer User alle Themen als ungelesen gekennzeichnet sein soll, dann Ja.
Ich würde sagen bei einen neuen User ist für ihn alles als gelesen gekennzeichnet.
Und das Tracking beginnt erst mit der Registrierung.
Zitat von Abt
und gleiches bei neuem Thema für 30.000 User. Hinzu kommt, dass wir Stati erzeugen müssen, die womöglich bei vielen Usern nie wieder abgefragt werden (weil Konten inaktiv etc).
Dem könnte man entgegen wirken, das nur User berücksichtigt werden deren letzte Aktivität nicht zu lange zurück liegt.
Zitat von Abt
Ich weiß nicht, wie das schneller sein soll. Das ist ja gerade das, was wir nicht wollen: expotentielles Wachstum / Leistungsthema. Oder sehe ich das falsch?
Aber wenn ich das richtig sehe mit dem aktuellen Datenbankschema, spielt die Tabelle ForumBoardUserVisits keine Rolle um an die Informationen zu bekommen, ob alle Themen eines Boards gelesen sind.
Und anders müsste die Informationen aus mehreren Tabellen ermittelt werden, neben ForumThreadUserVisits müssten auch noch ForumPosts und ForumThreads berücksichtigt werden.
Bei meinen Vorschlag nur die eine Tabelle.
Weiterhin hat man damit auch die Möglichkeit auszuräumen, z.B. ältere Einträge aus der Tabelle löschen.
Und ich weiß nicht ob es gewünscht ist über die Jahre festzuhalten, wann was von jeden User gelesen wurde.
Ob das wirklich schneller, müsste man testen.