IMAP_Sample

Update: Jetzt auch mit SSL-Unterstützung…

Man gibt nur noch den Namen des Sql-Parameters und den entsprechenden Wert an und das .Net Framework kümmert sich um den Rest.

using (var conn = new SqlConnection(@"ConnectionString zensiert"))
{
     conn.Open();

     string sql = "Select LastName FROM TestTable WHERE LastName = @l";

     var cmd = new SqlCommand(sql, conn);

      cmd.Parameters.AddWithValue("@l", "Harglgargl");
       //selbes Ergebnis
       //cmd.Parameters.Add("@l", "Meier");

       object res = cmd.ExecuteScalar();
}

Ich würde erwarten, dass der SQL-Server schlau genug wäre und den Parameter korrekt auflöst.

Leider gibt es hier ein kleines Problem.

Führt man das Codefragment mit den Werten “Huber”, “Schmidt”, und “Harglgargl” aus würde man erwarten,

dass der SQL-Server einen bereits vorhandenen Ausführungsplan benutzt bzw. einen Plan für diese Abfrage erstellt und dann wiederverwendet.

Das Resultat sieht leider etwas anders aus:

Für jede Varchar-Länge wird ein eigener Ausführungsplan angelegt.

Die Auswirkungen werden bei einem genaueren Blick auf die Speicherausnutzung des SQL-Servers deutlich.

Mein Dev-Server sagt dazu auf jeden Fall Folgendes:

Cached: verwendeter Speicher um Seiten zu cachen

Stolen: Speicher der “gestohlen” wird um Ausführungspläne zu cachen

Das Verhältnis wird in den meisten Szenarien vernachlässigbar sein. Ich kann mir allerdings einige Umgebungen vorstellen in denen das Ganze zum Problem werden könnte.

Wie dem auch sei. Je mehr Speicher zur Verfügung steht um Seiten zu cachen umso besser

Die Lösung des Ganzen ist aktuell leider etwas umständlich. Man kann das Ganze umgehen indem man den Datentyp der entsprechenden Datenbankspalte angibt.

Leider ist das Ganze extrem lästig da es aktuell keine brauchbare Überladung gibt (Man kann sich natürlich eine schnitzen)…

using (var conn = new SqlConnection(@"ConnectionString zensiert"))
{
     conn.Open();

     string sql = "Select LastName FROM TestTable WHERE LastName = @l";

     var cmd = new SqlCommand(sql, conn);

     SqlParameter p = new SqlParameter("@l", System.Data.SqlDbType.VarChar, 1000);
     p.Value = "Huber";

     cmd.Parameters.Add(p);

     object res = cmd.ExecuteScalar();
}

Das Ganze wäre prinzipiell mit Hilfe einiger Subqueries machbar.

Optimaler läßt sich das Ganze mit Hilfe der Funktion Rank() lösen die ab SQL-Server 2005 zur Verfügung steht.

SELECT
	Spieler,
	Verein,
	Tore,
	Saison,
	RANK() OVER (PARTITION BY Saison ORDER BY Tore DESC) AS Platz
FROM
	#ErzielteTreffer

SELECT Spieler,Verein,Tore,Saison FROM
	(
	SELECT
		Spieler,
		Verein,
		Tore,
		Saison,
		RANK() OVER (PARTITION BY Saison ORDER BY Tore DESC) AS Platz
	FROM
	#ErzielteTreffer
	) AS Rangfolge
WHERE Platz = 1

Config:

...
    
      
        
          ...
          

              
            
            
          
        
      
    
    
      
        
          
            
            
          
          ...
      
    
    
      
        
      
    
    ...

Das Standard-Traceing im WCF Framework ist erstaunlich einfach anzuwenden und zu konfigurieren. Auch das im Framework enthaltene Analysetool ist ganz brauchbar.

So viel Luxus ist man gar nicht gewohnt wenn man vorher hauptsächlich mit dem WSE-Framework zu tun hatte…

Leider ist Microsoft den Weg nicht komplett zu Ende gegangen. Gibt man sich nicht mit der Erzeugung von Logdateien zufrieden, sondern will das Ganze in eine Datenbank  bzw. Message Queue persistieren darf man wieder selbst tätig werden.

Ich würde davon abraten das komplette Traceing direkt synchron aufzusetzen. Es hat sich bewährt die Nachrichten zuerst einmal zwischenzulagern und die Verarbeitung dann asynchron auszuführen.

public class MsmqTracer : TraceListener
{
   public override void TraceData(TraceEventCache eventCache, string source, TraceEventType eventType, int id, object data)
   {
   if (!string.IsNullOrEmpty(traceQueue))
   {
      try
      {
      MessageQueue msmq = new MessageQueue(traceQueue);
      MessageQueueTransaction trans = new MessageQueueTransaction();

      trans.Begin();
      Message msg = new Message(data.ToString(), new XmlMessageFormatter());

      msmq.Send(msg, trans);
      trans.Commit();
      }

      catch (Exception msmqEx)
      {
         Debug.WriteLine(string.Format("Error while persisting trace: {0}", msmqEx.ToString()));
      }
   }
   else
   {
      Debug.WriteLine("Missing MSMQ Trace");
   }
}

public override void Write(string message) {}

public override void WriteLine(string message) {}

Leider ist das Ganze kaum dokumentiert…

Die Aktivierung der Counter ist denkbar einfach (wenn man mal rausgefunden hat dass es sowas überhaupt gibt…) und erfolgt durch einen Eintrag in der App.Config des Hosts

Die entsprechenden Werte lassen sich dann direkt mit perfmon anzeigen und auswerten.

Excel 97 – 2003

SELECT

     [ID], -- Excel Spalte 1
     [Text] -- Excel Spalte 2

FROM

     OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0',
     'Data Source=C:\test.xls;Extended Properties=Excel 8.0')
     ...[Tabelle1$] -- Tabellenblatt

ORDER BY

[ID] DESC

Excel 2007:

Um die Funktionalität auch bei .xslx-Dateien nutzen zu können, muß folgende Komponente auf dem System installiert sein:
2007 Office System Driver: Data Connectivity Components
 

SELECT
	*
FROM
	OPENDATASOURCE(
		'Microsoft.ACE.OLEDB.12.0',
		'Data Source=C:\test.xlsx;Extended Properties=Excel 12.0')
		...[Tabelle1$]

Leider funktioniert das Ganze aktuell nur auf 32-Bit Systemen, da die entsprechenden Provider auf 64-Bit Systemen derzeit nicht zur Verfügung gestellt werden.

Um dieses Feature nutzen zu können muss folgendes Setting aktiviert sein

EXEC sp_configure 'Ad Hoc Distributed Queries', '1' RECONFIGURE

http://technet.microsoft.com/de-de/library/ms187569.aspx

WITH TEMP (Pk, Parent_Pk, Title, Name, Iteration) AS
(
  SELECT Pk_JobStruct, Fk_Parent, Title, Name, 0
  FROM T_JobStruct
  WHERE PK_JobStruct = 1 -- el cheffe

 UNION ALL

  SELECT sub.Pk_Jobstruct, sub.Fk_Parent, sub.Title, sub.Name, (t.Iteration + 1)
  FROM T_JobStruct AS sub, temp AS t
  WHERE t.Pk = sub.Fk_Parent

)

SELECT * FROM Temp

Auch wenn in der Webservice-Entwicklung mittlerweile größtenteils das WCF-Framework eingesetzt wird, haben wir alle bestimmt noch die eine oder andere “ältere” Anwendung zu betreuen.

Tritt ein Bug auf, schadet es nie zuerst einen Blick auf die entsprechenden Daten zu werfen. Während das Ganze im WCF-Framework mit einigen Mausklicks erledigt ist oder man nicht sowieso ein asychrones Traceing aufgesetzt hat ist bei den Web Service Enhancements ein wenig mehr zu tun.

Das Ganze ist allerdings mit Vorsicht zu genießen und sollte auf Produktiv-Systemen relativ zügig wieder deaktiviert werden da die entsprechenden Dateien relativ schnell anwachsen…

- Referenz auf die entsprechende WSE Assembly einfügen

- Die Vererbung der generierten Client-Klasse anpassen

Reference.cs

public partial class GlobalWeather : Microsoft.Web.Services2.WebServicesClientProtocol

 - App.config der Anwendung erweitern

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
 ...
      <section name="microsoft.web.services2" type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </configSections>
 ...
  <microsoft.web.services2>
    <diagnostics>
      <trace enabled="true"
        input="inputTrace.webinfo"
        output="outputTrace.webinfo"/>
    </diagnostics>
  </microsoft.web.services2>
</configuration>