Kategorie: .NET

Wenn in einem Access Report Summen falsch gebildet werden, kann das sehr viele verschiedene Ursachen haben. Meist handelt es sich um Rundungs- und Typenfehler. In dem vorliegenden Fall war die Ursache allerdings viel banaler. Als ich einen Report auf meinem PC generierte stimmte die Summenbildung (hier: 2307t). Ebenso auf dem Rechner eines Kollegen. Erst als wir die Datenbank dann schließlich auf dem Rechner des Kunden installierten, kamen utopische Zahlen heraus. Sie reichten je nach Seleketion von ca. -63000t bis 180000t. Eine Exception wurde zudem nicht ausgeworfen.

(Leider habe ich von dem fehlerhaften Report keinen Screenshot machen können)

Die Lösung war nach einigem rätseln denkbar einfach, denn es handelte sich nicht um einen Fehler im eigentlichen Sinne. Der Kunde hatte nicht die aktuellste Version von Access (? => Info).

Nachdem mein Kollege ihm das Service Pack 3 installiert hatte (Download), funktionierte auch wieder alles. Ergo: Kunde glücklich.

—

Da Access 2003 nun nicht Stand der Technik ist, möchte ich noch kurz anreißen wie sich Versionsunterschiede bei modernen Microsoft Technologien verhalten. Einer der häufigsten Fehler den ich bei sog. “strikten” Kunden zu sehen bekomme ist der folgende:

System.IO.FileNotFoundException: Die Datei oder Assembly System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

Strikt deswegen, weil es Unternehmen gibt, die Service Packs oder Updates im Unternehmensnetzwerk nicht freigeben. Der obige Fehler deutet im Grunde nur daraufhin, dass die “System.Core”, also der Kern des .NET Frameworks in einer bestimmten Version (3.5.0.0) nicht vorliegt.
Das mag für Laien vielleicht verwirrend sein, aber es ist für Windowsentwickler möglich, Anwendung unter verschiedenen .NET Framework Versionen bereitzustellen. So passiert es nicht selten, dass Programme die von der eingesetzten Technologie mit der Version “2.0.0.0” zwar auskämen, trotzdem mit der Ausführungsvoraussetzung “3.5.0.0” erstellt werden.
Schafft die Installation des .NET Frameworks 3.5 (Download) daher keine Abhilfe oder ist es prinzipiell im Unternehmen nicht erlaubt dieses zu upgraden, kann es bei Individualsoftware manchmal ratsam sein, die Entwickler zu bitten, das Projekt mit einem niedrigeren Zielframework (2.0, 3.0, 3.5, später 4.0) bereitzustellen.

Fazit: Microsoft hat also auch hier aus den Fehlern der Vergangenheit gelernt. Ich hätte mir trozdem sehr gewünscht, wenn Access eine Meldung ausgegeben hätte, die daraufhin deutet dass die ausgelieferte Datenbank mit einer späteren Access Version erstellt wurde.

Der folgende Code ist eine Übersetzung aus einer sehr häufig verwendeten Delphi-Funktion. Sie war Grundlage vieler Projekte, da Delphi von Haus aus keine Parsingmethode anbot.

        public static string Parse(string Char, string S, int Count)
        {
            string T = string.Empty;

            if (S[S.Length-1].ToString() != Char)
                S += Char;
            for (int I = 1; I <= Count; I++)
            {
                if (S.Length == 0) return "";
                T = S.Substring(0, S.IndexOf(Char));
                S = S.Substring(S.IndexOf(Char)+1);
            }
            return T;
        }

Beispiel:

string foo1 = "foo1#foo2#foo3#hallo"; // der Ausgangsstring
string teil1 = Parse("#", foo1, 1); // enthält: "foo1"
string teil2 = Parse("#", foo1, 2); // enthält: "foo2"
string teil4 = Parse("#", foo1, 4); // enthält: "hallo"
string leer = Parse("#", foo1, 42); // enthält: "" (leer)

Ich gebe zu, dass das nicht gerade die effizienteste Methode ist einen String zu zerlegen, aber die Routine ist äusserst effektiv und einfach aufgebaut. Fehlverwendung ist praktisch ausgeschlossen.

Die letzte Woche war ich häufig damit beschäftigt, “Flaschenhälse” in meinen Quellcodes zu finden. Ein Tool das mir dabei unglaublich weitergeholfen hat nennt sich:

redgate ANTS Profiler

Der ANTS Profiler ist ein proprietäres .NET Tool der Firma Red Gate^® Software Ltd. Da die Software im Framework 2.0 entwickelt wurde, benötigt man ebendieses für die Installation. Nach dem Download und der Installation, besitzt das Visual Studio eine Kladde mehr, mit der der ANTS Profiler aufgerufen wird.

Zeitgleich mit dem Aufruf wird die eigene Anwendung gestartet und der Profiler beginnt mit seinen Aufzeichnungen. Da die Anwendung in der Zeit unter “verschärfter Beobachtung” steht, arbeiten Algorithmen in der Regel viel zeitintensiver.

Nach Beendigung der eigenen Anwendung (z.B. durch manuelles Schließen oder automatisches Schließen einer Konsolenanwendung) wertet der Profiler seine Untersuchungen aus und stellt sie folgendermaßen dar:

Im oberen Diagramm wird die Prozessorauslastung und die Lese- und Schreibzugriffe dargestellt. Im Bereich darunter kann man in einem hierarchischen Balkendiagramm sehen welche Klassen/Funktionen die meiste Rechenzeit in Anspruch genommen haben.

Im untersten Fenster ist das, was für den Programmierer allerdings am interessantesten sein dürfte: eine zeilenweise Zeitmessung des Quellcodes. Hier kommen teilweise Flaschenhälse zum Vorschein, die zwar absolut logisch sein mögen, aber aufgrund der täglichen Programmierroutine gerne vernachlässigt werden. Zum Beispiel das generieren neuer Objekte mit “new” in Schleifeniterationen oder verdeckte SQL-Querys in unscheinbaren LINQ-Funktionen (z.B. Count();).

Die Software kostet in der Standardversion ohne Support: 295€ (Stand Februar 2009)

Nachtrag am 04.03.2009:

Soeben hat mich ein freundlicher Mitarbeiter der Firma redgate angerufen und mir angeboten die im Juli 2009 erscheinende neue Version (.NET 3.5) bereits vorab zu testen. Dies habe ich natürlich wahrgenommen und hoffe in den nächsten Tagen ein wenig schlauer zu sein.