Tips und Tricks

SQL Server 2008 Express und Windows Server 2008 64 Bit

Andre — Fri, 22 Jan 2010 16:56:13 GMT

Ende November mietete ich mir einen Windows 2008 64 Bit VServer, auf dem ich einige Websites hosten wollte.

Einer der ersten Schritte nach der Freischaltung war die Installation des SQL Server 2008 Express inkl. Management Studio Express.

Nun ja, zumindest versuchte ich dies. Denn leider war weder eine manuelle Installation der SQL Server Express 64 Bit Variante erfolgreich, noch half der Weg über den Web Plattform Installer.

Statt dessen bekam ich folgende Fehlermeldung:

Der Befehlszeilenwert INSTANCESHAREDWOWDIR ist ungültig. Stellen Sie sicher, dass der angegebene Pfad gültig und nicht identisch mit dem Pfad für INSTANCESHAREDDIR ist.

Eine kurze Recherche im Netz ergab, dass dieses Problem auf IA64 Systemen auftritt, wenn man den SQL Server nicht im Standardpfad installiert. Als Abhilfe solle man das INSTALLSHAREDWOWDIR als Befehlszeilenparameter setzen.

Interessant, aber ich habe ein X64 System und wollte im Standardpfad installieren. Also scheint die Ursache doch eine andere zu sein.

Was anschließend folgte, waren endlose Nächte in denen ich versuchte den SQL Server zu installieren. Der Trick mit dem Befehlzeilenparameter brachte mich zwar über die Fehlermeldung, dafür konnte ich dann aber weder das SP1 noch das Management Studio Express installieren. Deinstallieren ging auch nicht mehr, denn auch dann kam die Meldung:

Der Befehlszeilenwert INSTANCESHAREDWOWDIR ist ungültig. Stellen Sie sicher, dass der angegebene Pfad gültig und nicht identisch mit dem Pfad für INSTANCESHAREDDIR ist.

Also hieß es nach jeder erfolglosen Installation erst mal: Windows 2008 Server neu installieren (lassen).

Mittlerweile war ich schon kurz davor aufzugeben. Glücklicherweise fand ich folgende Seite:

http://www.cannontrodder.net/2009/07/24/sql-server-2008-x64-on-windows-server-2008-x64-is-utterly-broken/

Hier hatte jemand das exakt gleiche Problem. Im Gegensatz zu mir hatte er jedoch eine Lösung gefunden, die die Installation des SP1 und des Managent Studios erlaubten.

Alles in allem sah meine Vorgehensweise zur Installation des SQL Servers auf einem nackten Windows 2008 System (außer vorinstalliertem PLESK und der VC++ 2005 Runtime war sonst nix drauf) wie folgt aus:

.NET Framework 3.51 herunterladen und installieren
Powershell als Feature im Server Management aktivieren
SQL Server 2008 Express With Tool 64 Bit herunter laden (SQLEXPRWT_x64_DEU.exe)
Starten des Setups, Verzeichnis in das das Setup entpackt wird notieren
Setup Bildschirm geöffnet lassen, jedoch nichts klicken
Öffnen eines Command-Prompts
Navigation in das zuvor notierte Verzeichnis
Eingeben der folgenden Befehlszeile: setup /action=install /INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server\\" /INSTALLSHAREDWOWDIR="C:\Program Files\Microsoft SQL Server Shared\\"
Wizzard durchklicken
Download des Sql Server 2008 SP 1 64 Bit (SQLServer2008SP1-KB968369-x64-DEU)
Starten des SP 1 Setups (lief ohne Probleme)

Ich hoffe, dass ich anderen, die mit dem selben Problem kämpfen mit diesem Eintrag helfen kann!

An dieser Stelle auch noch mal vielen Dank an die Entwickler und Testabteilung des SQL Server 2008 Setups. Ohne euch hätte ich gar nicht gewusst, was ich an den vielen Abenden machen soll ...

Client Scripte mit ASP.NET 3.51 zusammenfassen

Andre — Thu, 14 Jan 2010 11:16:22 GMT

Jeder der in einer ASP.NET Webforms Anwendung ein oder mehrere "Ajax-Enabled" Controls eines Komponentenherstellers nutzt kennt das Problem: Die Anzahl der zum Client übertragenen Scripte steigt explosionsartig an.

Dies liegt daran, dass die meisten Komponentenhersteller je Control ein eigenes Script zum Client senden. Generell ist das auch durchaus sinnvoll, denn nur so kann gewährleistet werden, dass der Browser nur die minimal benötigte Anzahl an Scriptcode vom Server herunterladen muss.

Wie der folgende Screenshot zeigt, wird dieser Segen jedoch auch schnell zum Fluch. Die Abbildung zeigt einen Mitschnitt des Netzwerktraffics beim Besuch einer Seite eines aktuellen Projekts. Inhalt der Seite sind ein Scriptmanager, zwei Infragistics Controls, einige ESRI WebADF Controls sowie ein paar eigene Servercontrols, die auch eigene Scripts rendern.

Die Anzahl zu übertragenden Scripts beträgt laut Screenshot also 37 Stück.

Interessant, aber wo liegt nun das Problem?

Wir wissen zwar nun, dass wir 37 Scripte zum Client übertragen müssen, aber was ist daran so schlimm und warum sollte es uns überhaupt interessieren?

Um das Problem an der Situation zu erkennen, sollten wir uns kurz vor Auge führen, dass die Scripte nicht gemeinsam innerhalb des selben HTTP Requests wie die eigentliche Website übertragen werden. Stattdessen wird je Script (und auch Bild, CSS Stylesheet, etc.) eine eigene Anfrage an den Webserver gestellt.

Jede dieser Anfragen hat eine gewisse "Rüstzeit" oder auch Latenz. Damit ist die Zeitspanne gemeint, die zwischen dem Absetzen des Befehls, eine Anfrage zu starten und dem tatsächlichen Start der Anfrage vergeht. Je nach Entfernung zwischen Client und Server sowie der Qualität der Internetanbindung der beiden variiert der tatsächliche Wert dieser Reaktionszeit.

Und was bedeutet dies nun konkret?

Schauen wir uns zur Verdeutlichung ein kleines Beispiel an. Gehen wir von jemandem mit einer extrem schlechten Anbindung und einer Latenz von 500 ms aus (zugegeben, der Wert ist recht hoch, lässt sich aber schön einfach rechnen ;-))

Um unsere 37 Scriptdateien herunterzuladen, hätten wir nun also

37 Anfragen * 500 ms Latenz + 37 Antworten * 500 ms Latenz = 37 Sekunden.

Diese 37 Sekunden sind reine Wartezeit und kommen zur eigentlichen Übertragungszeit der Scripte hinzu. Nun ist es natürlich nicht so, dass sämtliche Anfragen sequentiell abgearbeitet werden. Allerdings sieht die Standardkonfiguration vieler Browser eine Beschränkung von zwei gleichzeitigen Verbindungen zu einem Hostnamen vor. Diese Anzahl resultiert aus einer Empfehlung der HTTP 1.1 Spezifikation. Heisst, wir müssen unsere 37 Sekunden noch durch zwei Teilen, da zwei gleichzeitige Verbindungen möglich sind. Bleiben immer noch 18,5 Sekunden übrig.

Was können wir dagegen tun?

Um dieses Problem, was tückischerweise während der Entwicklung nur selten auffällt, da die Latenz zwischen lokalem Webserver und lokalem Webbrowser nicht sonderlich hoch sein dürfte ;-), in den Griff zu bekommen, bietet ASP.NET ab der Version 3.51 das Element CompositeScript als Kindelement des Scriptmanagers an.

Dieses Element erlaubt es, einzelne Scripts anzugeben, welche anschließend automatisch zu einem Script zusammengefasst werden.

Das Ganze sieht ungefähr so aus:

<asp:ScriptManager runat="server" ID="sm1">
    <CompositeScript>
        <Scripts>
            <asp:ScriptReference Name="/Scripts/MeinScript1.js" />
            <asp:ScriptReference Name="/Scripts/MeinScript2.js" />
            <asp:ScriptReference Name="/Scrips/MeinScript3.js" />
        </Scripts>
    </CompositeScript>
</asp:ScriptManager>

Problematisch ist nur, dass man die URL der notwendigen Scripts nur für Dateibasierte Scripts kennt. Sobald ein Script aber als eingebettete Ressource über die Webresource.axd nach aussen gerendert wird, ist die URL unbekannt.

Um dieses Problem zu lösen, kann das auf Codeplex erhältliche Control ScriptReferenceProfiler genutzt werden. Wird es auf einer Seite eingesetzt, rendert es eine Liste aller genutzten Scripte heraus. Diese Liste kann 1:1 kopiert und in das Scripts Element des CompositeScript Elements eingefügt werden.

Die eingefügten Scripts werden anschließend serverseitig zu einem großen Script hinzugefügt und innerhalb einer einzigen Anfrage herunter geladen.

Nicht so schnell!

Der Versuch, alle 37 Scripte der zuvor genannten Seite in einem CompositeScript Element zusammen zu führen resultiert in folgendem Fehler:

Die Ursache für diesen Fehler ist, dass der Scriptmanager jedes benötigte Script mit einem kryptischen Bezeichner an die URL anhängt. Dies sprengt schnell die maximale Begrenzung einer URL auf 1024 Zeichen.

Die Lösung

Um dieses Problem zu umgehen platziert man einfach mehrere CompositeScript Elemente auf der Seite und verteilt die Scripte auf diese. Da jedes CompositeScript Element einen eigenen Scriptmanager benötigt, nutzt man ab dem zweiten CompositeScript Element statt zusätzlichen Scriptmanagern, von denen es immer nur einen pro Seite geben darf einfach ScriptmanagerProxy Controls.

Die optimale Verteilung der Scripte auf die einzelnen CompositeScript Elemente ist schnell im Trial-and-Error-Verfahren gefunden. In meinem Beispiel sah sie übrigens wie folgt aus:

<asp:ScriptManagerProxy ID="ScriptManagerProxyAjax" runat="server">
    <CompositeScript>
        <Scripts>
            <asp:ScriptReference Name="MicrosoftAjax.js" />
            <asp:ScriptReference Name="MicrosoftAjaxWebForms.js" />
            <asp:ScriptReference Name="AjaxControlToolkit.Common.Common.js" Assembly="AjaxControlToolkit, Version=3.0.30512.20315, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" />
            <asp:ScriptReference Name="AjaxControlToolkit.Compat.Timer.Timer.js" Assembly="AjaxControlToolkit, Version=3.0.30512.20315, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" />
            <asp:ScriptReference Name="AjaxControlToolkit.Compat.DragDrop.DragDropScripts.js"                 Assembly="AjaxControlToolkit, Version=3.0.30512.20315, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" />
            <asp:ScriptReference Name="AjaxControlToolkit.Animation.Animations.js" Assembly="AjaxControlToolkit, Version=3.0.30512.20315, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" />
        </Scripts>
    </CompositeScript>
</asp:ScriptManagerProxy>

<asp:ScriptManagerProxy ID="ScriptManagerProxyInfragisticsCommon" runat="server">
<CompositeScript>
<Scripts>

...
</Scripts>
</CompositeScript>
</asp:ScriptManagerProxy>

...

Gerade wenn man sich mit einem Element nahe an der 1024 Zeichen Grenze befindet, sollte man jedoch im Hinterkopf halten, dass die tatsächliche Url der Seite später meist nicht mehr http://localhost ist, sondern eher http://meinesubdomain.meinedomain.de. Durch die Änderung des Hostnamens während der Produktivsetzung ändert sich also eventuell noch einmal die Länge der URL. Daher im Zweifelsfall lieber ein Script weniger als in der Entwicklungsumgebung möglich in die CompositeScript Tags einfügen.

Es müssen übrigens nicht alle Scripts in CompositeScript Tags gepackt werden. Solche, die nicht verpackt wurden, werden wie gehabt ganz normal weiter als einzelner Script Tag zum Browser herausgerendert.

Und was bringts nun?

Tja, was bringt der ganze Aufwand nun? Da Bilder bekanntlich mehr als Worte sagen, hier ein paar Vorher/Nachher Screenshots der zuvor vorgestellten Seite:

Initial hat die Seite 37 Scripts heruntergeladen.

Yahoo's YSlow gab der Seite eine Gesamtnote von E.

Die Ladezeit betrug knapp 15 s, die Gesamtgröße 734 kb.

Nach den Änderungen wurden nur noch 9 Scripte referenziert.

Die YSlow Benotung stieg immerhin von E auf D.

Die Ladezeit reduzierte sich auf knapp 5 s, die Gesamtgröße auf 655 kb.

Prüfen, ob sich ein Webpart im Design Modus befindet

Andre — Thu, 17 Sep 2009 10:29:23 GMT

Während der Webpart Entwicklung kann es nützlich sein, zu wissen ob man sich gerade im Webpart Design Modus befindet. Folgender Codeausschnitt zeigt, wie man an diese Information kommt:

        protected bool IsDesignMode()
        {
            bool designMode = true;
            if (this.Page != null)
            {
                WebPartManager wp = WebPartManager.GetCurrentWebPartManager(this.Page);
                if (wp != null)
                {
                    designMode = (wp.DisplayMode != WebPartManager.BrowseDisplayMode);
                }
            }
            return designMode;
        }

Hilfreich ist dies zum Beispiel, um Validatoren während des Design Modus abzuschalten.

Meine drei Top Entwicklertools

Andre — Thu, 04 Jun 2009 22:59:41 GMT

Ich weiß, ich bin spät, aber zum Glück noch nicht zu spät. MSDN Deutschland hat zur Blog-Parade aufgerufen und fragt nach den drei Lieblings-Entwickler-Tools.

Nachdem Mario, Alex, Jan und viele andere auch schon mit gemacht haben, möchte ich meinen Senf selbstverständlich auch zum Besten geben.

Das Visual Studio zur Grundausstattung eines Entwicklers gehört setze ich mal voraus und lasse es daher außen vor. Nun aber zu meinen Top 3.

Microsoft WinDbg

Ich kann gar nicht aufzählen, wie oft mir dieses Tool schon in unangenehmen Situationen geholfen hat.
Wer kennt die Situation nicht:
- Man entwickelt eine Applikation
- Auf dem Entwicklungs- und Testsystemen läuft Sie großartig
- Beim Kunden stürzt sie ab
- Man hat weder eine vernünftige Fehlermeldung, noch einen aussagekräftigen Eintrag in der Log-Datei
- Der Fehler ist bei uns nicht nachvollziehbar
- Wir dürfen mit unserem PC nicht ins Kundennetz und Visual Studio oder CoreDbg dürfen wir dort auch nicht installieren
- „Pech gehabt, lieber Kunde“ oder wirres Code-Ändern ist keine valide Option ;-)
Wenn es so weit ist, hilft nur noch ein ganz tiefer Griff in die Werkzeugkiste, nämlich der zu WinDbg. Für diejenigen, die ihn nicht kennen: WinDbg ist ein unmanaged (native) Debugger mit grafischer Benutzeroberfläche. Dank der SOS Erweiterung kann man ihn jedoch wunderbar dazu verwenden, auch managed Code zu debuggen. Zugegeben, der Komfort liegt etwas hinter dem des in Visual Studio integrierten Debuggers, aber in der Not nimmt man schließlich, was man bekommen kann. Das tolle an diesem Debugger ist nämlich, dass er nicht installiert werden muss, sondern direkt vom Stick gestartet werden kann. Außerdem "sieht" er etwas mehr als der in VS integrierte Debugger, denn schließlich ist er ja eigentlich ein unmanaged Debugger. Bei Interesse könnte ich mich übrigens dazu verleiten lassen, mal ein WinDbg Einsteiger Tutorial zu schreiben, oder zumindest mein "Cheat-Sheet" hier aufs Blog zu packen. Also einfach die Kommentarfunktion dieses Eintrags nutzen!
Infragistics NetAdvantage

»Für den ersten Eindruck gibt es keine zweite Chance« lautet ein geflügeltes Wort. Dass Menschen einander innerhalb weniger Augenblicke beurteilen, ist allgemein bekannt. Da diese Beurteilung vor allem anhand optischer Gesichtspunkte statt findet, achten viele Menschen heutzutage in besonderem Maße auf ihr Äußeres. Nur so lassen sich wichtige erste Begegnungen, wie zum Beispiel ein Vorstellungsgespräch, erfolgreich meistern.
Ähnlich wie das menschliche Äußere bei einem Vorstellungsgespräch, kann auch das Äußere einer Softwareapplikation – also die Benutzeroberfläche – im Zweifelsfall über Sieg oder Niederlage (kaufen oder nicht kaufen!) entscheiden. Der Grund dafür ist, dass viele Benutzer, vor allem solche, die technisch nicht sonderlich versiert sind, vom Eindruck der Benutzeroberfläche auf die Gesamtqualität der Software schließen. Komplexe, überladene Bildschirmmasken, deren Design an ein typisches Look and Feel von vor zehn Jahren erinnern, mindern potentiell also den kommerziellen Erfolg einer Anwendung. Dies gilt besonders dann, wenn die Konkurrenz ihre Hausaufgaben gemacht hat!
Reichte es vor 15 Jahren noch vollkommen aus, einfach nur die Bedienung der Applikation mit der Maus zu unterstützen, erwarten Anwender heute doch einiges mehr. Angeregt von innovativen Oberflächenelementen in Applikationen großer Hersteller, wie zum Beispiel Apples Coverflow, das Ribbon in Microsoft Office 2007 oder interaktiv gruppierbarer Tabellen wie in Microsoft Outlook, erwarten Endanwender solche Features auch in anderen, also unseren Applikationen.
Leider kommt man mit den Bordmitteln, die Microsoft Visual Studio bis zur Version 2008 an dieser Stelle liefert nicht immer ans Ziel. So sind zum Beispiel weder Ribbons, noch interaktiv gruppierbare Tabellen oder Excel ähnliche Diagramme „out-of-the-box“ möglich.
Möchte man die Anforderungen an eine konkurrenzfähige Oberfläche also erfüllen, kommt man (wirtschaftlich gesehen) kaum um den Einsatz einer 3rd Party UI Komponentensuite herum.
Die Suite meiner Wahl ist Infragistics NetAdvantage. Die Komponenten sehen nicht nur top aus, sondern bieten auch alle Features, die das Entwicklerherz begehrt.
StyleCop
Konsistente Quellcode Formatierungen in einem Projekt mit mehreren Entwicklern. müssen dank StyleCop kein Wunschtraum mehr bleiben. Jedem, der im Team entwickelt kann ich dieses Tool nur wärmstens ans Herz legen!

HTTP Error 500 nach Restore eines Sharepoint Backups

Andre — Mon, 18 May 2009 23:44:53 GMT

Kürzlich versuchte ich via stsadm -o restore das Sharepoint Backup eines Kundens auf meinem Entwicklungsrechner einzuspielen. Obwohl die Wiederherstellung problemlos lief, kam beim anschließenden Aufrufen der Seite stets nur die statische Meldung: HTTP 500, interner Serverfehler. Sowohl das Eventlog, als auch die Sharepoint-Log Dateien gaben keinen Aufschluss zur Ursache des Fehlers. Auch Google und Co waren wenig hilfreich.

Nach stundenlangem Probieren konnte ich die Ursache glücklicherweise doch finden: Sowohl der Kunde, als auch ich hatten einen englischen MOSS auf einem englischen Windows 2003 Server installiert. Im Gegensatz zu mir hatte der Kunde jedoch zusätzlich die deutschen Sprachpakete für MOSS und WSS 3.0 inkl. aktuellem Servicepack installiert.

Mein Fazit der Geschichte:

In Zukunft werde ich beim Aufsetzen einer Sharepoint Entwicklungsmaschine sofort die Language Packs installieren.

Dotnet-kicks.de Link in Feedburner RSS Footer einbinden

Andre — Mon, 18 May 2009 23:27:06 GMT

Wer den RSS Feed seines Blogs via Feedburner publiziert, kann mit Hilfe eines FeedFlares sehr einfach einen dynamischen Dotnet-kicks.de Link unter jeden Eintrag setzen.

Dazu ist wie folgt vorzugehen:

Einloggen bei feedburner
Feed zur Verwaltung auswählen
Registrierkarte Optimize anklicken.
Links im Menü den Punkt FeedFlare wählen
Neuen Flare hinzufügen

Eine passende Flare Datei, die von jedem Benutzt werden darf, befindet sich auf meiner Homepage unter http://www.codemurai.de/downloads/kick_it-deflare.xml
Speichern und Aktivieren
Das Ergebnis genießen ;-)

Office 2007 Bedienung für 2003 Profis

Andre — Thu, 30 Apr 2009 10:47:16 GMT

Da immer mehr und mehr meiner Freunde, Kunden und Kollegen auf Office 2007 umsteigen werde ich in letzter Zeit häufiger gefragt, wo sich ein unter 2003 bekannter Menüpunkt innerhalb des Office 2007 Ribbons versteckt.

Die Frage lässt sich relativ leicht durch die folgenden drei interaktiven "Handbücher" beantworten:

Wer es noch nicht kennt:

Dem Anwender wir die gewohnte Office 2003 Oberfläche präsentiert. Nach Auswahl eines Menüpunktes wird per Animation der neuer Ort angezeigt. Schick, oder?

Visual Studio 2008 stürzt beim Kompilieren eines Outlook 2007 Add-Ins ab.

Andre — Thu, 29 Jan 2009 23:04:57 GMT

Heute versuchte ich mein erstes Outlook 2007 Add-In unter Visual Studio 2008 zu entwickeln. Nachdem ich bereits einiges an Code geschrieben hatte, wagte ich den ersten Kompiliervorgang.

Das Ergebnis war allerdings wenig erfreulich, denn anstatt mir ein das Ergebnis meines Kompiliervorgangs anzuzeigen, ging Visual Studio einfach kommentarlos zu.

Um auszuschließen, dass es an meinem Code lag, stellte ich dasselbe zusätzlich noch mit einem leeren Outlook 2007 Add-In nach. (Glücklicherweise) war das Resultat gleich :-)

Nach ein wenig googeln wurde ich darauf aufmerksam, dass die Visual Studio PowerCommands die Ursache sein sollten. Diese habe ich jedoch gar nicht installiert. Also ging die Suche weiter.

Die Lösung fand ich schließlich in folgendem Eintrag:

MSDN Forum - VS 2008 closes at build, Outlook 2007 Add-In

Kurz zusammengefasst: Es ist ein Fehler innerhalb der CLR, der auftritt, wenn Assemblies in einer bestimmten Reihenfolge geladen werden.

Als Workarround kann man das VSTO Native Image (nicht VSTO selbst ;-)) löschen. Dazu tippt man in einem Visual Studio Command Promt einfach folgende Zeile ein:

ngen /delete Microsoft.VisualStudio.Tools.Office.Runtime.v9.0.dll

Viel Erfolg ;-)

Was ist fast so schön wie leuchtende Kinderaugen?

Andre — Mon, 25 Aug 2008 23:40:52 GMT

Genau: leuchtende Kundenaugen :-)

Diese durfte ich kürzlich wieder sehen. Einer meiner Kunden behalf sich nämlich Jahre lang mit "schmutzigen" Workarrounds um das Feuern von Update-Triggern bei Massenupdates zu vermeiden.

Glücklicherweise ist es jedoch unter dem SQL Server möglich, Trigger bedarfsweise zu deaktiveren / aktivieren.

Für alle, die mit dem selben Problem kämpfen hier zur Referenz:

-- Trigger für Tabelle deaktiveren
ALTER TABLE [MeineTabelle] DISABLE TRIGGER ALL
 
-- Massenupdate durchführen, z. B.
-- update MeineTabelle set Preis = Preis * 1.5
 
-- Trigger wieder aktivieren
ALTER TABLE [MeineTabelle] ENABLE TRIGGER ALL

Vorkommnisse eines Zeichens unter T-SQL zählen

Andre — Mon, 25 Aug 2008 23:39:23 GMT

T-SQL bietet keine Möglichkeit die Vorkommnisse eines Zeichens innerhalb einer Zeichenkette zu zählen.

Richtig! Nun ja, zumindest fast. Zwar gibt es keine eingebaute Funktion, mit folgendem Konstrukt lässt sich die Anforderung jedoch trotzdem erfüllen:

    1 -- Anzahl der vorkommenden 't' zählen
    2 Select 
    3         CompanyName, 
    4        len(CompanyName) - len(replace(CompanyName, 't', '')) as Anzahl
    5 from 
    6         Customers

Im gewählten Beispiel, welches übrigens auf der Northwind Datenbank ausprobiert werden kann, werden die Anzahl der 't' innerhalb des Felds CompanyName gezählt.

Die Funktionsweise ist recht einfach:

Zuerst wird in Zeile 4 die Länge des Namens ermittelt. Im Beispiel von 'Alfreds Futterkiste' wäre dies 19. Anschließend werden alle 't' innerhalb von 'Alfreds Futterkiste' durch einen leeren Character ersetzt und die Länge von 16 Zeichen ermittelt. Als letztes wird der zweite Wert vom ersten subtrahiert, so dass wir auf unser Ergebnis von 3 kommen.

Eigentlich ganz einfach, oder :-)