Die Zeit, die er hierdurch spart, kann er ja für ein Gespräch mit seinem Wirtschafts- und Innenminister verwenden, in dem er unsere Freude über ihre ständige Produktpiraterie und Menschenrechtsverletzungen kundtut.

Wie der eine oder andere vielleicht mitbekommen hat, passiert hier in der letzten Zeit recht wenig.

Grund hierfür ist, dass ich momentan in nicht-IT-Projekten bei meinem Arbeitgeber sehr stark eingebunden bin.

Dabei ist mir in den letzten Wochen (leider) eines doch relativ häufig aufgefallen:

Die Unternehmen der old economy (z.B. Stahlhandel etc.) wirken dem Kunden gegenüber wesentlich engagierter als die der new economy (Softwarehäuser etc.).

Konkret merke ich dass aktuell daran, das wir Software für FEM und PDM anschaffen möchten, wir aber entweder von den Softwarehäusern keine qualifizierten Angaben zu dem jeweiligen Produkt erhalten können oder falls wir diese haben, ewig (mehrere Tage bis Wochen) auf ein Angebot warten müssen.

Gerade die IT-Branche mit Ihren ausgefeilten CRM-, ERP-, [SonstigeAkronyme]-Software sollte doch in der Lage sein den Kunden mit Standardlösungen schnell bedienen zu können - insbesondere dann, wenn der Kunde ausdrücklich sagt "ES EILT!".

Unter diesem Aspekt erscheinen die Unternehmen überhaupt nicht jung, dynamisch etc - ganz im Gegenteil eher als sehr statisch mit festgefahrenen Prozessen in der Arbeitsabwicklung, die kein Denken links oder rechts des Pfades zulassen...

Sicher gilt dies nicht für alle Unternehmen, aber bei ca. 15 IT-Unternehmenskontakten in knapp einem Monat mit sehr ähnlichem Resultat lässt das doch schon ziemlich tief blicken.

Natürlich gibt es auch löbliche Ausnahmen, so z.B. QualityHosting, wo schnell und unkompliziert die Partitionierung am dedizierten Server geändert wurde oder auch bei DELL, wo ich den Preis für ein individuell konfiguriertes NAS innerhalb von einem halben Tage hatte und das zu einem Preis, der deutlich unter dem Standard-Preis auf der Website lag.

Just my 2 cents ;-)

PS: Mein Blog ist umgezogen nach http://blog.alexonasp.net

Endlich macht die das Bloggen mit dasBlog wieder richtig Spass - Windows Live Writer sei Dank!

Warum mich dasBlog zuletzt nur noch genervt hat?

• Seitdem die 1000-Blogpost-Grenze überschritten ist, ist es sehr langsam
• Der FreeTextBox-Editor läuft nicht vernünftig mit FireFox (1.x / 2.x)
• Die Sicherheitswarnungen des IE7 beim Verlinken nerven
• Die Sicherheitswarnungen des IE7 beim Einfügen per copy/paste nerven (noch mehr!)

Was mich an Windows Live Writer begeistert?

Es funktioniert einfach ;-) Sogar Updates in Postings werden korrekt behandelt.

Nach nur etwas mehr als einer Woche seit der Anschaffung hat der Samsung Q1 "Nachwuchs" bekommen: Ab sofort ist das Gerät geschützt in einer Organizer-ähnlichen Tasche für den Transport untergebracht und für längere Texteingaben mit einer USB-Tastatur (die ebenfalls geschickt in der Tasche befestigt und aufbewahrt werden kann) versehen.

Das Ganze Paket nennt sich Samsung Q1 Organizer Pack und ist z.B. hier erhältlich.

Die anfängliche Zufriedenheit ist einer andauernden Zufriedenheit gewichen ;-)

Besser so als so:

Wie man sieht, ist es für Deutschland fünf (h) nach zwölf..... und die Herrschaften sitzen immer noch beim Tee/Kaffee.

Dass der Bürger das nicht mehr will, hat sich ja zuletzt hier gezeigt.

Der DataSet Designer in Visual Studio 2005 ist im Vergleich zum DataSet Designer in Visual Studio 2003 ein echter Hit.

Allerdings finde ich, hat er einen (eigentlich zwei) ziemlich große(n) Wermutstropfen:

Szenario 1:

Zieht man eine Stored Procedure in den Designer, so hat man nach dem Rechtsklick auf die erzeugte Tabelle und den Klick auf "Configure..." folgenden Assistenten vor sich:

Hier kann man bequem die Stored Procedures für Select, Insert, Update und Delete auswählen. Diese werden dann automatisch auf die Fill bzw. GetData und Update Methoden des DataTableAdapters gemappt. Feine Sache, funktionert wunderbar.

Nachteil: erzeuge ich so mehrere Tabellen in meinem DataSet Designer, fehlen mir die Primary Keys und die Relations zwischen den Tabellen. Schade - Mehraufwand einplanen.

Szenario 2:

Zieht man eine oder mehrere Tabellen in den DataSet Designer, so hat man sofort ein DataSet mit allen Primary Keys und Relations zwischen den Tabellen:

Auch hier gilt: Feine Sache, funktionert wunderbar.

Versucht man nun allerdings, wie oben gezeigt, via "Configure...", die Stored Procedures für Insert, Update und Delete (und auch Select) zuzuweisen, wird man kläglich scheitern. Man kann zwar beliebige Stored Procedures zuweisen - diese müssen aber neuen Methoden für den DataTableAdapter zugewiesen werden, da der DataSet Designer für die Standard-Methoden SQL-Text-Statements erwartet.

Hier hilft auch kein zeitlicher Mehraufwand - das ist schlichtweg umständlich und produziert Verwirrung für den Anwender des DataSets bzw. des DataTableAdapters.

Viel besser wäre imho folgende Lösung:

Die Tabellen-Struktur sollte über Drag'n Drop von Tabellen erzeugt werden können. Somit sind alle Relations und Keys sofort verfügbar (Löschen geht immer einfach als Anlagen). Danach sollte der User sprich Developer entscheiden können, ob er auf die Standardmethoden Stored Procedures oder SQL-Statements zuweisen möchte.

Meine Meinung zu diesem Thema habe ich bereits im MSDN Product Feedback Center kundgetan.

Wer mit dieser Situation im DataSet Designer also ebensowenig glücklich ist wie ich, möge doch bitte für meinen Änderungsvorschlag voten - danke.

Bereits am 1. Mai 2005 wurde dieser Schritt bei meinem Lieblings- (und seit langem auch einzigem) Hoster vollzogen.

Bei der Gelegenheit habe ich festgestellt, dass ich bereits seit über 5 Jahren zufriedener Kunde bin. Praktisch keinerlei Ausfälle oder ungelöste Probleme / Anfragen zeigen, dass der Name Programm ist.

Gerade die Threads der letzten Tage in der ADO.NET-Liste haben mir wieder gezeigt, dass nach wie vor gilt: billig != günstig.

Milan Negovan hat den Nagel mal wieder auf den Kopf getroffen.

Seine Beobachtung, dass es zig .NET-Bücher mit allgemeinem "Bla Bla" gibt, aber fast keine In-Depth-Bücher, ist traurige Realität. Selbst da .NET 2.0 in den Startlöchern steht, habe ich z.B. noch kein Buch gefunden, das wirklich anschaulich erläutert, wie ich meinem ASP.NET Server Control einen Designer alá ASP.NET DataGrid für Visual Studio.NET spenderie.

Traurig, wirklich traurig.

herrje...

Nein, ich verabschiede mich nicht von ASP.NET ;-)

Wer sich aber verabschiedet, ist Mike Roberts - und zwar von .aspx-Seiten. Dies bedeuted allerdings nicht gleichzeitig, dass er nicht mehr mit ASP.NET arbeitet. Vielmehr verfolgt er den Ansatz, .aspx-Seiten durch eine IHttpHandler-Implementierung zu ersetzen, um so seine ASP.NET-Applikationen einfacher und testbarer zu machen, da er somit die Logik nicht mehr an zwei Stellen (deklarativ in .aspx und im CodeBehind) verwalten bzw. debuggen muß.

Der Schritt geht zugegebenermaßen sehr weit und dürfte wohl auch einigen Aufwand bedeuten, allerdings kündigt Mike Roberts ein Open Source Framework, welches diesen Ansatz verfolgt, an.

Ich finde den Ansatz insbesondere deshalb sehr interessant, da ich mir bereits häufiger die Frage gestellt habe, ob es wirklich vorteilhaft ist, Eigenschaften u.ä. von WebControls in der .aspx-Seite zu deklarieren.

Insbesondere der Ansatz bei ASP.NET 2.0, wo man via VS Designer und ohne eine einzige Zeile "echten" C# oder VB.NET-Code komplette Seiten mit Datenbindung, Menü's etc. erstellen kann, will mir nicht so recht gefallen. Zugegeben: Bis auf einige Demos habe ich mit ASP.NET 2.0 noch nichts gemacht (ok, Schande über mich ;-) ), aber ich fände den Ansatz - ähnlich wie bei Winforms bisher, die Deklaration von Objekten und deren Eigenschaften im CodeBehind über den Designer zu erledigen, angenehmer.

Imho findet durch o.g. Ansatz bei ASP.NET 2.0 eher wieder eine Vermischung von Logik und Layout statt - ein Chaos, welches dank ASP.NET endlich - zumindest bei konsequenter Anwendung von CodeBehind - beseitigt schien.

Natürlich kann man auch bei ASP.NET 2.0 noch mit CodeBehind arbeiten, aber werden nicht gerade Ein- und Umsteiger hier wieder zu "unsauberem" Arbeiten verleidet bzw. wird der Entwickler, der lieber mit CodeBehind arbeitet, nicht extrem benachteiligt (Tipp mal schön Deinen Code, Junge ;-) ) - oder gibt es in VS 2005 eine Option, die es mir erlaubt zwischen Generierung von .aspx-Code auf die Generierung von CodeBehind-Code, also C# bzw VB.NET, umzuschalten? (die Frage ist einigermaßen ernst gemeint).

Das Thema brande mir schon länger unter den Nägeln, dank Mike's Posting habe ich es nun endlich auch einmal zu Blog gebracht.

Wie seht Ihr das? Die Diskussion ist eröffnet ;-)