Wieso habe ich versucht SQLite unter C# zu nutzen?

Grund war, daß der Firefox seine Bookmarks als SQLite File abgelegt (places.sqlite).

Da ich 6 Maschinen einsetze, meine Bookmarks weder Google noch FoxMark anvertrauen will, aber trotzdem gerne auf allen Maschinen die gleichen Bookmarks verwenden will ohne viel manuelles Doing, sind ein Kollege und ich auf den Gedanken gekommen hier ein kleines Hilfsprogramm zu schreiben.

Da ich gerne in C# Programmiere, habe ich mir natürlich gleich von Finisar den ADO.Net SQLite Provider besorgt.

Das SQLite Datenbankfile war schnell gefunden und kopiert, ein Beispielcode war auch schnell gefunden, aber die Sache wollte nicht.

“Finisar.SQLite.SQLiteException” wurde aufgefangen.
Message=”malformed database schema – near \”AUTOINCREMENT\”: syntax error”
Source=”SQLite.NET”
StackTrace:
bei Finisar.SQLite.sqlite3.Throw()
bei Finisar.SQLite.sqlite3.CheckOK()
bei Finisar.SQLite.sqlite3.exec(String sql)
bei Finisar.SQLite.SQLiteConnection.Open()
bei MozBookmarkSync.SQLiteDB.openDBFile() in …
InnerException:

Dieser Fehler soll angeblich nur dann auftreten, wenn man einen nicht unterstützten Create Befehl beim Erzeugen der Tabelle verwendet hat.

Mein erster Verdacht war, daß man hier beim Firefox was rumgepfuscht hat. Mea culpa… ich tat ihnen Unrecht!

Die Datei firefox-3.0rc3-source\mozilla\db\sqlite3\src\sqlite3.c basiert auf der Version 3.5.4.2 von SQLite.

Ein Test mit SQLite Expert erbrachte, daß ich das SQLite File places.sqlite vom Firefox ohne Probleme öffnen und auslesen kann.

Wo könnte der Fehler liegen?

Nach einigem Hin und Her und Suchens auf Google und verschiedenen HowTo Pages, habe ich mir dann von hier den Source des ADO.Net SQLite Providers besorgt.

Und hier kam dann der Hammer…

Der Provider wurde zuletzt in 2005 überarbeitet und unterstützt nur SQLite 3.1.1.

Thema erledigt. Manchmal soll es halt nicht gehen und bevor ich anfange jetzt selbst zu fummeln, lehne ich mich zurück, greife mir das nächste Thema und schaue mal, was der Kollege mit JAVA erreichen kann. Dafür gibt es Level4 (native JAVA) Code für SQLite…

Update

ha… es gibt doch noch eine neuere Implementation…

http://sourceforge.net/projects/sqlite-dotnet2

Mal schaun ob da das notwendige drin ist

Langsam aber sicher habe ich für fast jede Routine einen Unittest erstellt.

Die Konzeptionierung der Game Engine geht auch gut vorran und ich bin guter Dinge in wenigen Wochen eine Testversion verfügbar zu haben, welche ich dann ausgewählten Personen zuschicken werde.

Die ersten eingebauten Funktionieren werden sich aber dann trotz allem zuerst auf internas beschränken. Es wird zwar ein Registrationsformular geben, man wird sich anmelden können, aber Spieltechnisch sind dann noch keinerlei Routinen vorhanden.

Da ich auf keinen bestehenden Code aufbauen will, muß ich hier viele Dinge selbst erstellen.

Der Dynamic Data Cache funktioniert auch endlich unter Vista und ich kann mich jetzt der Game Engine widmen.

Das Thema Code Security wird von mir getrennt behandelt. Hier stehen noch einige Konzeptionelle Dinge vorher an, welche ich erledigt wissen will, bevor ich was wichtiges später übersehe.

Soderle… ich habe alle Sourcen überarbeitet, was eine ziemliche Arbeit war.

Vista ist viel restriktiver im Vergleich zu XP. Zwar könnte ich es mir einfach machen und im Administrativen Modus arbeiten, aber dann würden mir viele Probleme mit den Rechten erst zu spät auffallen.

Der Webserver läuft, die Template Engine funktioniert, die Sprachroutinen werfen auch keine Fehler mehr aus, das Formularhandling für POST ist rudimentär auch eingebaut.

In den nächsten Wochen werde ich die Game Engine erstellen. Sprich, das eigentliche Spiel.

Alles andere war die Vorarbeit und hatte noch keinerlei Bezug zum eigentlichen Spiel.

Mein erstes Ziel wird die Benutzerverwaltung incl. Login- und Registrationsformular sein.

Parallel dazu werde ich Angriffsszenarien definieren und vorbereiten. Der Spielcode soll später produktiv verwendet werden und nicht bei jedem kleinen Husten von Scriptkiddis umfallen.

Und wieder freue ich mich, daß ich keinen Abgabetermin dafür habe

Nachdem ich in den letzten Tagen angefangen habe meine Basisbibliotheken auch an andere weiter zu geben, mußte ich natürlich auch anfangen die Qualität weiter zu erhöhen. Was für mich persönlich reicht, muß für andere noch lange nicht genügen.

Sprich, ich kann mit einigen Nebeneffekten leben, andere aber nicht. Noch übler wird dies, wenn man Klassen/Methoden dann verwendet, dass Programm dann Fehler erzeugt und man nicht weiss, ob der Fehler am eigenen Programm liegt, oder an meiner Basisbibliohek.

Hierfür verwendet man üblicherweise Testtools wie z.B. NUnit. Aber es gibt es auch noch ein weiteres, sehr nützliches Tool.

Und zwar NCover.

Mittels NCover kann man unter anderem ermitteln, ob während der Laufzeit des eigenen Programms überhaupt alle Quellcodezeilen angesprungen worden sind. Nicht selten hat man bei Unittests nicht alle Möglichkeiten abgedeckt und später eventuell wichtige Quellcodebereiche werden erst gar nicht angesprungen.

Man sollte aber jetzt nicht davon ausgehen, dass Tools wie NUnit oder NCover alle Möglichkeiten abprüfen können. Jedes dieser Tools ist nur so gut, wie die zugrundeliegenden Unittests und das Ergebnis ist stark abhängig von den Rahmenbedingungen.

Bei mir wird NUnit ein fester Bestandteil meines Entwicklungsprozesses im Privaten Bereich werden. NCover kommt für finalisierende Tests hinzu, wird aber nur sporadisch eingesetzt werden.

Kleine Anmerkung am Rande: Ein Kollege meinte die Tage mal wieder zu mir, dass Unittests absolut unsinnig sind und den Entwicklungsprozess nur verlängern würden. Ja, sie verlängern ihn, dafür steigt die Qualität des Ergebnisses enorm und man hat später weniger Wartungsaufwände. Tja… es gibt halt immer wieder “Programmierer”, welche Quantität über Qualität stellen. Traurig, aber ich werde mir so eine Arbeitsweise nicht zu eigen machen.

Und wieder beginnt mein Leidensweg mit OpenSource Software.

Diesmal wollte ich mittels PDO, welche eine Datenbankschnittstelle unter PHP darstellt, auf einen SQL Server zugreifen.

Nach dem üblichen Hürdenlauf mit dem immer (!) noch verhunzten MSI-Installer von PHP, hatte ich zwar PDO am Laufen, aber es wollte nicht mit dem SQL Server reden.

Der SQL Server war korrekt konfiguriert, ich konnte mich mit einem extra für diesen Zweck angelegten Account auch einloggen und ihn verwenden. TCP/IP war auch aktiviert als Kommunikationsweg, der Port war definiert und in der Firewall freigegeben, es konnte also nichts mehr blockieren.

Trotzdem wollte PHP/PDO nicht mit dem SQL Server reden.

Hier nun meine Ergebnisse der Stundenlange Analyse, welche dann folgte:

In folgender PDO Doku steht das PDO_DBLIB für FreeTDS / Microsoft SQL Server / Sybase zuständig ist.

Folgt man dem Link der sich unter PDO_DBLIB verbirgt, dann kommt man zu einer Subseite der PHP-Doku, welche folgende Warnung beinhaltet:

Diese Erweiterung ist EXPERIMENTELL. Das Verhalten dieser Erweiterung, einschließlich der Funktionsnamen, und alles Andere was hier dokumentiert ist, kann sich in zukünftigen PHP-Versionen ohne Ankündigung ändern. Seien Sie gewarnt und verwenden Sie diese Erweiterung auf eigenes Risiko.

Im ersten Kommentar wird auf die PECL Page von PDO hingewiesen, welche dann unter anderem das Release 1.0 mit Datum 2005-11-26 enthält.

Vorhin war ich Neugierig und habe einfach mal auf den Link hinter dem zugehörigen Changelog Eintrag geklickt und da kam dann das:

Update code for API changes in PDO; no actual changes have been made to this driver.

** Changes **
- Fix Bug #34777; segfault when retrieving non-existent error info
- Fix Bug #35032; didn't find FreeTDS includes on some systems

PDO_ODBC werde ich auf gar keinen Fall verwenden, dafür ist die Gesamtperformance von ODBC zu schlecht. MySQL mit InnoDB will ich nicht einsetzen. Im Moment bewege ich mich dort wo es sofort geht, von OpenSource Software weg und setze immer mehr auf kommerzielle Kauflösungen.

Von daher fällt für mich der Zwischenschritt der Migration von MySQL nach MS-SQL weg und ich werde zusätzlich die Migration von PHP nach C# angehen müssen.

Das gefällt mir im Moment überhaupt nicht, aber ich werde wohl damit leben müssen.

Und was bleibt mir noch zu tun?

Genau! Die Benotung des Ganzen Konstrukts, wo da wäre, das…

• …die Doku von PHP alles andere als aktuell ist.
• …bei PHP Sachen als Stable maskiert werden, welche noch nicht mal Ansatzweise als Stable gelten können.
• …der Hinweis auf Probleme nur im Changelog auftaucht.
• …man lieber auf den langsamen ODBC Treiber setzt, anstatt die vorhandenen Bugs zu fixen.
• …man nur so zu aggieren scheint, weil es sich hier um eine Microsoft Datenbank handelt.

DING DING DING Und da war er der 5. Fricklerpunkt!

Und somit bekommt PHP/PDO den Frickler-Award der Woche!

Im Moment bemüht sich PHP redlich den Frickler-Award des Jahres zu bekommen.

So langsam stelle ich mir eine Frage… ist OpenSource Software immer so unreif?

Das letzte Beispiel zu dem Thema lieferte per Default immer NULL, abgesehen davon war die Implementation auch nicht vollständig korrekt.

TheUndeadable war so freundlich, mich auf den richtigen Weg zu bringen.

public IEnumerator<jobqueueentry> GetEnumerator()
{
  return _jobQueue.Values.GetEnumerator();
}

System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
  return _jobQueue.Values.GetEnumerator();
}

FXCop ist ein feines Tool. Manche Warnungen die es anzeigt, kann man leicht lösen, bei einigen knallt man mit .NET Eigenarten zusammen.

Bestes Beispiel war IEnumerable.

FXCop meinte, es wäre sauberer, wenn ich IEnumerable; verwenden würde. OK, also machte ich mich an die Arbeit und stelle den Source um.

Und prompt lieferte der Compiler folgende Meldung:

does not implement interface member ‘System.Collections.IEnumerable.GetEnumerator()’

Tja… lange habe ich gesucht. 2 Bekannte haben sich das mit angesehen und erst nach langem Suchen sind wir auf folgenden Blogeintrag gestossen:
IEnumerable in .NET 2.0 Beta 2

public class JobListCollection : IEnumerable <JobQueueEntry>
{
  public IEnumerator<JobQueueEntry> GetEnumerator()
  {
    return null;
  }

  IEnumerator IEnumerable.GetEnumerator()
  {
    return GetEnumerator();
  }
}

Fazit:
Manche Fehlermeldungen sind so panne, da kann man echt nur noch mittels Google und viel Zeit hinter die Lösung kommen.

Es gibt Tage, da hätte ich große Lust den Fricklern mal so richtig die Meinung zu geigen.

Grund:

Fatal error: Call to undefined function mysql_connect()…

Eigentlich nicht tragisch, aber… Die Leute von PHP sagen, es ist ein Fehler in MySQL. Und die von MySQL sagen, es ist ein Fehler in PHP. Und keiner bringt brauchbare Lösungen.

Beim Versuch der Lösung dieses Problems, bin ich dann dahinter gekommen, dass die php.ini welche bei PHP 5.2.5 dabei ist, total Grütze ist und schon beim Start über 20 Fehler bringt. Da werden einfach mal Module eingebunden, welche es nicht gibt.

Nach vielen vielen Tutorials, HowTo und FAQs bin ich dann dahinter gekommen, dass…

• …PHP es MySQL in die Schuhe schiebt und umgekehrt.
• …der MSI-Installer der Versionen 5.2.5 und 5.3.0 Dev nicht nur Bockmist baut, sondern auch noch eine unbrauchbare php.ini mitbringt.
• …in der Windows Version von PHP C:\Windows als Pfad für die php.ini HARDCODED eingetragen wurde.
• …in der aktuellen Version von PHP Unmengen von Sachen eincompiliert wurden, welche schon bei einem Aufruf mittels “php -m” mehr Fehlermeldungen ausspucken, als die Hilfe selbst groß ist.
• …dieser Fehler NUR unter Windows vorhanden ist.

DING DING DING Und da war er der 5. Fricklerpunkt!

Und somit bekommt PHP den Frickler-Award der Woche!

Die Portierung vom KKDaemon für die Aufträge geht gut vorran. Ich habe die Zeit genutzt, in welcher ich mit meinem Vater am Flughafen gewartet habe. So 30% vom KKDaemon sind schon fertig.

Der Entwicklungsserver installiert sich eben fertig. Ich habe Windows 2003 Standard Server gewählt. Habe nach dem Desaster mit den Sourcen die Nase jetzt erstmal wieder voll von Linux.

Und es gibt heute mal eine “kleine” Sourcestatistik von mir. Für die große Version davon auf welcher man mehr erkennen kann, einfach wie üblich auf das Bild selbst klicken.

Der LINQ Benchmark hat ein kleines Update erhalten.

Beim Benchmark 2 Run 2 fehlte die Zuweisung zum Objekt. Außerdem werden jetzt noch Zusatzinformationen ausgegeben um eine leichtere Zuordnung zum jeweiligen Abschnitt in der Dokumentation zu ermöglichen.

LINQ_Benchmark.zip (232 KB)

Die Werte haben sich nur geringfügig verändert, was wohl eher an der niedrigeren Grundlast auf der Testmaschine lag. Ansonsten ist die Verteilung gleich geblieben.