Nicht passende Lösungsoptionen:

1.) Freigabe des Ordners als Netzlaufwerk und anschließend als Netzlaufwerk einbinden
Problem 1: Das Laufwerk soll für alle Anwender freigegeben sein, es war aber nur für mich sichtbar
Problem 2: Die Anmeldung erfolgte mit anderen User-Daten, bei dem sich das Kennwort regelmäßig ändert

2.) Einbinden mit dem DOS-Befehl subst. Diese auf den ersten Blick perfekte Lösung scheiterte daran, dass die Freigabe nur für den aktuellen Anwender in der aktuellen Sitzung gültig war. Nach dem Abmelden war der Laufwerksbuchstabe wieder weg.

Lösung:

Ich habe einen Eintrag in die Registrierdatenbank (registry) eintragen können, so dass nun für alle Anwender und nach jedem Neustart ein Ordner als lokales Laufwerk verfügbar war:

Beispiel:
Ich möchte den folgenden Ordner als Laufwerk “E:” einbinden: D:\ordner1\suborder2

Dazu ist ein neuer Eintrag (“Zeichenkette”) in folgendem Registry-Baum einzutragen:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices

Als Name der Zeichenkette den Laufwerksbuchstaben einschließlich dem Doppelpunkt eintragen. Im Beispiel also “E:”
Der Wert des neuen Eintrags beginnt immer mit “\??\” gefolgt vom Pfad. Im Beispiel ist dies “\??\D:\ordner1\subordner2″

Nun noch den Server durchstarten und schon ist das Laufwerk permanent eingebunden.

Danke an Windows Reference für den Tipp!


SELECT c.* FROM
INFORMATION_SCHEMA.TABLES t
JOIN INFORMATION_SCHEMA.COLUMNS c ON
c.table_name=t.table_name
AND c.table_schema=t.table_schema
AND c.table_catalog=t.table_catalog
WHERE
t.TABLE_TYPE='BASE TABLE'
ORDER BY c.TABLE_CATALOG,c.TABLE_SCHEMA,c.TABLE_NAME,c.ORDINAL_POSITION


Über den folgenden Pfad findet sich der Schlüssel mit dem Namen “SQLQueryTimeout”:

HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\90\Tools\ShellSEM\DataProject

Dieser steht standardmäßig auf 30 (Sekunden) und kann über einen Doppel-Klick erhöht werden.

javax.security.auth.login.FailedLoginException: The storage control block address is invalid

Das Problem war, dass der Account des Anwenders nur für bestimmte Workstations freigegeben war. Da der ApplicationServer auf einer anderen Maschine läuft, konnte sich der Anwender auch nicht anmelden.

Herausfinden lässt sich dies über einen Windows-Command mit folgenden Befehl (userid bitte ersetzen:

net user /domain userid
....
Workstations allowed         All
....

Die Zeile “Workstations allowed” sollte “All” enthalten oder mindestens den Namen des Servers.

[IBM][SQLServer JDBC Driver][SQLServer]The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 1 (“”): Data type 0×38 is unknown.

Das Problem liegt in einem Treiber-Konflikt: Ich verwende den JDBC-Treiber für den SQL-Server 2000, habe aber einen SQL-Server 2005. Laut Microsoft tritt dieses Problem auf, wenn zuerst der “alte” Treiber geladen wird.

Lösungen:

• Den korrekten JDBC-Treiber von MS installieren — dies klappte bei mir aber nicht, da die Verbindung via JNDI auf einem IBM WebSphere Application Server V5.1 erfolgte. Erst ab dem WebSphere 6.1 wird auch der SQL-Server 2005 unterstützt.
• Anfragen vermeiden, die zu dem Konflikt führen — bei mir ging dies, in dem ich bei einem createStatement die zusätzlichen Parameter entfernte.

SELECT SERVERPROPERTY('productversion'),
       SERVERPROPERTY ('productlevel'),
       SERVERPROPERTY ('edition')

Alternativ kann man auch diesen Ausdruck absetzen:

SELECT @@VERSION

Weitere Infos gibts bei Microsoft im KB321185

Die Einrichtung und der Zugriff der verschlüsselten Derby Datenbank ist vergleichsweise simpel: Zum JDBC-Connect String werden die zwei Parameter dataEncryption=true und bootPassword=2NGWGv.... hinzugefügt, z.B.

jdbc:derby:MyDB;create=true;dataEncryption=true;bootPassword=2NGWGv

Hier ein Screenshot, wie ich die Verschlüsselung im Eclipse Data Source Explorer eingebunden habe:

Über den zusätzlichen Parameter encryptionAlgorithm lässt sich noch der Verschlüsselungs-Algorithmus angeben. Weitere Informationen zu diesem Parameter gibt es in den Derby-Docs.

Da ich den Datei-Namen der zu erzeugenden XML-Sitemap-Datei für jedes Blog bestimmen kann, bennen ich die Datei nach einem einheitlichen Schema: sitemap-<http-host>.xml.

Da ich meine Sitemaps bereits bei Google & Co. unter dem Namen sitemap.xml registriert habe, wäre ein Umstieg auf den neuen Dateinamen etwas lästig. Daher habe ich die Apache RewriteRules herangezogen:

# Sitemap Korrektur

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} sitemap.xml.gz$

RewriteRule sitemap.xml.gz$ /sitemap-%{HTTP_HOST}.xml.gz [L]

# Ende Sitemap Korrektur

Die vier Zeilen bewirken, dass Anfragen an die Datei sitemap.xml.gz — sofern nicht vorhanden — an die Datei sitemap-<Hostname>.xml.gz (intern) weitergeleitet werden.

Das Problem ist, dass Firefox Portable den echten Firefox startet und dieser echte Browser sich zum Standard-Internet-Browser des Windows-Systems macht. Gewünscht ist aber, dass FirefoxPortable gestartet wird.

Ich habe hierfür in der Windows-Registry den folgenden Wert anpassen müssen:

HKEY_CURRENT_USERSoftwareClasseshttpshellopencommand

(Die Registrierdatenbank kann so geändert werden: “Start”-Taste drücken -> “Ausführen” -> regedit eingeben und “OK” klicken).

Hier steht beim Standard-Wert firefox.exe unterhalb des FirefoxPortable Verzeichnisses drin. Dieser Wert muss so geändert werden, dass FirefoxPortable.exe gestartet wird. Allerdings war bei mir noch der Parameter “-osinst” angegeben, der den FirefoxPortable am Starten gehindert hat. Erst nachdem ich den Parameter entfernt hatte, startete mein gewünschter Firefox mit den richtigen Einstellungen.

Zuerst versuchte ich mein Glück in der Experten-Konfiguration des Browser, in dem ich als URL in die Adresse-Leiste meines Firefoxes eingab: about:config. Hier aber gelang es mir nicht eine passende Einstellung zu finden.

Die Lösung hierfür verbarg sich im Unterverzeichnis “OtherSource” der Firefox-”Installation”. Die dort enthaltene Konfigurations-Datei “FirefoxPortable.ini” musst nur in den Hauptordner von Firefox kopiert und bearbeitet werden. Sprich, die Datei musste im selben Verzeichnis abgelegt sein, wie das Programm FirefoxPortable.exe.

Nun noch die Konfiguration bearbeiten und in der Zeile “DisableSplashScreen=false” verändern auf “DisableSplashScreen=true”. Damit ist der SplashScreen beim Starten deaktivert.

Hier meine geänderte Konfiguration:

[FirefoxPortable]
FirefoxDirectory=Appfirefox
ProfileDirectory=Dataprofile
SettingsDirectory=Datasettings
PluginsDirectory=Dataplugins
FirefoxExecutable=firefox.exe
AdditionalParameters=
ocalHomepage=
DisableSplashScreen=true
AllowMultipleInstances=false
DisableIntelligentStart=false
SkipChromeFix=false
SkipCompregFix=false
RunLocally=false

Mit dieser einfachen Änderung ist dieses Fenster beim Starten von Firefox nicht mehr zu sehen: