SQLServer Substring und Oracle Substr

Ich dachte ja eigentlich, dass, wenn man ein SQL-Skript aus einer Oracle-Anwendung auf den SQLServer migriert, man nur das „substr“ durch „substring“ ersetzen muss.

Klappt fast immer. Nur, wenn man den <startindex> von substr(‚text‘,<startindex>,<länge>) kleiner als 1 wählt (z.B.) substr(„abcdefg“,0,2) bekommt man bei Oracle „ab“ – beim Sqlserver aber nur „a“.

Grund: Der Sqlserver liefert *immer* einen String der Länge <startindex>+<länge>-1 (oder null, wenn das kleiner als 0 werden sollte). Oracle liefert immer einen String der Länge <länge>.

Quellen:
https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions162.htm
http://msdn.microsoft.com/de-de/library/ms187748.aspx

WordPress, Permalinks und der 404 – Fehler

Was lange währt…

Ich war auf der Suche nach dem Fehler, dass meine WordPress-Konfiguration auseinander fällt, wenn ich den Permalink-Typen vom hässlichen Standard ändere.

Egal, was ich versucht habe, es gab einen 404-Fehler (Seite nicht gefunden), wenn ich den Permalink aufgerufen habe.

Die Ursache war einfach:

WordPress bedient sich des Apache-Mods rewrite_module.
Das war auch installiert.

Worpress definiert die Rewrite-Regeln für die hübscheren Permalinks in der .htaccess – Datei.
Die war auch korrekt.

Aber:
Wenn man in der apache2.conf angibt, dass für das Worpress-Verzeichnis gilt:

AllowOverride None

– dann kann die .htaccess – Datei von WordPress auch nicht greifen.

Unschöne Variante:

AllowOverride All

eintragen.

Schöner ist es meiner Meinung nach, AllowOverride None zu lassen – und den Inhalt der generierten WordPress – .htaccess Datei beim Zulassen des Verzeichnisses als Direktiven für das rewrite_module einzubinden. Das geht offensichtlich auch 😉