Marco's .NET Blog

Lange suchen und versuchen, und doch gefunden…

Mein WCF-Service meldete sich mit einer “KeyNotFoundException” zurück. Lag an der Verwendung von “wsHttpBinding” in der web.config.

Nach der Änderung des Binding auf “basicHttpBinding” in der web.config, aktualisieren der Service-Referenz und neu erstellen des Projekts lief alles…

GridViews sind eine schöne Sache. Man kann schnell und einfach Daten auf seiner Form ausgeben, bearbeiten und vor allen Dingen komfortabel löschen.
Aber nur, wenn die Bezugsspalte in der Datenbank als Primary Key hinterlegt ist.

In meinem Fall sollte eine Terminserie, die aus vielen Einzelterminen (jeder Termin hat eine ID -> Primary Key) anhand einer SerienGuid (varchar -> KEIN PK), die diese Termine zu einer Serie zusammenfasst, gelöscht werden.

Hierzu habe ich im GridView folgende Änderungen vornehmen müssen:

DataKeyNames [Tag] entfernen
OnRowCommand=”GridView1_RowCommand” einfügen

Ein neues Template-Field hinzufügen:

1
2
3
4
5
6
7
8
9

<asp:TemplateField>
<ItemTemplate>
<asp:ImageButton ID=”ImageButton1″ runat=”server” ImageUrl=”~/images/icon_delete.gif”
CommandName=”DeleteIt” OnClientClick=”return confirm(‘Möchten Sie diesen Eintrag wirklich löschen?’);”
CommandArgument=’<%# Eval(“SerienGuid”) %>‘ />
</ItemTemplate>
<HeaderStyle BackColor=”#EBF1FD” HorizontalAlign=”Center” />
<ItemStyle BackColor=”White” HorizontalAlign=”Center” />
</asp:TemplateField>

Anschliessend im CodeBehind:

1
2
3
4
5
6
7
8
9

protected void GridView1_RowCommand(object sender, GridViewCommandEventArgs e)
{
   if (e.CommandName == “DeleteIt”)
   {
      String sql = “DELETE FROM SerienTabelle”
            + “ WHERE SerienGuid = ‘” + e.CommandArgument  + “‘”;
      [...]
   }
}

Schön, dass es sie gibt: Den <TextMode=”Password”> bei der <asp:TextBox>.
Aber schade, dass sich das Control anders verhält als die “Standard-Textbox”. Nach einem Postback sind die enthaltenen Eingaben nämlich weg. Gerade bei Registrierungsformularen, die Informationen ein- und ausblenden sollen (je nachdem was der Benutzer so anklickt), wäre es aber sehr wünschenswert, wenn der Inhalt beim Postback erhalten bleibt.

Dieses Verhalten lässt sich mit einem einfachen Code-Schnippsel einstellen:

1
2
3
4
5

protected void Page_Load(object sender, EventArgs e)
{
    textboxPasswort.Attributes.Add
                     (“value”, Request.Form[textboxPasswort.UniqueID]);
}

Man braucht es halt doch: das Captcha-Control. Ohne dieses erstickt man in Spam-Submitted-Forms…
Unter
http://www.mondor.org/captcha.aspx
ist es freies, leicht integriebares Captcha-Control als Download verfügbar.

Kleiner Zusatz für die Verwendung in der web.config:

IIS 7:
Unter system.webserver handlers muss noch der folgende Abschnitt hinterlegt werden:

<add path=”CaptchaImage.axd” verb=”GET” preCondition=”integratedMode,runtimeVersionv2.0″/>

IIS 6:
Den Abschnitt  unter system.web httphandlers ablegen

Wer mal auf die Schnelle einen ConnectionString für einen Datenzugriff unter .NET braucht:
Auf dieser Webseite sind ConnStrings für jeden erdenklichen Zugriff zu finden…

http://www.connectionstrings.com

(Danke an Thomas Br. / Thomas G.)

Wer den MaskedEdit Externder aus dem AJAX-Toolkit (http://www.asp.net/ajax) einsetzt, kenn die Problematik, dass ein Datumswert, der nicht im Format dd.mm.yyyy eingegeben wird sondern als dd.mm.yy, zurück ins 20. Jahrhundert (also 19xx) zurückkatapultiert wird…
Auch die Eigenschaft Century nutzt hier nichts, denn diese wird schlicht und ergreifend ignoriert.

Eine kleine Änderung im MaskedEditBehavior.js lehrt den MaskedEdit Extender das 21. Jahrhundert:

Zeile 2005 – Funktion: _GetDateElementText

if (Y4)
  {
  if (aux !=”" && aux.length < 4)
    {
     while (aux.length < 4)
     {
       aux = “0″ + aux;
      }

     // DIESE ZEILE EINFÜGEN –>
     if (aux.substring(0,2) == ’00′) aux = ’2′+aux.substring(1,4);
     // <–

     m_arrDate[this.get_CultureDateFormat().indexOf("Y")] = aux;
   }
}
else [...]

Jetzt springt der MaskedEditExtender automatisch auf 20xx um…

Voraussetzung für die Umsetzung dieses Beitrags ist ein funktionierender Report auf Basis des SQL Reporting Services. Hierbei ist es unerheblich mit welcher SQL Server Version (2005[8.0] oder 2008[9.0]) gearbeitet wird. Die asp.NET-Umsetzung habe ich im Framework 2.0 umgesetzt.

Zunächst brauchen wir eine (in meinem Fall serialisierbare) Klasse, die das Interface Microsoft.Reporting.Webforms.IReportsServerCrendentials zur Ausführung des Reports implementiert:

[Serializable]
public class ReportCredentials :
      Microsoft.Reporting.WebForms.IReportServerCredentials
{
   string _userName, _password, _domain;

   public ReportCredentials(string userName, string password,
            string domain)
   {
      _userName = userName;
      _password = password;
      _domain = domain;
   }

   public System.Security.Principal.WindowsIdentity  ImpersonationUser
   {
      get
      {
          return null;
       }
    }

   public System.Net.ICredentials NetworkCredentials
   {
     get
     {
        return new System.Net.NetworkCredential
                       (_userName, _password, _domain);
     }
   }

   public bool GetFormsCredentials(out System.Net.Cookie authCookie,
             out string userName, out string password,
             out string authority)
   {
      userName = _userName;
      password = _password;
      authority = _domain;
      authCookie = new System.Net.Cookie
                      (“.ASPXAUTH”, “.ASPXAUTH”, “/”, “Domain”);
      return true;
     }
}

 Auf der aspx-Page, auf der der Report eingebunden werden soll, muss ein Steuerelement “ReportViewer” und folgender Code eingefügt werden:

protected void Page_Load(object sender, EventArgs e)
{
  if (!IsPostBack)
  {
    ReportViewer1.ShowCredentialPrompts = false;
    ReportViewer1.ServerReport.ReportServerCredentials =
             new ReportCredentials(“UserName”, “Passwort”, “”);
    ReportViewer1.ProcessingMode = 
             Microsoft.Reporting.WebForms.ProcessingMode.Remote;
    ReportViewer1.ServerReport.ReportServerUrl =
             new System.Uri(“http://reportserver/ReportServer”);
    ReportViewer1.ServerReport.ReportPath =
             “/Path2Report/ReportName”;

    ReportViewer1.ServerReport.Refresh();
  }
}

Auch eine Parametrisierung aus der Webpage ist möglich:

ReportParameter[] param = new ReportParameter[1];
param[0] = new ReportParameter(“ReportParam”, txtParameter.Text);

ReportViewer1.ServerReport.SetParameters(param);

Und zu guter letzt muss noch ein Abschnitt in der web.config im Abschnitt <system.web><httpHandlers>  angelegt werden:

<add verb=”*” path=”Reserved.ReportViewerWebControl.axd” type = “Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />