# Monday, September 17, 2007

Ich bin ein JavaScript Anfänger. Vor dem aktuellen Projekt gab es nur ein bisschen Html mit JavaScript als DOM Manipulator dazwischen. Echte Profis werden sicher nichts lernen können.

Ein Problem bei JavaScript ist, dass das Web voller kleiner Snippets ist, die tolle Sachen im Browser anstellen. Man findet nicht sehr viel zu den Konzepten der Sprache. JavaScript ist eine gute Ergänzung zu Html, weil es ebenso tolerant ist. Kein Compiler achtet auf die Typisierung, implizite Typkonvertierung überall.

Natürlich kann eine Sprache, die sehr schnell zu "es funktioniert" führt, auch zu unsauberem Code verleiten. Wer die Sprache konzeptionell missbraucht gerät in Gefahr, über unangenehme Randbedingungen zu stolpern, die nicht mehr funktionieren.

Ein Beispiel sind zwei sehr häufig benötigte Konstruktionen, das Array und die Hashtable.

JavaScript verfügt über ein Array Objekt das sich wie erwartet verhält. Nur ein bisschen dynamischer. So passt sich die Länge zum Beispiel automatisch an:

var testArray = new Array();
testArray[0] = "Test0";
testArray[99] = "Test99";
// Der Test liefert true:
if (testArray.length = 100)
    result = "Array Länge: 100";

Für die Hashtable gibt es aber kein entsprechendes Objekt. Aber dafür gibt es eine sehr interessante Eigenschaft von JavaScript. Alle Eigenschaften (und Methoden) eines Objekt sind, wie für eine dynamische Sprache zu erwarten, dynamisch. Können also zu jeder Zeit verändert werden. Der JavaScript Interpreter verwaltet diese Eigenschaften offensichtlich in einer Hashtable. Diese Objekt-Hashtable steht auch dem Entwickler zur Verfügung. Eine Einschränkung hat diese Objekt-Hashtable aber: Nachdem Objekt Eigenschaften benannt sind, können die Keys der Hashtable auch entsprechend nur Namen oder allgemeiner Zeichenketten sein. Genauso können natürlich als Hash Key keine Schlüsselworte des Core Objects verwendet werden (z. B: "toString").

var hashObject = new Object();
// Werte zuweisen
hashObject["key1"] = "Wert1";
hashObject["key2"] = 1234;
// Werte auslesen über Hashtable
var test = hashObject["key1"];
// Werte auslesen über Eigenschaft
var test2 = hashObject.key2
// Test, ob ein Wert vorhanden ist
if (hashObject.hasOwnProperty("key1"))
    result = "vorhanden";

Mit der for...in und der for each...in Schleife kann man ganz einfach über die Schlüsselworte oder Schlüsselwerte der Objekt-Hashtable iterieren.

for (key in hashObject)
    allKeys += key;

Bis dahin kann man das alles ganz einfach aus der JavaScript Referenz lernen. Leider liest man nicht immer die komplette Dokumentation, bevor man sich in einer neuen Sprache austobt. Google liefert zu jeder Frage sehr viele kleine Lösungen. Leider kann Google die Qualität des Codes nicht beurteilen. Schlechter Code prominent platziert führt zu neuen Programmierern mit schlechtem Stil.

Der häufigste Fehler in diesem Zusammenhang ist, dass man das Array als Hashtable verwendet:

var newHashObject = new Array();

JavaScript ist eine objektbasiert Skriptsprache und damit ist auch das Array ein Objekt. Damit funktioniert zunächst alles wie bisher. Trotzdem sollte man das so nicht machen.

Erstens leidet die Lesbarkeit. Wenn man Array definiert, erwartet man ein Array. Wenn der Zugriff dann über Variablen erfolgt, ahnt man vielleicht nicht, dass gar keine Array Indizes, sondern Hashtable Keys verwandt werden:

var result = hashObject[item];

Ist item ein Integer, mit dem auf das Array zugegriffen wird? Oder ist item ein String, mit dem auf eine Objekt Eigenschaft zugegriffen wird?

Auch der Entwickler kann sich selbst verwirren. Die Länge des Arrays wird über length abgefragt. Missbraucht man das Array als Objekt-Hashtable liefert length natürlich den falschen Wert (0).

Richtig ärgerlich wird es aber dann bei dem in Operator, der unter anderem in den Schleifen zum Einsatz kommt. Eigenschaften der vordefinierten Core Objekte werden dabei nicht ausgegeben. Nur per Code definierte Eigenschaften werden berücksichtigt, dafür aber über die ganze Prototypen Hierarchie (JavaScripts quasi Vererbung).

Ich wollte zum Beispiel das Array per Prototype um eine contains Methode erweitern.

Array.prototype.contains = function(element) 
{
    for (var i = 0; i < this.length; i++) 
    {
        if (this[i] == element) 
        {
            return true;
        }
    }
    return false;
};

Diese Erweiterung funktioniert toll. Nur jedes Array hat jetzt ein weiteres Hash Element mit dem Key contains. Bei einer Schleife wird dieses Element mit ausgegeben. Und zwar bei jeder Objekt-Hashtable, die fälschlicherweise mit "new Array" statt "new Object()" definiert wurde.

Merke: Kein Array verwenden, wenn eigentlich nur ein Object gebraucht wird!

Monday, September 17, 2007 1:21:25 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Friday, September 14, 2007

Die Strichmännchen leben weiter gefährlich!

Wie ich inzwischen erfahren habe, ist die englische Übersetzung von Strichmännchen nicht notwendig Stickmann, auch Stick Figure ist möglich. Mit diesem neuen Wissen konnte ich weitere Abenteuer der kleinen Kerle aufspüren: Stick Figures in Peril auf Flickr.

Zum Zeitpunkt dieses Eintrags waren dort bereits unglaubliche 10.308 Bilder abgelegt! Da müssen wir mit unseren paar Varianten richtig bescheiden bleiben. Alleine auf diesem Bild finden sich unglaubliche Gefahren:

stick_figure_in_peril

Und als Abschluss diesen gefährlichen Hechtsprung in Untiefen. "Es hat sich bereits ein Krater gebildet, von all den Strichmännchen die an der gleichen Stelle aufprallen."

submerged_rocks

Blah | TD
Friday, September 14, 2007 8:48:12 AM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Tuesday, September 11, 2007

Ich radle fast täglich am Münchner Olympiastadium vorbei. Das Stadium wurde anlässlich der Olympischen Sommerspiele 1972 erbaut. Was man vielleicht nicht weiß, dass mit dieser Olympiade die jedem bekannte Zeichensprache der modernen Piktogramme entstand:

Fussball piktogramm

Otl Aicher hat alle vertretenen Sportarten und das komplette Leitsystem dieser Olympiade entworfen. Bei Erco liegen die Rechte und wenn die Webseite funktionieren würde, könnte man sich auch über den heutigen Stand der Bildersammlung informieren.

Im Rahmen der Gestaltungsarbeit für das visuelle Erscheinungsbild der XX. Olympischen Spiele in München im Jahre 1972 entwickelte der Grafiker Otl Aicher, einer der Mitbegründer der Ulmer "hochschule für gestaltung", erstmals eine systematisch aufgebaute Zeichensprache. Ein umfassendes und komplexes Repertoire von Bildzeichen diente dazu, ein internationales und vielsprachiges Publikum zu den diversen Veranstaltungsorten zu leiten und mit relevanten Informationen zu versorgen.

Am weitesten hat es das in den damaligen Piktogrammen verwandte, Strichmännchen gebracht. 1972 durfte es sich noch bei diversen sportlichen Aktivitäten stärken. Heute begegnet es uns eher in vielen gefährlichen Situationen. Manchmal zeigt es uns auch, wie wir uns richtig verhalten sollen.

Im Rahmen der Technischen Dokumentation schicken wir von CPTec das Strichmännchen regelmäßig von einem gefährlichen Abenteuer zum nächsten:

falling hazard fork lift hazard bruising hazard

Die Erholungsphasen sind kurz und dringend benötigt:

Shower mandatory

Inzwischen gibt es sogar eine Sammlung seiner wichtigsten Einsätze!

Das deutsche Strichmännchen gibt es auch als englischen Stickman, dem es aber auch nicht besser ergeht. Überall lauert die Gefahr. Jetzt auch als reflektierende Aufkleber:

 stickman_in_peril

stickman_in_officeland

 

Gefunden über Rick Strahl - Stickman in Peril :)
Blah | TD
Tuesday, September 11, 2007 1:46:52 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Thursday, September 06, 2007

Ein Spruch, der sich immer wieder bewahrheitet:

Daten leben länger als die Programme, die die Daten erzeugen

Mein Fall ist nicht so drastisch, das Programm, das die Daten erzeugen kann, lebt noch. Eine Visual Foxpro Applikation hat die Daten erzeugt, eine .NET Applikation soll jetzt damit weiter arbeiten.

Über den Visual FoxPro OLE DB Provider kann man direkt auf die VFP Daten zugreifen. Die restliche Logik kann in der inzwischen eher vertrauten Visual Studio Umgebung programmiert werden:

            string connectionString = "Provider=vfpoledb.1;Data Source=c:\\data.dbc";
            OleDbConnection connection = new OleDbConnection(connectionString);
            connection.Open();
            string selectCmd = "SELECT * FROM table";
            OleDbCommand command = new OleDbCommand(selectCmd, connection);
            OleDbDataReader reader = command.ExecuteReader();
            while (reader.Read())
            {
                // Daten verarbeiten
            }
            reader.Close();
            connection.Close();

Wenn die VFP Anwendung bereits eine saubere Business Schicht implementiert hätte, wäre es besser, auf dieser Ebene die Informationen auszutauschen und nicht auf die rohen Daten zuzugreifen. Ist aber hier nicht der Fall.

Wenn kein Visual Foxpro installiert ist, sollte obiger Download genügen um den OLE DB Provider zu installieren. Unter Vista x64 klappt die Installation zwar problemlos. Nur der Treiber ist eine reine 32Bit Anwendung und Visual Studio erzeugt normalerweise Code für Any CPU. Dieser Code läuft auf einem 64Bit OS, dann entsprechend als 64Bit Anwendung. Der Versuch auf vfpoledb zuzugreifen scheitert:

The 'vfpoledb.1' provider is not registered on the local machine.

Die einzige Lösung, die ich kenne, ist die komplette Solution auf Platform target x86 zu schalten:

VS Build Configuration Manager

Jetzt funktioniert der Zugriff auf die VFP Daten einwandfrei.

Wieder holt einen die Vergangenheit ein und das tolle neue System kann nicht so agieren wie es möchte. Aber das ist der Preis, wenn man nicht alles immer neu erfinden will.

Thursday, September 06, 2007 2:16:56 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Wednesday, September 05, 2007

Gehört hatte ich schon öfters von dem Foxit Reader: Einem kleinen, schnellen Ersatz für den Adobe Acrobat Reader. Aber in einigen Applikation verwende ich den Acrobat Reader als Komponente zur PDF Darstellung. Das heißt der Acrobat Reader ist ohnehin notwendig auf meinem Rechner installiert. Auch selbst erzeugte PDFs sollen in erster Linie im Acrobat Reader funktionieren. Da hilft Foxit nicht viel.

Und so schlimm empfand ich das Original von Adobe dann auch nicht, dass der mentale Aufwand für einen weiteren PDF Reader gerechtfertigt war. Jetzt beschäftige ich mich bei einem aktuellen Projekt intensiver mit der Adobe Acrobat Linie und der zugehörigen SDK. Auf einmal benötige ich einen zusätzlichen PDF Reader. Wieso kann man nicht mit den Adobe Tools alleine die Aufgabe lösen?

Das Problem liegt in der Architektur von Adobe Acrobat Professional und dem Adobe Reader. Es ist vielleicht schon aufgefallen, dass wenn man einmal ein PDF mit einem der beiden geöffnet hat, das andere Tool nicht mehr funktioniert. War der Reader offen, geht kein Acrobat Professional mehr und umgekehrt. Klemmt irgendwie eine (scheinbare) Instanz der Tools, geht gar nichts mehr. Auch wenn mehrere Acrobat Fenster offen sind und eines einen modalen Dialog darstellt, geht im anderen Fenster nichts mehr.

Das fällt vielleicht normalerweise nicht auf, aber wer die SDK Dokumentation noch nicht auswendig kann, wird sich wundern: Man öffnet den JavaScript Editor in Acrobat und möchte seinen Code bearbeiten. Natürlich ließt man parallel die API Dokumentation. Nur was macht der arme Entwickler mit einer PDF Dokumentation, während er in einem PDF arbeitet? Gar nichts, zumindest nicht mit Adobe-Mitteln. Erst wenn man den Editor beendet, erwacht Acrobat wieder und die Dokumentation steht zur Verfügung. Nur wer vorher die richtige Seite in der SDK geöffnet hat, kann Code und Erklärung gleichzeitig studieren.

Die einfachste Lösung war für mich, den Foxit Reader für die Adobe Acrobat SDK zu verwenden. Ironie des großen Softwarehauses.

  Foxit Reader
Wednesday, September 05, 2007 1:18:51 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Monday, August 27, 2007

JavaScript ist eine dynamische Sprache. Der Code wird nicht kompiliert sondern zur Laufzeit interpretiert. Dadurch wird unter anderem die eval Funktion ermöglicht, die innerhalb eines Skripts einfach JavaScript Code als Parameter entgegen nimmt und ausführt.

Im .NET Framework gibt (gab) es eine Variante von JavaScript: JScript. Damit sollte es möglich sein, aus einem C# Programm heraus diese JScript Funktion aufzurufen. Und tatsächlich ist dies sogar sehr einfach möglich. Man muss sich nur darüber im klaren sein, dass das nur eine Übergangslösung ist.

Aus MSDN VsaEngine:

Use of this type is not recommended because it is being deprecated in Visual Studio 2005; there will be no replacement for this feature. Please see the ICodeCompiler documentation for additional help.

In .NET 3.0 ist es damit bereits Schluss. In Zukunft wird wohl eher die Dynamic Language Runtime DLR dafür verwendet.

Das hilft mir aber jetzt nichts. Die einfachste Lösung habe ich in einem Kommentar zu einem Blog-Eintrag von Rick Strahl gefunden: Evaluating JavaScript code from C#

Man erzeugt sich eine JScript Dll:

  1. Mit Notepad eine Datei mit folgendem Text erzeugen:
    class EvalClass { function Evaluate(expression: String) { return eval(expression, "unsafe"); } }
  2. Die Datei als C:\MyEval.js speichern.
  3. Einen VS2005 Command Prompt (Start, Programs, VS2005, VS2005 Tools) öffnen.
  4. Auf C:\ wechseln.
  5. Folgenden Befehl absetzen:
    jsc /t:library C:\MyEval.js
  6. Es wird eine neue Datei mit dem Namen MyEval.dll erzeugt.
  7. MyEval.dll in das gewünschte C# Projekt kopieren und referenzieren. Zusätzlich muss noch Microsoft.Jscript.dll referenziert werden.
  8. So kann jetzt die JavaScript Eval Funktion aufgerufen werden:
    EvalClass evalClass = new EvalClass();
    object result = evalClass.Evaluate("2+3");

 

Das  funktioniert wirklich so einfach und gut. Was ich später noch ändern musste, war der zusätzlich String Parameter "unsafe" bei der JScript eval Funktion. Ohne diesen Parameter gibt es eine Security Exception, wenn der übergebene JavaScript Code eine neue Funktion deklariert.

Monday, August 27, 2007 10:57:25 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Wednesday, August 22, 2007

Früher waren Webseiten in HTML codiert und animierte Gifs haben für ein bisschen Bewegung gesorgt. Ein paar besonders tolle Entwickler konnten per JavaScript Bilder austauschen, wenn sich der Mauszeiger darüber bewegt hat. Daten wurden in ein Formular eingegeben und per Submit an den Server übertragen. Damals war alles aus heutiger Sicht überschaubar.

Das Web 2.0 hat uns AJAX und damit den nach Hause telefonierenden, per JavaScript programmierten Browser gebracht. Damit erstellte Webanwendungen stehen in ihrer Funktionalität in manchen Bereichen Desktop Applikationen in nicht mehr nach. Aber ohne JavaScript geht auf diesen Seiten gar nichts mehr.

Gleichzeitig können fast alle neueren Browser-Schwachstellen mit deaktiviertem JavaScript umgangen werden. Also ohne JavaScript ist man sicherer, aber es funktioniert nicht mehr sehr viel. Was tun?

noscript_logo

NoScript ist ein Firefox Add-on, dass es ermöglicht JavaScript in Abhängigkeit der besuchten Webseite an- und abzuschalten. Bei der ersten Installation ist JavaScript auf allen Webseiten verboten. Besucht man vertrauenswürdige Seite, die JavaScript benötigt, kann man die Ausführung von JavaScript erlauben und NoScript merkt sich diese Einstellung. Im Laufe der Zeit erstellt man sich damit eine eigene Whitelist der erlaubten Seiten und bemerkt NoScript dann eigentlich nicht mehr.

NoScript ermöglicht es auch, JavaScript generell wieder zu aktivieren. Dieser Versuchung sollte man aber widerstehen.

Inzwischen sind noch ein paar weitere Funktionen für ein sichereres Browsen in NoScript implementiert worden. Es können Java, Flash und andere Plug-ins von nicht vertrauenswürdigen Seiten blockiert werden. Auch gegen Cross-Site Scripting (XSS) Angriffe versucht NoScript zu schützen.

Ich selbst verwende seit einiger Zeit NoScript und würde nicht mehr ohne diese zusätzliche Sicherheit surfen. Diese Woche hat hier bei CPTec ein Kollege einen Virus in Quarantäne geschickt. In den eher dubiosen Ecken des WWW hat unser Virenscanner in seinem HTTP Traffic den Bösewicht entdeckt. Noch mal Glück gehabt. Aber selbst bei täglichen Updates der Patterns ist die Scan Engine potentiell immer zu langsam für den jeweils neuesten Schädling. Jetzt wird bei uns NoScript zur Pflichtinstallation.

Wednesday, August 22, 2007 10:26:45 AM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Monday, August 20, 2007

Innerhalb der Acrobat Welt gibt es einige Integrations-Technologien von Adobe: Für die PDF Erzeugung ist die teure, exklusive PDF Library sicher am Besten geeignet und Plug-Ins schreibt man eher mit der Acrobat SDK in C. Für Interaktionen und einfache Automatisierungen im PDF Dokument ist JavaScript gedacht.

Eine standardisierte Skriptsprache (ECMA) auf dem Niveau von JavaScript ist sicher besser als zum Beispiel VBA (Visual Basic for Applications), mit dem man in Microsoft Office seit Jahrzehnten (ab 1995) seine Makros bastelt. Adobe hat eine dynamische, objektorientierte und modernere Sprache gewählt. Aber manches ist bei VBA besser gewesen.

Ich weiß jetzt nicht mehr, wann ich das erste mal den Microsoft VBA Editor geöffnet hatte. Es ist sehr lange her,  aber IntelliSense war damals schon vorhanden. Auch war der Code in Abhängigkeit von seiner Eigenschaft farbig markiert. Syntax highlighting nennt man das im Englischen. Was hat Adobe da zu bieten?

Acrobat JavaScript Editor

So sieht also der JavaScript Edit in Acrobat aus. Ganze 3 Buttons, farbloser Text, keinerlei Code Unterstützung und auch keine kontextsensitiven Menüs. Zum Glück kann man in den Eigenschaften einen externen Editor angeben. Am Besten einen, der JavaScript kennt.

Ohne externen Editor geht es bei längerem Code auch gar nicht mehr:

Adobe Acrobat Error

Nun quält der Microsoft Visual Studio verwöhnte Entwickler sein JavaScript irgendwie in die PDF Datei und macht dabei einen Fehler. Fehler machen gehört dazu, der Debugger hoffentlich auch.

Acrobat JavaScript Debugger

Das ist im Vergleich zum Editor jetzt fast schon eine überladene Benutzeroberfläche. Oben links finden sich die Buttons zur Ablaufsteuerung: Resume Execution, Interrupt, Quit, Step over, Step into, Step out

Dazu gibt es keine mir bekannten Hotkeys. Also fleißig mit der Maus die kleinen Knöpfchen angepeilt. Ist man an einer interessanten Stelle im Code angelangt, will man natürlich in das Code Fenster wechseln. Wer versucht mit Tabulator-Taste das aktive Steuerelement zu wechseln ist natürlich zu sehr von einem Windows Standard geblendet. Dieser Dialog will die Maus bewegt sehen!

Aber jetzt kommt der Clou! Zwischen dem aktuellen Skript und den obigen Buttons liegt ein Fenster mit der Skript Hierarchie:

Adobe_JavaScript_Debugger

Na gut, so ist das nun mal, irgendwo muss die Maus ja immer drüber. Denkste! Das Steuerelement im rot markierten Bereich hat Hot Tracking aktiviert. Die bloße Berührung mit dem Mauszeiger lässt den Code an die entsprechende Stelle springen. Weg ist der Kontext. Also die Übung wiederholen und diesmal die Maus im weiten Bogen bewegen. Na also geht doch!

Acrobat_Debugger_LineColumn

Im unteren Teil werden zwei Textboxen und einmal die aktuelle Zeile und Spalte angezeigt. Aber Vorsicht, die Anzeige gehört nur zur unteren Textbox, zur Console. Die aktuelle Zeile im Script-Fenster muss man selber zählen. Wer gut im Raten ist, kann auch das kleine Gitter # anklicken und zu einer Zeilennummer springen.

Puh! Diese kleine Lästerei musste jetzt sein. Das Nervenkostüm und die Produktivität leidet in der Adobe Welt aus meiner Sicht sehr. Ich erwarte ja keine Visual Studio oder Eclipse Umgebung, aber diesen Dialog verwendet Adobe-Intern sicher niemand. Heute will man doch eigentlich in der eigenen Infrastruktur externe Entwickler fördern. Das ist gut für das Hauptprodukt. Microsoft ist da meines Erachtens ein paar Schritte weiter.

Monday, August 20, 2007 10:42:57 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Friday, August 17, 2007

 Eine neue Version von dieser ASP.Net Blog Engine wurde veröffentlich:

Version 2.0 of dasBlog is released, and dasBlog goes ASP.NET 2.0 (with medium trust).

Das Update lief eigentlich problemlos. Lediglich die Anzeige bisheriger Aktivitäten funktioniert nicht. Alte Log Dateien werden gezippt gespeichert und irgendwie klemmt etwas mit der Auswertung dieser gezippten Dateien. Ich habe nach einer Lösung gesucht, aber bis zum Source Code und Debugger hat mich das Problem nicht gequält. So oft schau ich mir die Auswertung nicht an.

dasBlog

Friday, August 17, 2007 1:28:02 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Tuesday, August 14, 2007

Die Überschrift ist kein Roman, sondern, auch wenn die Länge es nicht erahnen lässt, eine Erweiterung der Team Edition for Database Professionals. Microsoft setzt damit die Tradition fort, dass es zu vielen Produkten ein paar kostenlose Erweiterung direkt aus den Entwickler Teams gibt. Über diese Power Tools kann Microsoft auch zwischen den großen Release Zyklen neue Funktionen veröffentlichen:

Microsoft® Visual Studio® 2005 Team Edition for Database Professionals Service Release 1 (Voraussetzung für die Power Tools)

Microsoft® Visual Studio® 2005 Team Edition for Database Professionals Power Tools

Details zu den neuen Funktionen gibt es beim DataDude:

    • Dependency Viewer
    • Refactoring
      • Move Schema
      • Expand Wildcard
      • Fully Quality Name
      • Refactor in to strongly typed DataSet definitions
      • Refactor Command Generator
    • Data Generation
      • Sequential Data Bound Generator
      • Editors for the Data Bound Generator, Sequential Data Bound Generator and RegEx String Generator to make configuration easier
      • The RegEx editor also tries to interpret your CHECK CONSTRAINTs and create a matching RegEx expression that you can use to generate data values that match the constraint definition
      • The RegEx editor can also be used for interactively defining and testing RegEx expressions and evaluate the output visually, which makes it a lot easier to create the right RegEx expression for your value domain.
    • MSBuild Tasks
      • SqlSchemaCompareTask; allows you to compare schemas between two database from the command line using MSBuild.
      • SqlDataCompareTask; allows you to compare the content of tables within two databases from the command line using MSBuild.
    • T-SQL Static Code Analysis
    •  Miscellaneous tools
      • SQL script pre-processor command-line utility, which will expand all SQLCMD includes and variable definitions (sqlspp.exe)
    • Schema Manager API

 

Vorsicht: Nach diesen Updates werden Database Projekte beim ersten Öffnen durch einen Wizard konvertiert und sind dann für ältere Versionen von Visual Studio unbrauchbar.

Viel gespielt habe noch nicht mit den Tools:

Die statische Code Analyse hat mir aber schon mal 66 Warnings in einem Projekt ausgespuckt. Keine dramatischen Verfehlungen, aber leider funktioniert bei mir die "Show Error Help" Funktion nicht. Auch die ausgegeben IDs findet Google noch nicht. Mir fehlen also die Erläuterungen zu den Ausgaben.

Der Schema Dependency Viewer gefällt mir auch sehr gut. Als CodeRush Anwender ist man von dessen References Viewer im C# Code aber verwöhnt. Einfach Shift+F12 und alle Referenzen werden blitzartig dargestellt. Das Gleiche im T-SQL Editor wäre super. Bis dahin dürfen wir jetzt wenigstens schon mit der Maus im Schema Viewer das Kontext Menü aufrufen.

Tuesday, August 14, 2007 11:10:41 AM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  |