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.

WCF Service Error (Silverlight 2 Development)

While working with Silverlight 2 Beta 1 and a WCF Service as the data source, I received the following error (with a different messy filename of course):

Could not load file or assembly ‘App_Web_sjsnnzu9, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.

This issue can be solved with the following change in the web.config file:

<compilation debug="true" batch="false">

The important part is the “batch=false”. See the MSDN “compilation Element (ASP.NET Settings Schema)” for further information about this section. At least it solves the issue so far. :)

Thank you to Olivier who wrote a comment on a post in Rick Strahl’s Web Log.

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…

Gewohnt anders.

Ein Bild zum Slogan, zitiert von der IKEA-Webseite. Proudly powered by Vorgezogenes Sommerloch(tm).

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.”

Data Source Independent DAL

Another short piece of personal learning. Ich markiere für einmal den grossen Architekten. :)

Die Idee eines Data Access Layers ist gemeinhin, Datenzugriffe datenbank- oder sogar datenquellenneutral (neben relationalen Datenbanken allein können ja auch Textdateien oder ein Web Service als Datenquelle dienen) zu halten. In der Praxis ist dies nach meinen Erfahrungen nicht immer genau so der Fall, wie dies die Theorie anpreist.

Die Theorie sagt: Der Presentation Layer präsentiert Daten und enthält keine Logik (höchstens formelle Prüfung oder Plausibilisierung von Eingaben), der Business Layer hantiert mit den Business-Objekten und implementiert die Logik, der Data-Access Layer liest und speichert die Daten und abstrahiert die Zugriffe auf die Datenquelle auf allgemeinem Level.

Ich wollte nun einen Business Layer, der weder von der Datenquelle abhängt noch hunderte Zeilen Code enthält, um die netten Rückgabewerte und Ausgabeparameter wieder in Objekte umzubauen. Ich wollte im DAL auch keine Strukturen definieren, dessen Felder denjenigen im Business-Objekt entsprechen. Ein Objekt (Business Entity!) soll “as it is” ohne weitere Bearbeitung zur Speicherung gereicht werden und auch fixfertig wieder aus dem DAL kommen.

Dafür habe ich nun ein separates Assembly gebaut mit abstrakten Basisklassen für die Business-Objekte. Business Layer und DAL haben beide eine Referenz darauf, sodass beide die Grundstruktur der Objekte kennen. Hier eine schnelle PowerPoint-Skizze:

Der Business Layer kann nun dem DAL beliebige Instanzen von Klassen übergeben, welche von den (abstrakten) Basisklassen im DAL abgeleitet sind. Im Business Layer kann ich meine Business-Entitäten erstellen, die von den Basisklassen erben, meine Methoden erstellen und zusätzliche Interfaces implementieren, beispielsweise für bequemes .NET Windows Forms Data Binding.

Zur Implementierung habe ich vorerst nur die gekapselten Felder und das IEquatable Generic Interface in der Basisklasse implementiert: Die Entität soll grundsätzlich sofort einsetzbar sein (für Business-Layer und DAL!), aber keine besonderen Businessfunktionalitäten bereitstellen. Die braucht der DAL nämlich nicht, und hat sie auch nicht zu brauchen.

Nein, allzu neu ist die Idee nicht. Bei simple talk ist die Idee im Artikel “.NET Application Architecture: the Data Access Layer” (der Artikel ist sehr empfehlenswerte Lektüre!) beispielsweise aufgegriffen, diskutiert und Alternativen gegenübergestellt. Sie beschreibt diesen Approach als akademisch:

From an academic standpoint, this approach is probably the truest form of a data abstraction for a DAL because you can make the shared classes completely data-source independent and not just database independent.

Diesen Eindruck macht er auch auf mich. Ich bin mir nicht sicher, inwiefern er bei grossen Projekten mit aberhunderten von Entitäten wirklich bequem durchführbar ist. Aber er ist bestimmt nicht schlecht; ich werde damit experimentieren.

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.

The Tumble Dryer

Ich ziele nicht auf die Lyrics von “Retirement”, Kaiser Chiefs, nein.

“Ich selber habe die Erfahrung gemacht, daß normale Shirts, Hosen, usw., die nicht gerade besondere Applikation und Sonderstoffe beinhalten, auch getrocknet werden können.” (Tobias Haase in de.etc.haushalt)

Dies las ich die in de.etc.haushalt, gefunden über Google. Die Erfahrung kann ich bestätigen, übernehme aber selbstverständlich keinerlei Haftung. ;)

Mein Problem ist, dass der Trockenraum des Wohnblocks schlecht ist. In zweierleit Hinsicht:

• Die Raumluft wird weder geheizt noch getrocknet und die Wäsche trocknet entsprechend langsam.
• Es stinkt zwischendurch ein wenig faulig (oder so ähnlich, woher auch immer das kommt) oder nach Zigarettenrauch aus dem Treppenhaus oder dem Lift. Wenn ich die Wäsche nun drei Tage hängen lassen muss, nimmt sie eine Mischung aus sämtlichen Gerüchen auf.

Nun habe ich Gebrauch vom Tumbler gemacht, obwohl die meiste Wäsche dafür nicht offiziell geeignet gewesen wäre. Quer durch, von Shorts bis Pullover, alles in eine Ladung und auf dem Schonprogramm durch. Kein Problem, lediglich nicht ganz “schranktrocken”. Aber diese Restfeuchtigkeit liess sich gut in einigen Stunden in der Wohnung wegtrocknen.

Warum ich das schreibe? Ich habe lange gegoogelt, um eine Empfehlung bezüglich Tumlerbenutzung bei normalen Textilien zu finden. Massenhaft Werbung für Geräte habe ich gefunden, und in der Wikipedia historische Fakten. Kurz vor der Kapitulation stiess ich auf den oben genannten Beitrag. Und selbstverständlich beweist man ja auch Hausmännlichkeit.

Operation “Bohrhammer” (Heimwerkerkönig)

Ein grosses Jahrhundertprojekt seit dem Einzug in die neue Wohnung war (!) das Aufhängen der neuen Lampe. Tatataaa:

Zwischen Weihnachten und Neujahr habe ich endlich die Zeit gefunden, mich mit dem Bohrhammer an die Bohrlöcher zu machen, die ich schon lange vor mir her schob: Die Garderobe (für einen Euro in Deutschland gefunden), die Lampe sowie einen Wand-Zeitschriftenhalter. Mit dem Bohrhammer ging das ganz leicht, anders als mit der Schlagbohrmaschine. Damals habe ich damit die Lampe aufhängen wollen, nach der Farbe auf der Decke aber aufgegeben.

Den Wand-Zeitschriftenhalter und die Asterix-Bände habe ich zu Weihnachten bekommen, und das bewährt sich wirklich. WLAN habe ich noch keines, somit ist ein Stoss Hefte in der Nähe des Topfes super.

Die Garderobe hängt zwar ein wenig schief (das Foto lassen wir diskret weg), aber sonst ging das auch als Informatiker ganz gut. Es ist nur ganz wichtig, sich vorher zu erkundigen, wo Gas-, Wasser-, und Stromleitungen verlaufen. Ich habe da einiges gegoogelt und viel gefunden (u.a. “Wenn Bohrer oder Nagel eine Leitung treffen”), jedoch hat mir das den Gang zum Hausmeister nicht erspart.

Ach ja: Die Nachbarn waren gerade beide nicht zu Hause. … und nun bleibt mir nur noch, einen guten Rutsch zu wünschen.