4. JDBC-Treiber-Manager: url

JDBC-Treiber-Manager: url

  • P

    Wie sieht der url zu einer mysql-Datenbank aus?

    In etwa so: jdbc:odbc://www.domain.de:3306/DB-Name ?

    Noch was, beginnt der Zeilen -bzw. Spaltenindex in einer Tabelle bei 0 oder 1?

    0
  • G

    Noch was, beginnt der Zeilen -bzw. Spaltenindex in einer Tabelle bei 0 oder 1?

    Im Gegensatz zu einem Array, beginnt dieser Index mit 1 meine ich mich erinnern zu können 🙂
    Die Treiber URl sieht auch ganz gut aus, da würde cih meine Hand aber nicht für ins Feue legen

    0
  • D

    Also bei mir sieht das so aus:

    jdbc:mysql://localhost:3306/database?user=username&password=password

    Username und Passwort kannst du ja auch anders übergeben - jedenfall muss ich als Protokoll jdbc:mysql verwenden. (verwende nicht die ODBC-Bridge)

    0
  • P

    Ah ok, danke ihr beiden! 🙂

    0
  • G

    destruct0r schrieb:

    jedenfall muss ich als Protokoll jdbc:mysql verwenden. (verwende nicht die ODBC-Bridge)

    Und darf man auch erfahren, warum? Denn ich arbeite mich zur Zeit auch in Sachen SQL API und MySQL ein, und in meiner Quelle wird nur die ODBC-ODBC Bridge genauer erläutert 😞

    0
  • D

    Griffin schrieb:

    destruct0r schrieb:

    jedenfall muss ich als Protokoll jdbc:mysql verwenden. (verwende nicht die ODBC-Bridge)

    Und darf man auch erfahren, warum? [...]

    Naja das mit dem muss war wohl damals etwas blöd geschrieben. Ich weiß nicht, ob es mit meinem Treiber mit einem anderen Protokoll auch geht. (sprich das mit dem jdbc:odbc)
    Jedenfalls habe ich das einfach von Anfang an so gemacht, wie es in der Dokumentation meines SQL-Treibers beschrieben stand.

    btw.: Kann es sein, dass ich mal irgendwo gelesen habe, dass wenn man die Wahl zwischen dem spezifischen Protokoll und der ODBC-Bridge hat auf jeden Fall die Treiber-spezifische Version nehmen soll? Aus Performance-Gründen und weil man so auch Datenbankspezifische Features besser nutzen kann? (bin mir nichtmehr sicher)

    0
  • G

    destruct0r schrieb:

    Aus Performance-Gründen und weil man so auch Datenbankspezifische Features besser nutzen kann?

    Das mit der Performance ist gut. Aber "datenbankspezifisch" impliziert doch schon wieder Inkompatibelität, oder?! Da gilt es wohl, einen Kompromiss zu finden 🙂

    0
  • D

    Aber "datenbankspezifisch" impliziert doch schon wieder Inkompatibelität, oder?! Da gilt es wohl, einen Kompromiss zu finden

    Das stimmt natürlich - manchmal ist inkompatibilität aber kein Problem.
    Im Großen und Ganzen sollte man sich aber eigentlich an den SQL-Standart halten und nicht davon abweichen...

    0
Anmelden zum Antworten