org.hibernate.MappingException: No Dialect mapping for JDBC type: -9

Folgendes Setup: Play 1.2.5.3, also Hibernate 3.6.10. Damit eine native Query auf einen MS SQL Server.

Folgender Fehler:

WTF? Die Query ist da übrigens nicht erst seit gestern drin, den Fehler gibt es aber erst seit Neuestem.

stackoverflow sagt nun zuerst mal:

The type -9 is java.sql.Types.NVARCHAR

und weiterhin (das liest man auch an anderer Stelle, der Fairness halber), die Lösung wäre:

Kurze Prüfung: Das fragliche Feld ist sowieso ein varchar. Außerdem hat es natürlich normalerweise einen Grund, nvarchar zu benutzen – nvarchar ist ein varchar, das Unicode unterstützt. Das will man nicht zurück casten. Macht also doppelt keinen Sinn. Vielleicht kommt der Fehler initial daher, dass das Feld seit Kurzem mit einem per String.toUpperCase() transformiertem String befüllt wird, vielleicht hilft hier ein String.toUpperCase(Locale), damit nicht implizit ein Unicode-String daraus wird. Klingt irgendwie auch merkwürdig, aber hey: Es ist ein MS SQL-Server! 🙂

Wie auch immer, wir haben durchaus nvarchar-Felder, und wollen die auch nutzen. stackoverflow sagt nun weiterhin, man müsse den nvarchar-Typ explizit bekannt machen, wenn er das im aktuell von Hibernate verwendeten SQL-Dialekt (und das ist hier SQLServer2008Dialect) nicht ist (ist er zwar, aber wenn’s der Sache dient…):

Ausprobiert, geht nicht. Nun gibt es neben registerColumnType auch registerHibernateType (Quelle), und damit geht’s:

Fast vergessen: Das ganze wird dann natürlich auch nicht per XML, sondern per application.conf konfiguriert:

HTH

MS SQL: “DROP COLUMN” mit Defaultwert

MS SQL, once again: Folgendes Skript legt eine Spalte mit Default “1” an:

Aber es legt nicht nur diese Spalte an, sondern auch einen Constraint “DF__lc_storea__isPri__6A85CC04”. Möchte man diese Spalte nun wieder löschen:

dann meldet MS SQL Erfolg (!), tatsächlich aber wurde die Spalte nicht gelöscht m( Besonders schön in Migrationsskripten. Nicht.

Man kann den Constraint nun explizit löschen:

Oder man sucht ihn dynamisch aus den Tiefen des Systems:

HTH

MS SQL: Alle Tabellen leeren

Ich möchte das nicht jedes mal googlen:

In dem Zusammenhang: Flyway initOnMigrate in Play Applikationen:

MS SQL: Datenbanken migrieren

Komplette MS SQL-Datenbanken von einem Server auf den anderen zu migrieren, ist nicht so einfach große Scheiße.

Das geht damit los, dass nicht offensichtlich ist, wie man die Daten aus der Datenbank herausbekommt. Es gibt im “Microsoft SQL Server Management Studio” (alleine der Name!):

  • Rechtsklick -> Tasks -> Daten exportieren (“Export Data”). Hier kann man nur tabellenweise exportieren.
  • Rechtsklick -> Tasks -> Sichern (“Backup”). Hier wird (trotz “Sicherungstyp: Vollständig”) nur das Schema exportiert.
  • Rechtsklick -> Tasks -> Skripts generieren (“Generate Scripts”): Erzeugt eine .sql-Datei, die auch nur dann die Daten enthält (und nicht nur das Schema), wenn unter Erweitert -> Datentypen, für die ein Skript erstellt wird (“Types of data to script”) “Schema und Daten” ausgewählt wird.

Es geht damit weiter, dass .sql-Dateien ab einer gewissen Größe nicht vom Management Studio verarbeitet werden können – sie werden exportiert, aber sie werden nicht wieder importiert. Das geht nur (?) über die Konsole:

Dabei wurde bei mir allerdings die Tabelle dbo.schema_version nicht mit migriert, was Flyway aus dem Konzept bringt. Will man die Tabelle (oder jede andere?) manuell migrieren, muss man darauf achten, welche Sprache eingestellt ist. Kein Witz: Ist der Quell-Server Englisch, der Zielserver aber Deutsch, kann es einen

Meldung 242, Ebene 16, Status 3, Zeile 3
Bei der Konvertierung eines char-Datentyps in einen datetime-Datentyp liegt der datetime-Wert außerhalb des gültigen Bereichs.

(The conversion of a varchar data type to a datetime data type resulted in an out-of-range value) geben. Der Grund: Ein

ist englische Schreibweise (Monat vor Tag), es muss dann

heißen… klar: Die Syntax des Skripts ist natürlich abhängig von der Sprache des Clients, nichts liegt näher m(

UPDATE: Unnötig zu sagen, dass der Import per Konsole unendlich lange dauert.