Crystal Report, das .NET Framework 4 und crdb_adoplus.dll

Versucht man einen Crystal Report in einem .NET Framework 4 Projekt zu instanziieren, bekommt man die u. g. Fehlermeldung:

Die Datei oder Assembly "file:///C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet1\crdb_adoplus.dll" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

Um das Problem zu beheben ist mir leider nur eine Möglichkeit bekannt, und zwar muss man in die .config Datei des Projekts folgenden Wert einfügen:

useLegacyV2RuntimeActivationPolicy="true"

im Ganzen sähe das dann so aus:

<startup useLegacyV2RuntimeActivationPolicy="true">
	<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>

Siehe hier auch:
Microsoft
Stackoverflow.com

554

Sollte man beim Abholen von E-Mails via Fetchmail (oder dergleichen) an einen Domino Server die Fehlermeldung

Delivery Failure: SMTP Error: 554 Error writing message to safe storage; message could not be stored to disk

bekommen, dann liegt das ziemlich sicher an einer defekten/beschädigten mail.box Datei auf dem Server.

Der Server muss via "q" beendet werden, dann benennt man die mail.box um in bspw. "mail.box.old". Anschließend startet man den Server wieder und die "mail.box" wird neu erstellt.

VMWare Converter - Cannot obtain hardware information

Wenn man beim Konvertieren einer ESXi VM mit dem Betriebssystem Windows Server 2008 R2 (64 Bit) vom Converter die Fehlermeldung “Unable to obtain hardware information for the selected machine” bekommt, dann liegt das an einem Bug im Converter.

Abhilfe schafft das Ändern des Gast OS Typs der zu konvertierenden Maschine von Windows Server 2008 R2 auf Vista 64 Bit. Nach dem Konvertieren kann man dann den Typ wieder zurück ändern...

HowTo: Wie man User Eingaben validiert

Quelle

Call of Duty 4 Crash Multiplayer Fehler 0a9e372d3b4ad19135b953a78882e789

Tja, was machen, wenn die Call of Duty 4 "iw3mp.exe" beim Starten des Multiplayers mit der Fehlermeldung "0a9e372d3b4ad19135b953a78882e789" abstürzt? Und zwar nur beim Multiplayer. Der Singleplayer Modus läuft 1a.

Habe ziemlich lange im Internet gesucht und bestimmt 10 Neustarts benötigt, um endlich herauszufinden, an was das liegt.

Und zwar liest man oft, es läge am Realtek Audio Treiber, was im Prinzip auch stimmt. Aber die Tipps wie "den Ordner 'Miles' löschen", den Realtek Treiber deinstallieren usw. halfen alle nicht.

Die Lösung ist, in den Einstellungen des Realtek Treibers die Option "Front-Anschlusserkennung deaktivieren" zu aktivieren.

Dazu doppelklickt man zu aller erst auf das hässliche Realtek Icon im Systemtray Bereich (rechts unten bei der Uhrzeit in der Startleiste). Dann klickt man oben rechts auf das Ordner-Symbol:

Es öffnet sich folgender Dialog:

Hier hakt man die oberste Option "Front-Anschlusserkennung deaktivieren" an und bestätigt das ganze mit "OK".

Fertig, jetzt kann Call of Duty 4 Multiplayer wieder gestartet werden.

Assert failure in ENABLEAGENT in Lotus Notes 8

Ja, wenn Lotus Notes dem Benutzer beim Deaktivieren des Abwesenheitsassistenten (oder dem Out of Office Agent) diese Meldung an den Kopf wirft, dann liegt das daran, dass der Benutzer keine Agenten ausführen kann.

Nach einer Änderung des Zugriffstyps auf die eigene Mailschablone von Editor auf Manager hat es dann geklappt.

Geräusche aus derm Serverraum

Wir wurden heute von einer Kollegin darauf aufmerksam gemacht, dass anscheinend laute Pfeif-Geräusche aus unserem Serverraum im Keller zu hören seien.

Wir sind natürlich ("natürlich" -> siehe Link unten) sofort runter in den Serverraum geeilt um die Geräuschquelle ausfindig zu machen.

Nachdem wir uns beide nach längerem Herumsuchen gehörmäßig darauf geeinigt hatten, dass das Pfeifgeräusch (oder Fiepen oder Piepen oder alles zusammen), das klanglich allerdings leider unter schätzungsweise hundert anderen, teilweise ähnlichen Geräuschen geringfügig unterging, entweder von unserem Fax-Server oder von unserem Lotus-Notes Server kommen müsse, informierten wir unsere Kollegen im Innendienst (womit ich übrigens auch Kolleginnen meine, um diesen Satz noch etwas länger zu machen), dass es gleich zu einer kurzzeitigen Serverabschaltung kommen würde.

Als wir dies erledigt hatten, fuhren wir erst den einen 'verdächtigen' Server runter und als es dieser nicht war (das Pfeifen war leider nach wie vor hörbar), auch den anderen.

Zu unserer Überraschung aber war auch nach der Abschaltung des vermeindlichen Pfeifgeräuschverursachers (so die offizielle Bezeichnung) das lästige Pfeifen immer noch gut hörbar.

Fuck!

Ok, was nun? Ich und mein Kollege überlegten erstmal. Auf die Idee, dass es weder der eine noch der andere Server war, bin ich ehrlich gesagt nicht gekommen.

"Woher kann das Geräusch noch kommen?", "Welche Geräuschquellen gibt es im Serverraum außer den Servern sonst noch?", "Täuschen mich meine Ohren?" (ok, den letzten Gedanken hatte wahrscheinlich nur ich)

Und da fiel es meinem Kollegen ein. Das fucking Bedienpanel unserer Alarmanlage ist für uns beim Öffnen und Betreten des Serverraums "unsichtbar" hinter der Serverraumeingangstüre angebracht. Wir schließen also die Türe um das Panel begutachten zu können und sehen alle drei Fehler LEDs aufleuchten.

Nochmal fuck.

Jetzt haben wir unnötigerweise zwei Server heruntergefahren und ebenso unnötigerweise alle Kollegen informiert, eine (unfreiwillige) Pause einzulegen.

So... und was lerne ich nun aus der ganzen Sache?

  1. Niemals die Alarmanlage oder sonstige Geräte in einem Serverraum unterbringen, die dort nicht unbedingt hingehören oder stehen müssen.
  2. Falls sich ersteres nicht vermeiden lässt, dann müssen die Geräte so angebracht werden, dass man sie gleich beim Hereingehen mit einem Blick ablesen kann (und je nach Größe des Serverraums: man diese ZUERST inspiziern muss).
  3. Eventuell eine Serverüberwachungs Software einsetzen (wie bspw. Nagios), mit der man schon vom Schreibtisch aus sieht, dass etwas nicht stimmt oder man sogar automatisch benachrichtigt oder gewarnt (!) wird.

Ok, und nun der Grund, weshalb die Alarmanlage überhaupt erst wie wild gepfeift hat:

Ein Kollege war noch vor der allmorgendlichen Deaktivierung der Alarmanlage als erster unfreiwilligerweise ins Haus 'eingedrungen'. Und zwar ungewollterweise so gewaltsam, dass eben unsere Alarmanlage meinte, sie müsste wie wild pfeifen.