MS Office Verknüpfung Dateitypen wiederherstellen

Unter gewissen Umständen, wie zum Beispiel durch die Parallelinstallation von Open Office, kann es vorkommen, dass die Office-Dateitypen (doc, docx, xls, xlsx, etc.) nicht mehr den Microsoft Programmen zugeordnet sind oder gar keine Zuordnung zu irgendeinem Programm mehr vorgenommen wurden. Da es sich um recht viele unterschiedliche Dateiendungen handelt, kann die manuelle Zuordnung ein mühsames Geschäft sein. Einfacher geht es, wenn die entsprechen Office-Programme mit dem Parameter -r aufgerufen werden. Dadurch erfolgt die automatische Zuordnung aller Dateitypen.

Diese Version des Citrix Receivers unterstütztdie ausgewählte Verschlüsselung nicht

Ich verwende den Citrix Receiver, um mich zu einem Server eines Kunden zu verbinden. Tatsächlich funktioniert die Lösung erstaunlich stabil und zuverlässig, jedoch noch einem Update der Softwareversion auf dem Server, brach mein Receiver den Aufbau der Verbindung mit folgender Meldung ab:

Diese Version des Citrix Receivers unterstützt die ausgewählte Verschlüsselung nicht.

Keine Frage, wenn die Version des Servers und Receivers nicht mehr kompatibel zueinander sind, darf die Software auch ihren Dienst quittieren. Allerdings führte die Deinstallation und Installation der aktuellen, kompatiblen Version zu keinen Erfolg.

Die vollständige Deinstallation muss manuell erfolgen:

  1. Citrix Receiver deinstallieren
  2. Ein eventuell vorhandenes Citrix-Browserplugin deinstallieren
  3. Neustarten
  4. Den kompletten Ordern „ICA Client“ unter Programme\Citrix bzw. Programme (x86)\Citrix löschen
  5. Im AppData Ordern des eigenen Benutzerprofils Unterordner Local\Citrix (%userprofile%\AppData\Local\Citrix\) den Ordner Receiver löschen
  6. In der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Citrix den gesamten Zweig „ICA Client“ löschen. Auf 64-bit Systemen findet sich der Ordner unter HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432\Citrix
  7. Neustarten
  8. Aktuelle bzw. zum Server kompatible Version des Citrix Receivers installieren.

T-SQL Zeichenkette mit Datentyp text vergleichen

Je nachdem, wie eine Datenbank aufgebaut ist, kann es vorkommen, dass ein als varchar oder nvarchar geführtes Feld mit einem Feld vom Typ text verglichen werden muss.

Ein trivialer Versuch wie der folgende

SELECT * FROM Zeiterfassung WHERE UserName = 'TF'

wird mit nachfolgender Fehlermeldung quittiert:
The data types text and varchar are incompatible in the equal to operator.

Soll ein solcher Vergleich zu einem Resultat führen, so muss ein Datentyp in den anderen konvertiert werden, dabei ist jedoch darauf zu achten, dass der zu konvertierenden Datentyp die Feldlängen nicht überschreitet. Für gewöhnlich sollte jedoch ein convert(varchar(max),datenfeld) ausreichend sein.

SELECT * FROM Zeiterfassung 
WHERE CONVERT(varchar(max),UserName) = 'TF'

T-SQL Primärschlüssel zurücksetzen

Mit Hilfe des DBCC CHECKIDENT Befehls des MS SQL Servers lässt sich der Primärschlüssel mit Identitätsspezifikation einer Tabelle neu vergeben und steuern. Neben wir an, in einer Tabelle „Adresse“ sind hundert Datensätze enthalten, mit dem Primärschlüssel beginnend bei 1 und endend bei 100. Möchten wir nun, dass der nächste eingefügte Datensatz den Schlüssel 250 enthält, können wir dies mit folgenden Befehl erreichen:

DBCC reseed: id  bei 250 fortsetzen
DBCC reseed: id bei 250 fortsetzen

Wenn man sich zum Beispiel innerhalb eines Unit-Tests auf Datensätze aus einer Datenbank beziehen muss, ist sicherzustellen, dass spezifische Datensätze über die gleichen Schlüssel zu erreichen sind. Wenn eine Tabelle nicht über TRUNCATE zurückgesetzt werden kann, bleibt nur ein einfacher DELETE. Mit einem anschließendem DBCC CHECKIDENT Befehl, können dann die Schlüssel zurückgesetzt werden, um wie im Beispiel wieder ab Datensatz 250 fortfahren zu können.

Primärschlüssel zurücksetzen nach DELETE
Primärschlüssel zurücksetzen nach DELETE

iCloud Fotos: Sync extrem langsam

Die iCloud von Apple scheint meines Erachtens ein gutes Angebot zu sein, wenn man seine Fotos auf diversen mobilen Geräten wie iPad oder iPhone und seinem Mac synchron halten möchte. Es macht schon Spaß eine Fotosammlung jenseits der 200GB immer dabei zu haben, ohne diese große Datenmenge tatsächlich auf den Gerät vorrätig halten zu müssen. Über die Preise der iCloud lässt sich gewiss streiten, ich persönlich empfinde das Staffelmodell jedoch als fair. Die Preise für Dropbox sind vergleichbar, doch insbesondere die Integration von Fotos ist beim Apple-Pendant zur Dropbox meines Erachtens deutlich schlechter gelungen.

Meine seit den frühen 2000er-Jahren aufgebaute digitale Fotosammlung umfasst mittlerweile rund 220GB und der Upload erfolgt über kriechend langsame 500 kbit/s, so dass bei voller Bandbreite in aufgerundet 41 Tagen alle Fotos und Videos in die iCloud übertragen sein sollten. Gewiss wäre es vermessen zu glauben, die volle Bandbreite stünde stets zur Verfügung, so dass ich  pessimistisch 60 Tage zum Synchronisieren eingeplant hatte.

Zu meinem Bedauern musste ich nach 50 Tagen feststellen, das gerade einmal 59,8GB übertragen wurden; und dass, obwohl durch den Power Nap die Synchronisierung mit der iCloud trotz Energiesparmodus klappen sollte.Bildschirmfoto 2015-08-06 um 22.49.13

 

Leider bieten weder Foto App noch OS X Yosemite ein detailliertes Protokoll, welche Dateien wann übertragen wurden.  Doch mittels des Kommandozeilen-Programms opensnoop lässt sich verfolgen, welcher Prozess auf welche Dateien Zugriff nimmt. Durch einen einfachen grep-Filter auf den Prozess CloudSync kann ich mir einen Überblick verschaffen, welche Dateien derzeit übertragen werden.

sudo opensnoop | grep CloudSync

Bildschirmfoto 2015-08-06 um 22.54.04

Durch Umleitung in eine Protokolldatei mit Timestamp war es mit so möglich in etwa zu ermitteln, wie lange die Übertragung einer einzelnen Datei benötigt. Das Ergebnis ist ernüchternd: Im Power Nap Modus scheint OS X nur einen Bruchteil der Bandbreite zu nutzen, um die Fotos zu synchronisieren. Überdies legt der Sync-Prozess nach jeder Datei eine Pause von einen Minuten ein, bis er mit der nächsten Datei fortfährt.

Abhilfe lässt sich hier zum Beispiel durch Caffeine schaffen, um den Energiesparmodus zu übersteuern – doch von einer zufriedenstellenden Lösung ist der Workaround weit entfernt. Nicht nur, dass mein Mac viel zu viel Storm für eine eigentlich triviale Aufgabe benötigt, sondern die Fotos werden nicht signifikant schneller übertragen.

Die Synchronisierung mit Dropbox war zuvor hingegen in etwa innerhalb er errechneten Übertragungsdauer möglich.

Eigentlich würde ich gerne die Vorteile der iCloud nutzen, um nicht nur ein dezentrales Backup meiner Fotos zu haben (das hatte ich zuvor schon mit Dropbox und das sogar noch in einem verschlüsselten Container), sondern vor allem, um in den Genuss zu kommen überall auf meinem iPad durch meine Fotosammlung Browsen zu können.

Derzeit überwiegen der Nachteile die erhofften Vorteile bei weitem und ich überlege bereits meinen Speicherplan bei Apple zu verändern. Schade, dass es nicht besser klappt. Vielleicht hat jemand ja noch eine rettende Idee.

Meine Optimierungen beschränken sich derzeit auf folgende, auf Beobachtungen gestützte Maßnahmen:

  1. Mit Caffeine oder vergleichbaren Apps den Energiesparmodus umgehen.
  2. Wenn möglich große Dateien wie etwa Videos von der Synchronisation ausnehmen.
  3. Keine weiteren Geräte mit der iCloud verbinden.
  4. Wenn möglich die Fotos in Alben mit weniger als 150 Bildern organisieren.

Diese Maßnahmen haben bei mir zu kleinen Performancesteigerungen geführt.

Nach nunmehr 50 Tagen heißt es für mich: 60GB übertragen, 160GB stehen noch aus. Sollte also nur noch 134 Tage dauern – mit ein bisschen Glück klappt es also bis Weihnachten. 😉

 

Windows Installationsdatum ermitteln

Möchte man herausfinden, wann Windows (funktioniert ab Vista) installiert wurde, so führt der Weg über die Kommandozeile. Dazu im Startmenü nach cmd suchen und die gefundene cmd.exe als Administrator ausführen.

In der Eingabeaufforderung dann folgenden Befehl eingeben:

systeminfo | find /I "Installationsdatum"

Windows Installationsdatum ermitteln

Lokaler Mailserver mit MailCatcher unter Windows

Wer unter Windows Anwendungen entwickelt, die E-Mails versenden sollten, sieht sich schnell vor die Herausforderungen gestellt einen lokalen Mailserver zu Testzwecken aufzusetzen. Der Aufwand dafür ist immens. Hier kommt MailCatcher ins Spiel! MailCatcher ist ein Ruby gem, das einen einfachen SMTP Server und ein Webinterface zur Verfügung stellt.

Screen shot 2011-06-23 at 11.39.03 PM

Eine lokale Ruby Installation inkl. DevKit vorausgesetzt, lässt sich Mailcatcher wie auf der Website beschrieben installieren.

gem install mailcatcher

Nach erfolgreicher Installation kann Mailcatcher durch den Befehl mailcatcher gestartet werden. Als mögliche Parameter können u.a IP-Adresse und Port für den SMTP-Server und das Webinterface angegeben werden. Eine genau Übersicht der Parameter liefert

mailcatcher --help

Ohne weitere Parameter gestartet kann das Webinterface über die URL http://localhost:1080/ erreicht werden.
Der SMTP-Server lauscht auf dem Port 1025, SSL/TLS-Verschlüsselung werden derzeit nicht unterstützt, ebenso ist die Angabe von Benutzernamen und Passwort nicht nötig.

Laravel Database Seeding mit Faker

Das Problem dürfte vielen Entwicklern bekannt sein: Woher bekomme ich Testdaten während der Entwicklung einer Anwendung. Die manuelle Eingabe ist mühsam und kostet viel Zeit und während die Datenbank sich im Entwicklungsprozess verändert, müssen diese Daten immer wieder angepasst oder ergänzt werden.
Laravel bietet mit dem Database Seeding eine einfache Möglichkeit, Datenbaktabellen mit Testdaten zu füllen. Allerdings müssen auch diese zunächst manuell als Array erfasst werden.

Um den Prozess der manuellen Dateneingabe zu automatisieren und auch umfangreichere Datenmengen im Entwicklungsprozess zu verwenden, hat sich im PHP-Umfeld die Bibliothek Faker etabliert. Mit Hilfe von Faker können zufällige Testdaten für einen großen Pool von Datenklassen wie z.B. Vorname, Nachname, Anschrift, E-Mailadressen, Blindtexte bis hin zu zufälligen Bildern generiert werden. Über die Provider steht sogar eine Schnittstelle zu Verfügung, um Faker um eigene Inhaltstypen zu erweitern. Ein herausragendes Merkmal ist zudem die Lokalisierung der Testdaten.

Um Faker in das Laravel-Projekt einzubinden, muss die composer.json um die Zeile "fzaninotto/faker": "1.5.*@dev" ergänzt werden, um die neue Abhängigkeit zu definieren.

"require": {
		"laravel/framework": "4.2.*",
		"fzaninotto/faker": "1.5.*@dev"
	}

Alternative ließe sich die composer.json auch über den Befehl composer require fzaninotto/faker um den Eintrag ergänzen.

Mit dem Kommando composer update wird Faker dann geladen.


<?php

class UserSeeder extends Seeder {

	public function run(){
		// Faker mit deutscher Lokalisierung über Factory initialisieren
		$faker = Faker\Factory::create('de:DE');
		$faker->seed(1234); // Zufallsgenerator initialisieren
		// Wir laden dynamisch einen Provide rhinzu, um Passwörter zu generieren 
		$faker->addProvider(new Faker\Provider\Internet($faker));
		$users = array();
		for ($i=0; $i < 10000; $i++) { // Wir generieren 10.000 Testdatensätze

			$firstname = $faker->firstName; //Vorname über Generator
			$surname = $faker->lastName; // Nachname über Generator
			$initials = $firstname[0] . $surname[0]; 
			// Einen Datensatz für die Tabelle User definieren wir als Array
			// und erzeugen dieses dynamisch über die Faker-Generatoren 
			$user = array(
			'email' => $faker->email,
			'initial'=> $initials,
			'firstname' => $firstname,
			'surname' => $surname,
			'username' => $faker->userName,
			'password' => Hash::make($faker->password()),
			'bio'=> $faker->text(255),
			'confirmation' => str_random(20),
			'confirmed'=> true,
			'registration_date'=> $faker->dateTimeThisDecade($max = 'now')

		);
		DB::table('user')->insert(array($user));
		}
	}
}

Mit dem Befehl php artisan db:seed wird der UserSeeder ausgeführt und erzeugt 10.000 sinvolle Testdatensätze.

Windows Server 2012 R2 Hyper-V Arbeitspeicher 100% belegt

Innerhalb einer mittels Hyper-V virtualisierten Maschine mit installierten Windows Server 2012 R2 kam es zu erheblichen Performanceeinbrüchen. Grund hierfür war ein aus dem Ruder gelaufenes Cachingverhalten bei I/O-Operationen. Mithilfe der Leistungsindikatoren ließ sich der Grund des Problems kaum ermitteln. Abhilfe schaffte hier RAMMap von Sysinternals. Neben den durch Prozesse und Kernel sowie Mappings allokierten Arbeitsspeicher zeigt RAMMap ebenfalls den durch Treiber reservierten Teil des Arbeitsspeichers (Driver locked) an. Der bei virtuellen Maschinen oft verwendete Arbeitsspeicher fällt unter die Kategorie.

rammap

Eine gute Zusammenfassung I/O-Caching und der Belegung des Arbeitsspeichers bei Hyper-V Virtaualisierung findet sich in diesem KB-Artikel.