Einträge von Axel Holzmüller

Da kann man lange suchen - kleiner Unterschied, große Wirkung.

So kennt die externe Funktion COM kennt das Kommando "WAIT", und es gibt COM-Objekte mit einer Methode namens "Wait". Dies sollte man nicht verwechseln, es ist mir trotzdem passiert.

Es ist wohl so, dass COM nur Kommandos in Großbuchstaben akzeptiert. So, wie es im Users Guide niedergeschrieben steht. COM 'WAIT' timeout ist ebenso valide wie COM 'PROPERTY' params, "COM 'Wait' timeout" wirft dagegen einen Domain Error aus.

Ich habe lange nach dem Grund für diese Fehlermeldung gesucht, David hat ihn herausgefunden. Glücklicherweise nicht sofort, ich brauche mich also nicht für vollkommen verblödet zu halten.

Bei Eigenschaften und Methoden von COM-Objekten ist die Situation in der Regel entspannter: Ob ich nun z.B. COM 'METHOD' handle 'Wait' param schreibe oder COM 'METHOD' handle 'WAIT' param ist einerlei, ich erhalte in beiden Fällen das erwartete Verhalten.

... das war vor CSD 10 die Frage.

Die Erkennung und Markierung von URLs in Kommentaren hat wohl vielen APL2-Fans nicht so recht zugesagt. Ich kann das nachvollziehen. Es wurden Dinge als URL erkannt, die nie als solche gemeint waren.

In der Regel hätte mich das auch nicht weiter gestört, denn ich lasse einem Doppelpunkt stets eine Leerstelle folgen. Dies widerspricht der Definition einer URL.

CSD 10 bietet nun eine richtige Lösung: Die Markierung von Zeichenfolgen in Kommentaren als HTTP-Link gibt es nun als Option. Im APL2 Objekt-Editor kann unter "Options/System Options" mit "Underline URL" entschieden werden, ob aus dem Editor heraus direkt auf Web-Seiten zugegriffen werden kann.

Als Voreinstellung ist diese Option nicht aktiviert.

Dies ist für alle die beste Lösung: Ein sinnvolles Feature, das bei Bedarf eingeschaltet werden kann.

Das ist nicht die einzige Neuerung der CSD 10. Doch dazu später mehr ...

Gestern hatte ich den Eindruck, eine magische Hand hat eine APL2-Funktion auf meinem Rechner verändert. Wenn überhaupt habe ich diese Funktion seit fast 2 Jahren nicht mehr angefasst, trotzdem fällt sofort eine Änderung ins Auge:

Diese Zeile (deren Inhalt hier unerheblich ist), ein vorher ganz unschuldiger Kommentar, erscheint urplötzlich unterstrichen

⍝LBAR:→(0∊⍴SP←(E_VKDA[⍙VKDA_INH⍳⊂'TANR';]∊2288 2480)/⍳2⊃⍴E_VKDA)/LTHV

Ich war es nicht, aber wer war es dann?

Viele, viele APL2-Fans tragen dafür die Verantwortung. Allen voran Bernd, daneben auch die Teilnehmer einer GSE-Arbeitsgruppensitzung (wovon ich auch einer war) und schließlich David.

Als ich diese Veränderung an einer anderen Stelle von ca. zwei Jahren das erste Mal sah, erinnerte ich mich an ein damals aktuelles GSE-Requirement. Wir hielten Bernds Vorschlag für sinnvoll, in Kommentaren von APL-Funktionen URLs einbetten und verlinken zu können. Damit erhält der APL2-Nutzer die Möglichkeit, aus einer APL2-Funktion heraus sich eine Web-Seite in seinem Standardbrowser anzeigen zu lassen.

Offensichtlich fand auch David die Idee interessant und die Umsetzung nicht zu aufwändig. Mit der nächsten CSD war dieses Feature verfügbar.

Eine unterstrichene Kommentarzeile ist als kein Bug in der Darstellung einer Funktion, sondern ein Feature.

Bis kurz vor Ende lief alles ganz gut mit dem Artikel über die angekündigte Informix-Appliance. Aber dieser letzte Satz, musste der sein?

"Diese Rolle war jedoch umstritten, da IDS gegenüber der DB2-Entwicklung ein Schattendasein fristete und das mit Version 10.0 eingeführte letzte größere Update schon seit Februar 2005 zurückliegt."

Welche "Rolle" ist hier eigentlich unerheblich, die Begründung allerdings ist sehr fragwürdig.

Die Annahme des "Schattendasein" von IDS gegenüber DB2 mag eine Zeit lang als nicht völlig unbegründet gegolten haben, ist allerdings inzwischen widerlegt. Heute klingt eine solche Behauptung wie Oracle-Propaganda.

Richtig kraus ist die Begründung mit einer zweijährigen Wartezeit für die kommende IDS-Version. Ja, es gibt Software, für die es jährlich (oder häufiger) ein Update gibt. Es gibt aber auch Beispiele mit regelmäßig längeren Zyklen. Windows Betriebssysteme sind prominente Beispiele. Die Spanne zwischen XP und Vista beträgt immerhin mehr als 5 Jahre.

"Vista: Eine kurze Geschichte der Zeit" titelte irgendwann vor der Jahreswende ein CW-Redakteur eine kurze Meinungsäußerung. Mir erschließt sich bis heute nicht Sinn oder Ziel dieser Zeilen. Ich verstehe nur, dass hier sich jemand zum Anwalt einer Softwarefirma aus dem regnerischen Nordwesten der USA gegen eine doch so böse Medienwelt berufen fühlt.

Das klingt wie die Verteidigung eines bei einem Fehltritt ertappten Politikers, der nun heftig auf die Presse eindrischt. Das hat aber selten dem armen Sünder genützt.

Dass im vorliegenden Fall ein Medienschaffender seine Kollegen der Märchenproduktion bezichtigt, ist schon bemerkenswert. Ich kann mich auch des Eindrucks nicht erwehren, dass der Autor die unter "Eine Chronik" zitierten Artikel der eigenen Redaktion entweder nicht gelesen oder nicht verstanden hat. Denn unter dem Titel "Microsoft blamiert sich mit Vista" findet man eine weitere "Chronik", die die Geschichte der Terminverschiebungen für Vista bis Anfang 2006 allgemein verständlich dokumentiert.

Der Autor der "Vista-Geschichte" dampft dagegen die betrachtete Zeit auf ein Drittel zusammen: hier beginnt sie erst Mitte 2005, während die ersten Ankündigungsturbulenzen bereits mit dem April 2002 begannen.

Lateinisch "ignorare" bedeutet "nicht wissen“ oder "nicht kennen“. Ignoranz kann mit Unwissenheit übersetzt werden, aber auch mt "Dummheit". Aber soweit will ich hier nicht gehen.

Was der Autor des CW-Artikels "Was Unternehmen wirklich brauchen" offensichtlich nicht weiß oder kennt, ist die lange Liste der BI-Hersteller. Das ist nicht verwerflich, denn wer kennt die schon alle. Aber die großen Player im Markt sollte man schon kennen. Dies vorausgesetzt ist die diesem Artikel beigelegte Liste "BI-Aussteller auf der CeBIT" schon befremdlich.

Denn der Autor war nachweislich auf besagtem CeBIT-Forum "Business Intelligence und Enterprise Information Integration", schließlich war er dort Moderator einer Podiumsdiskussion. Noch schlimmer: einer seiner Teilnehmer war Roland Grund, Data Mining Spezialist bei IBM. Und jeder Anwesende verstand, dass IBM Data Mining-Software im Portfolio hat.

Und Data Mining gehört zur Business Intelligence, einige sagen gar: Data Mining ist die Königsdisziplin der Business Intelligence. Also ist IBM bereits in dieser Hinsicht Anbieter von BI-Software.

Dass Data Mining bei Versicherungen und Banken, im Handel oder in der Automobilindustrie gerne eingesetzt wird, gehört nun inzwischen zur IT-Allgemeinbildung. Aber dass sich die Fußball-Bundesliga für Mining-Analysen interessiert, das ist schon spektakulär.

Zu hören war das auf dem CeBIT BI-Forum anlässlich der Podiumsdiskussion mit dem (unsäglichen) Titel "Zweiter Frühling für Data Mining". Zu lesen ist diese Aussage auch in dem Referat des Moderators der Veranstaltung in der CW. Ich kann mich noch erinnern, dass Rolands Erwähnung der Fußball-Bundesliga weder beim Moderator noch bei den Mit-Diskutanten irgendeine Reaktion hervorgerufen hätte. Auch im CW-Artikel wurde das nicht vertieft.

Ist es schon so selbstverständlich, Data Mining in allen Lebensbereichen einzusetzen? Oder waren außer Roland auf dem Podium nur Fußball-Ignoranten vertreten?

Eigentlich wollte ich nur einen Langläufer testen - eine SQL-Query in der drei Tabellen mit ca. 300.000 Zeilen und eine Tabelle mit mehr als 10.000 Zeilen gejoint werden. Anlass war meine Beobachtung, dass das Komprimieren großer Tabellen neben Speichergewinn auch eine bessere Performance bringen kann. Würde auch hier die Verdichtung der beteiligten Tabellen den Langläufer beschleunigen?

Ich testete ihn also in zwei Datenbanken, eine davon enthielt die Tabellen in komprimierter Form. Anfangs wies db2batch für die Query mehr als 200 Sekunden aus, mit teilweise signifikant besseren Werten für die Variante mit den Komprimanten. Aber eben nur teilweise.

Um vertrauenswürdigere Daten zu bekommen, ließ ich die Abfragen mehrfach mit anderen Abfragen in kontrollierter Form ablaufen. Ich rechnete also mit langem Warten auf die Ergebnisse. Doch, Überraschung, nach einigen Sekunden war alles vorbei.

Was bisher geschah:

• Die Tabellen einer MS-Access-Anwendung sind zu groß geworden für die Jet-Engine. DB2 ist die Wahl der Stunde für die Datenhaltung als skalierbare, performante und vertrauenswürdige Basis.
  
• Tabellendefinitionen und Daten lassen sich manuell oder per VBA-Routine nach DB2 transportieren.
  
• Auch die Anlage von Indizes und Schlüssel in der Zieldatenbank kann automatisiert werden.
  

Es bleibt die Aufgabe, die DB2-Tabellen an die Anwendung anzubinden. Dies geht unter Access natürlich nach rechtem Mausklick unter Tabellen mit "Tabellen verknüpfen ..." für jede einzelne Tabelle. Bei vielen Tabellen gerät das zu einer gesundheitsgefährdenden Klickerei. Aber auch hier lässt sich der Prozess wie folgt automatisieren

Beim Abbilden von Indizes und Integritätsbedingungen aus Tabellen, die unter Access mit der Jet-Engine erstellt wurden, sind leider noch folgende Unebenheiten zu beachten:

Unter Access ist es möglich, Spalten als Primärschlüsseln zu erklären, die laut Definition Nullwerte enthalten können. Das ist schon was Besonderes, denn nicht mal der SQL-Server erlaubt das. Keine vernünftige Datenbank lässt diesen Unsinn zu, also auch DB2 nicht.

Das hat allerdings die unangenehme Konsequenz, dass der Versuch der beschriebenen automatischen Anlage eines Primärschlüssels auf eine Spalte, die laut Definition im Access Nullwerte enthalten darf, nicht möglich ist. Am Besten definiert man die Tabellen gleich standardgemäß oder korrigiert diese Nachlässigkeit noch vor dem Export der Tabelle.

Falls dies aus irgendeinem Grunde nicht möglich ist, bleibt noch die Möglichkeit, in der DB2 Steuerzentrale die Definition solch einer Spalte zu ändern bevor sie zum Primärschlüssel erhoben wird. Bei vielen Änderungen dieser Art geht das auch per Script, die Änderungsanweisung ist allerdings recht unhandlich.

Übrigens: Auch Access kann keine Wunder vollbringen und aus sinnvollen Einschränkungen sinnlose Erweiterungen machen. Jeder Versuch, einen Nullwert in einen Primärschlüssel einzugeben, wird mit einer Fehlermeldung bestraft. Warum man allerdings bei der Definition einer Tabelle solche einen Quatsch zulässt, bleibt mir unerschlossen.

Neue Software, neue Hardware ... das war viel Arbeit und Ärger innerhalb einer Woche.

Das Letzte zuerst: Es war nur eine AP-Ersatzbeschaffung, ein Linksys WRT54GS - das "S" steht für "Speedbooster", mal sehen, ob das tatsächlich was bringt. Die Installation war eine Belastung für meine schon durch Wireshark gestressten Nerven. Warum, um Himmels willen, kann man bei der Konfiguration des lokalen LAN-Interfaces die Subnetmask nur aus einer Liste vorgegebener Masken auswählen. Diese Liste enthält natürlich nicht die 16-er Maske "255.255.0.0", die ich für das Netz hier gerne hätte. Warum bloß nicht? Also entweder darf ich mich als Hacker betätigen oder ich unterwerfe mich dem Linksys-Diktat.

Das Drama ging aber los mit Wireshark, einem allgemein anerkannten "packet sniffer". Nachdem mich ein Artikel in der CHIP wiedermal an Wireshark erinnerte, habe ich es vergangenen Sonntag kurz vor Mitternacht endlich installiert - auf Kosten einiger Stunden Schlaf.

Denn während der Installation verabschiedete sich meine Verbindung zum AP wortlos. Bei näherem Hinsehen stellte sich heraus, dass die LAN- und WLAN-Netzwerkverbindungen verschwunden waren. Herstellen irgendeiner Verbindung zu einen Netzwerk mit Wireshark war wie auch immer nicht möglich. Deinstallation von Wireshark und Neuinstallation des WLAN-Treibers brachte ebenfalls keine Änderung. Meine Netzwerkverbindungen blieben verschollen.

Per Mausklicks, Makro oder VBA-Routine lassen sich in der Jet-Engine unter MS Access gespeicherte Tabellen wie beschrieben leicht nach DB2 migrieren. Eine Datenbank besteht aber nicht nur aus einer zusammenhanglosen Ansammlung von Tabellen. Die Access-Exportfunktion transportiert eigentlich nur Struktur und Daten von A nach B, ignoriert aber Indizes, Primär- und Fremdschlüssel.

Ohne ihn jemals angewandt zu haben, bin ich mir sicher, dass MS mit seinen Upsizing-Agenten auch diese Datenbank-Objekte migriert. Leider eben nur auf den SQL-Server. Als Strafe dafür, dass ich die schöne neue MS-Welt frevelhaft verlassen will, muss ich leider eine Extrarunde programmieren. Aber danach lassen sich auch Indizes und Schlüssel nach DB2 portieren.

Dazu muss ich nur die TableDef-Objekte ausbeuten, so wie ich es für die Export-Routine für alle Tabellen meiner Access-Anwendung getan habe - eigentlich nur eine Schleife um "DoCmd.TransferDatabase". Mit diesem Kommando übertrage ich Struktur und Daten einer Tabelle, das ist dann aber auch schon alles. Beim Transfer von Indizes oder Integritätsbedingungen helfen wieder die TableDef-Objekte. Hier finde ich die Eigenschaften, die ich zur Erstellung geeigneter "create index" oder "alter table" benötige.

Für meine VBA-Exportroutine sieht das im Wesentlichen so aus:

Viel Arbeit für so gut wie nichts. Das ist das mein Schlussfolgerung aus der CHIP-Titelstory "Wer braucht Vista?". Meine Antwort also: Ich brauche es nicht. Anhand der Liste "Wo ist Windows Vista besser als XP" frage ich mich, wer überhaupt VIsta braucht.

Vielleicht hätte ich zur Entscheidungsunterstützung vor einigen Monaten die Computerwochen-Serie über Vista lesen sollen. Die Fülle an Artikeln, Worten und Buchstaben fand ich allerdings für meine Zwecke übertrieben. Da lobe ich mir doch die Kurzfassung in der CHIP.

Was wird dort also als Verbesserungen in Vista aufgeführt? Der Aero-Desktop? Interessiert mich nicht. Der verbesserte Explorer? Nett, aber brauche ich das?

Da ist die verbesserte Performance beim Booten schon bemerkenswerter. Aber ich boote diesen Rechner nicht so häufig, dass mir dies signifikante Vorteile bringen würde.

Bleiben noch als für mich möglicherweise interessante Neuerungen die verbesserte Speicherverwaltung ("macht Bluescreens seltener"), das "Synchonisierungscenter" und die verbesserte Sicherheit. Von Letzterem sollte man aber sich aber keinen Quantensprung erwarten.

Aber all dies rechtfertigt nicht den Aufwand und Ärger, der mich bei einer Migration erwartet.

Irgendwann wird sich diese Frage nicht mehr stellen. Nämlich dann, wenn mein nächster Rechner mit vorinstalliertem Vista kommt. Aber lohnt es sich für mich, heute und jetzt mein XP zu Vista upzugraden?

Aus Prinzip sage ich schon seit langem "Nein". Nun erhält diese kategorische Absage Unterstützung und Grundlage durch einen hilfreichen CHIP-Artikel. Ganz neutral wird in Ausgabe 03/2007 (S.44) gefragt "Wer braucht Vista" - ich würde eher daraus ein "Wer braucht schon Vista?" machen. Unter der Überschrift "Wo Windows Vista besser ist als XP" (S.46) werden eingie Pros gelistet, gegen die ich dann den beschriebenen Aufwand einer Migration gewichtet habe. Heraus kam: Für viel Arbeit erhalte ich so gut wie nichts. Es besteht also kein Grund zur Eile. Der nächste Computer kommt bestimmt und damit Vista.

Während in CHIP die Liste der Verbesserungen mit weniger als einer halbseitigen Tabelle sehr überschaubar gehalten ist, erstreckt sich die Beschreibung einer Neuinstallation und eines Upgrades über 2 1/2 Seiten. Das vermittelt die Aussicht aus viel Arbeit samt reichlich Ärger bis hin zu reiner Wut. Als Beleg einige Zitate:

Betriebssysteme aus dem Hause Microsoft sind ein Sicherheitsrisiko.

Das wird sich auch mit Vista nicht ändern. Laut Chip ist Vista zwar sicherer als XP, aber sowohl Linux als auch Apples Mac OS sind im Vergleich dazu eindeutig die bessere Wahl. Auch Vista beseitigt nicht die althergebrachten Schwachstellen.

Chip vergleicht in Heft 03/2007 unter dem Titel "Sicherheits-Test Betriebssysteme" Mac OS 10.0.4, OpenSuse 10.1, Windows XP (SP2) und die finale Version von Vista. Für Vista-Fans sollte das Ergebnis ernüchternd sein. Zitat: "Damit haben wir nicht gerechnet: Nicht nur unter XP, sondern auch unter Vista läuft der Eindringling, ohne dass ein Schutzmechanismus greift."

Hilfreich und deutlich sind auch die Aussagen der Tabelle "So sicher sind die Betriebssysteme wirklich". Hier einige Zitate zu Linux und Vista: