Mudu’s Blog

PostgreSQL mit .NET via ODBC

Wichtig: Im Zusammenhang mit der LAP 2007 steht der Inhalt selbstverständlich wie alle anderen Dokumente unter der Bierlizenz (siehe LAP-Wiki). :)

Die Herren, für morgen ein kleines Sample, wie aus .NET auf eine PostgreSQL-Datenbank zugegriffen wird:

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Odbc;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            using(OdbcConnection cn = new OdbcConnection(”Dsn=DateNDrive”))
            {
                cn.Open();
                // Important: It seems necessary that table names must be in
                // double quotes!
                using(OdbcCommand cmd
                    = new OdbcCommand(”select * from \”public\”.\”Fahrzeug\”", cn))
                {
                    using(DataSet ds = new DataSet())
                    {
                        using(OdbcDataAdapter da = new OdbcDataAdapter(cmd))
                        {
                            da.Fill(ds);
                            foreach(DataRow dr in ds.Tables[0].Rows)
                            {
                                Console.WriteLine(String.Format(”{0} {1}”,
                                    dr[”Marke”], dr[”Typ”]));
                            }
                        }
                    }
                }
            }
        }
    }
}

Die Datei ist auch zum Herunterladen verfügbar. Erweiterungen kann jeder selbst vornehmen. :)

Die ODBC-Verbindung muss natürlich vorhanden sein. Man erstellt sie unter Windows mithilfe des “Data Sources (ODBC)” Administrative Tool (”%SystemRoot%\system32\odbcad32.exe”). Folgen Sie den Anweisungen, drücken Sie “Weiter”, akzeptieren Sie die Allgemeinen Geschäftsbedingungen für die Einrichtung einer Datenbankverbindung.

IEEE 802.1X authentication mit SP3: "Wired AutoConfig" (PEAP)

Am Wochenende Service Pack 3 (Windows XP) installiert, und Mittwoch in der Schule erstmal kein Internet. Sonst allerdings habe ich noch keine Probleme mit dem Update bemerkt.

Mein Problem war, dass die Authentifizierung am Netzwerk nicht mehr geklappt hat, und das “Authentication”-Tab im Eigenschaften-Dialog der Local Area Network (LAN) Connection weg war. Dies lag daran, dass mit Service Pack 3 der “Wired AutoConfig” Service eingeführt wurde, welcher die Authentifizierung vornimmt: “This service performs IEEE 802.1X authentication on Ethernet interfaces”.

Service gestartet, per default stand er auf “manual”. Alles super. Nur wissen muss man das…

TechTalk/Hands-on Lab "Silverlight 2 Beta"

Letzte Woche hatte ich das Vergnügen, am MSDN TechTalk und Hands-on Lab zu Silverlight 2 dabei zu sein. Mit dem Lab wollte es leider aus technischen Gründen nicht klappen, die Speeches waren jedoch äusserst interessant. Die Präsentationen von Ronny Saurenmann und Sascha Corti stehen auf der Microsoft-Webseite bereit. Die “Hands-on Lab”-Unterlagen hat Sascha Corti in seinem Blog-Post “Silverlight 2 Beta 1 - End-to-End Hands-On Lab” veröffentlicht.

Die Speeches gaben einen Überblick über Silverlight und hoben einige Features hervor. Hier sind einige Elemente lose zusammengetragen. Interessant waren für mich besonders die Möglichkeiten bei der Arbeit mit Daten. An der Modifikation des Aussehens von Steuerelementen habe ich (persönlich) eher weniger Interesse.

• Cool fand ich das Silverlight Data Grid. Zumindest die Demonstration der Möglichkeiten war beeindruckend und ich habe ähnliche Möglichkeiten wie in der Windows-Entwicklung (kein Paging- und Postback-Käse wie im “normalen” Web). Besonders das “Inline-Editing” ist praktisch.
• Fehlen tut in der aktuellen Version (Beta 1) noch die Drop Down Box. Im Manual zum Lab ist eine Anleitung enthalten, selbst eine zu bauen, jedoch lässt sich meiner Meinung nach nicht in Minuten aus einer Text- und einer List-Box eine vollwertige Drop Down Box bauen. Das Steuerelement verhält sich, obwohl subtil, total anders als das Original. Man gehe jedoch davon aus, dass in der finalen Version eine Drop Down Box dabei sein.
• Silverlight bietet keine DataSet-Unterstützung. Der empfohlene Weg sei, eine List<T> (bzw. “Custom Objects”) zu verwenden, mit dem LINQ-Helper alle geänderten Werte zu suchen und zurück an die Datenquelle (in der Regel wohl an einen Web Service) zu senden.
• Silverlight unterstützt nur asynchrone Datenabfragen (Web Service, etc.). Dies ist logisch, schliesslich würde andernfalls der Browser des Benutzers stillstehen.
• Data Binding ist weitgehend unterstützt, die Anwendung gleich wie bei der Windows Presentation Foundation (WPF). Wichtig in diesem Zusammenhang: “DataContext”- und “ItemsSource”-Properties.

Bei diesen Präsentationen sah ich auch des öfteren LINQ in Anwendung. Dies war sehr interessant, da ich noch nie damit gearbeitet habe, gehört jedoch in einen anderen Topf.

Für einen .NET-Programmierer ist Silverlight bestimmt eine schöne Sache, um “interaktive Web-Applikationen” zu entwickeln. Das Plug-In ist für den Internet Explorer, Mozilla Firefox und Safari verfügbar und unter Linux als “Moonlight” bekannt. Ich wage nicht, über die potentielle Verbreitung ein Urteil zu fällen respektive zu urteilen, ob die Unterstützung dieser Plattformen in den meisten Fällen ausreicht.

Da bleibt noch eine Frage: Warum, wieso muss das GUI von Blend so schaurig unpassend schwarz sein? Bsst, ganze Strasse dunkel, warum?

Zum Schluss noch einige Zitate zur Auflockerung:

• “In Silverlight 1 you didn’t even have a text box!”
• “In this case I’d already said it’s the system but I’m sure it’s me who did something wrong.” (der Internet Explorer verabschiedete sich abrupt)
• “There is coffee, we know how important this is for you.”
• “Well, a demo application without an animation is no demo application.”

Stored Procedures

Die Diskussion in der Schulklasse um Stored Procedures ist erneut aufgekommen: Im Rahmen unserer so-richtig-Vier-Tier-Hangman-Applikation, die wir für die Schule entwickeln müssen, wurde deren Notwendigkeit in Frage gestellt und diskutiert. Ich bin bekanntlich immernoch ein Verfechter von Stored Procedures für jeden kleinen SQL-Befehl, der gegen die Datenbank abgesetzt wird.

Grund 1: Stored Procedures sind eine definierte Schnittstelle

Stored Procedures definieren zwischen Datenbank und jeder Applikation eine klare Schnittstelle. Mit anderen Worten:

Stored procedures are a contract. (…) The header of the stored procedure defines the parameters that the developer must supply, and the body is where the DBA puts all of their voodoo magic to get the data you requested.

Die treffende Beschreibung stammt aus dem Post Service Oriented Databases auf PaulStovell.NET.

Durch die Stored Procedure wird es leichter, die Datenbank zu erweitern, die Daten weiter zu normalisieren, total anders abzulegen oder Felder umzubenennen. Ausserdem können Optimierungen in der Abfrage vorgenommen werden, ohne an der Applikation selbst zu schrauben.

Trotzdem ist es natürlich gefährlich, beliebige Änderungen beispielsweise an Feldnamen vorzunehmen und dann durch die Stored Procedure unter dem alten Namen anzuzeigen, wenn dadurch die Einheitlichkeit der Namen (und somit der Überblick über das Gebilde) verloren geht.

Grund 2: Stored Procedures sind vorkompiliert

Stored Procedures sind vorkompiliert. Somit wird die Abfrage nicht bei jeder Verwendung neu interpretiert weil wieder von der Applikation versandt (zumindest beim Microsoft SQL Server - ich kenne nicht jede DB). Dazu sei ein Artikel SQL Server Stored Procedures von About Databases Guide Site zitiert:

Precompiled execution. SQL Server compiles each stored procedure once and then reutilizes the execution plan. This results in tremendous performance boosts when stored procedures are called repeatedly.

Natürlich macht sich das erst ab einer bestimmten Nutzungsfrequenz und/oder Query-Komplexität bezahlt, aber es schadet auch sicher nicht. :)

Grund 3: Netzwerk-Traffic

Je länger das Query, desto mehr Netzwerkverkehr verursacht die Übermittlung. Ein Stored Procedure Aufruf ist je nach länge wesentlich (oder auch unwesentlich) kürzer.

Grund 4: Mehr Sicherheit durch restriktivere Permissions

Werden Stored Procedures konsequent verwendet, braucht erhält ein Web- oder Service-User, respektive der Benutzer selbst, keine direkten Zugriffsrechte auf Tabellen. Ihm wird lediglich eingeräumt, die Stored Procedures auszuführen, die er benötigt. Der Entwickler oder DBA legt auf diese Weise genau die Queries fest, welche der Benutzer auszuführen hat. Alles andere geht nicht.

Nachtrag: Heute, am 5. Mai, bin ich zu diesem Thema auf simple-talk über “Bad Database Security” von Tony Davis gestossen.

Grund 5: Änderungen an Queries (bei Client-Applikationen)

Bei Applikationen, die auf dem Client laufen und nicht auf dem Server, werden hart codierte Queries mit auf den Client kopiert. In einer neuen Version ändert sich eine Abfrage und ein Benutzer holt sich die neue Version nicht. Es gibt zwei blöde Szenarien:

1. Blöd: Das Query in der alten Version funktioniert nicht mehr und der Benutzer kann nicht arbeiten. Dies geht in Grund 1 hinein, aber kann natürlich auch mit Stored Procedures passieren, falls sich eine Schnittstelle ändern muss.
2. Blöder: Das Query liefert Daten, die es nicht liefern sollte. Nehmen wir an, in die Datenbank wird ein neues Feld “IsUserVisible” (Bit) eingefügt. Neu werden den Benutzern nur noch die Einträge angezeigt, welche “IsUserVisible” auf 1/true gesetzt haben. Krasser Häcker Hans-Detlev startet die alte Version und sieht Informationen, die er vielleicht besser nicht sehen sollte.

Was kein Grund ist…

Kein Grund ist meiner Meinung nach das SQL-Injection-Problem. Zwar kann die Tragweite dank eingeschränkten Rechten kleiner sein, aber folgendes kann der geneigte Bastler immer noch machen:

string sql = "EXEC MyStoredProc @Filter = \'" + filter + "\'"

Umgekehrt geht auch folgendes:

string sql = "SELECT * FROM Hubschrauber WHERE HubschrauberId = %1";
// … und hier mit einem DbCommand-Objekt und Parametern arbeiten

Hm…

Was gibt es dazu für andere Meinungen, Alternativen? Oder wie sieht das auf den verschiedenen DBs aus?

InfoPath, Expressions and 256 Characters

For once I’m writing in English, because I am translating English developer slang to German very badly (even worse that I write in English :P) and I’m sure there are more English-speaking developers. Maybe I will write a German version later on.

InfoPath behaves pretty strange when I use expressions that are longer than 256 characters. This morning I worked with rules and conditions on click of a button on an InfoPath form. In my opinion the following is a bug, but it might be a feature too of course:

If you replace “(long expression here)” with any kind of expression which is longer than 256 characters, everything will go well when you press OK. Now open the properties window again. The expression will be cut to 265 characters. You can paste it again and it will be well again.

The problem is, e.g. you change a condition for a rule that applies on click. Everything will look well, but Apply or OK will not work. As soon as you close the dialog, the changes will be wasted. As a workaround (in German: “Würgaround”), change the expression to “asdf” (or anything that is shorter than the magic 256 characters), make your changes, apply the changes, reopen the window and paste the expression again.

.NET Windows Forms Data Binding

In den nächsten Monaten steht mir Training in .NET bevor, um in näherer Zukunft die Prüfung zum Microsoft Certified Professional im Bereich .NET-Entwicklung (MCP 70-536) ablegen zu können. Gestern habe ich mich anhand von zwei Screencasts von Paul Stovell genauer mit DataBinding auseinandergesetzt. Der Post hat ein wenig TSchoenerNotizblock-Charakter und darf nicht als fertiger Artikel gesehen werden, das ist wichtig.

Implementierung von Business Objects

Für mein Beispiel, zugegebenermassen ein “gspürsch-mi?”-Beispiel, habe ich mir die Business-Entität “Person” ausgesucht, mit den Eigenschaften “FirstName”, “LastName” und “EMail” (exposed in gleichnamigen Properties). Zusätzlich habe steht ein Flag “IsDirty” bereit, das jedoch für mein Beispiel nicht von Bedeutung ist.

Ziel ist es, nach alter OO-Weisheit, das Objekt aus der echten Welt abzubilden. Diese Person allein könnte nun in .NET bereits als Datenquelle verwendet werden, jedoch habe ich einige weitere Implementationen vorgenommen, um die DataBinding-Features auszureizen.

IEditableObject, INotifyPropertyChanged, IDataErrorInfo

Meine Person-Klasse implementiert nun explizit (!) die .NET-DataBinding-Interfaces IEditableObject, INotifyPropertyChanged und IDataErrorInfo aus dem System.ComponentModel-Namespace. Die explizite Implementierung ist nicht zwingend, es funktioniert auch so. Ich habe den Ansatz gewählt, um das fachliche Element (die Entität “Person”) vom technischen Teil (DataBinding) der Klasse sauber zu trennen.

Ein Wort zur expliziten Interface-Implementierung: Implementiere ich ein Interface explizit, stehen die entsprechenden Properties nur zur Verfügung, wenn ich meine Objektinstanz in ein Feld vom Typ des Interfaces, in unserem Falle IEditableObject, INotifyPropertyChanged oder IDataErrorInfo speichere oder in ein solches caste. Habe ich ein Feld vom Typ Person, steht die Eigenschaft nicht zur Verfügung:

// Das Error-Property ist von IDataErrorInfo gegeben und
// implementiert.
Person p = new Person();
IDataErrorInfo d = new Person();
String s = p.Error(); // funktioniert nicht
String t = ((IDataErrorInfo)p).Error; // funktioniert
String u = d.Error; // funktioniert auch

Da nun .NET Windows Forms Data Binding intern mit den Interfaces arbeitet, kann es die Methoden und Eigenschaften, die wir bereitstellen, wunderbar verwenden. Arbeite ich jedoch selbst mit einer Objektinstanz, interessieren mich die DataBinding-Elemente nicht und ich sehe sie auch nicht. Wunderbar.

Die Implementierungen und deren Zweck rolle ich an dieser Stelle nicht aus. Gerne verweise ich auf die entsprechenden MSDN-Artikel oder den Screencast von Paul Stovell in seinem Blog-Post Binding Patterns 0×0002 - Binding to Objects (englisch) mit dem geilen Kamel. Das Video habe ich mir an einem gemütlichen Sonntag Morgen bei einem Käffchen und einer Schale Corn Flakes reingezogen und in vierzig gemütlichen Minuten viel gelernt (und mich gefragt, warum ich jahrelang von Hand Text-Boxen abgefüllt habe…).

Architektur

Diese Implentierung hält die Architektur der Programms sauber. Beispielsweise sind sämtliche Validierungsroutinen dank dem IDataErrorInfo-Interface innerhalb des Business-Objekts angesiedelt und wandern nicht in den Anzeige-Layer. Und weil .NET Windows Forms Data Binding diese Interfaces out-of-the-box unterstützt, ist auch die Fehleranzeige durch einfaches Einfügen eines ErrorProviders auf der Form, der an die BindingSource gehängt wird, getan.

Der Anzeige-Layer ist dank DataBinding wirklich nur ein Anzeige-Layer und beinhaltet keinen weiteren Code. Fehlerbehandlung, Editieren mit Abbrechen und Bestätigen sowie die Aktualisierung aller Fehler läuft automatisch.

Got MVC?

Nächsten Dienstag steht eine Prüfung in Informatik an. “GUI-Bastelstunde in Java” ist das Thema, dazu gehört auch das MVC-Pattern.

Heute Abend habe ich zum ersten Mal in meinem Leben eine funktionierende MVC-Anwendung geschrieben, mithilfe einer hübschen Anleitung, die ich im Internet gefunden habe. An dieser Stelle herzlichen Dank an Joseph Bergin. Einen kleinen Teil hat auch die BauerPoint-Präsentation beigetragen, die ich zu diesem Thema auf der schuleigenen Moodle-Plattform gefunden habe.

Wer MVC auch nur ein wenig kennt, wird gähnen (”So ein Anfänger!”). Der Code geht kein bisschen über das Berufsschul-Minimalisten-Niveau und ist nur für erste Versuche oder zur Prüfungs-Vorbereitung gut.
Ich publiziere hier nur den Code (TemperatureMVC, ZIP-Archiv); eine lange Anleitung zu schreiben, spare ich mir. Davon gibt es schon genug. Allerdings sind die Beispiele in unserem Schulmaterial oft ziemlich gross. Dieser Fahrenheit-/Celsius-Rechner ist wirklich sehr einfach, aber genug, um das Prinzip zu verstehen.

WMI Query Language und .NET

Was die “WMI Query Language” mit .NET zu tun hat? Nun, nicht nur Windows-Administratoren müssen das (anscheinend, vielleicht) können, sondern auch Kandidaten für das “MCP 70-536″-Examen von Microsoft. Ein solcher würde ich gerne zu sein werden gedenken, und das noch dieses Jahr, und da gilt es zu lernen.

Auch dieses “WQL”, ein beschnittenes SQL, ist gefragt.

Zu den Aufgabenstellungen heisst es, ich müsse Platten, Netzwerkadapter und Prozesse auslesen können, Informationen über alle Netzwerkverbindungen abrufen und natürlich auch alle Services zusammenkratzen, die gerade pausiert sind. Nun, have fun. Wirklich dokumentiert ist dieses misteriöse WQL nicht, im mindestens finde ich in der MSDN nicht brauchbares.

Um jetzt ein wenig zu üben, habe ich mir einen kleinen “Query Analyzer” gebaut. Das Ding mit dem SQL Query Analyer zu vergleichen, wäre ein wenig, nein sehr hochgestochen, aber um ein wenig ausbildungsbedingten WQL-Masochismus zu betreiben reicht es.

Den Source-Code habe ich hochgeladen (WqlAnalyer), da habe ich auch schon ein paar dieser kryptischen Queries notiert. Prosit Hubschrauber!

Sobald ich mehr weiss, trage ich einige interessante (oder langweilige) Erkenntnisse zusammen, was WQL selbst betrifft. Das Jonglieren mit den entsprechenden Objekten ist nicht sonderlich aussergewöhnlich.

Visual C# 2005 Express Edition

Erster Eindruck: “Alles so schön bunt hier!”

Seit ein paar Tagen schlummert die Express-Edition des neuen Visual Studio auf meinem Rechner. Erstmals habe ich es heute in die Hand genommen und für eine kleinere Applikation genutzt. Ich will ja nicht behaupten, dass mein Programm schon lauffähig ist, aber ich bin ein gutes Stück weit gekommen und habe bereits einige Vorteile der neuen Version entdeckt:

• Intelli-Sense im Watch-Fenster: Neu kann ich mir während dem Debuggen sehr schön im Watch-Fenster meinen Code vervollständigen lassen. Sehr nützlich, wenn ich von einem Objekt einen Eigenschaftswert wissen will und nicht genau weiss, wie das Property heisst. Oder auch einfach, wenn ich zu faul bin, den Namen auszuschreiben und ihn mir lieber AutoVervollständigen lasse.
• “Windows Form Designer Generated Code” in einem separaten File: Was in Visual Studio 2003 immerhin durch eine “region” umschlossen war, ist nun ganz in eine eigene Datei ausgelagert. Schön, da der Code meistens nur störend war, da ohnehin vom Form-Designer automatisch generiert.
• “Masked Text Boxes”, beispielsweise um ein Datum bereits fertig formatiert zu bekommen und dem Benutzer die Eingabemaske entsprechend zurechtzumachen. Vergleichbar mit der Datumseingabe in Outlook. Möglicherweise gibt es das Control auch schon im alten Visual Studio, jedoch ist es mir erst jetzt aufgefallen.
• Automatische Anpassung des Klassennamens an den Dateinamen: Ich habe ein neues Projekt erstellt und als erstes die “Form1.cs” in “FrmMain.cs” umbenannt. Prompt fragte mich der Gentleman, ob er nicht die Klasse “Form1″ in “FrmMain” umbenennen solle. Konsequent durchgezogen hat er es, keine Compiler-Fehlermeldungen tauchten mehr auf, weil irgendwo noch der alte Name verwendet wurde.

Insgesamt macht das Teil einen guten Eindruck. Ich habe jetzt die ersten zwei Stunden damit gearbeitet und bin zufrieden. Die Express-Edition ist neuerdings sogar ganz kostenlos und darf anscheinend auch kommerziell verwendet werden (ohne Garantie :p).

Einziger Minuspunkt: Die Performance. Zwischendurch, insbesondere kurz nach dem Start “bis die IDE warmgelaufen ist” (also alle Komponenten in den Speicher geladen hat) und beim Starten und Anhängen des Debuggers schlief mir förmlich das Gesicht ein.