SSL-Problem mit jdbc

[KM]

Hallo,

gib im Connection-String mal die Option encrypt=false an. Standardmäßig wird beim SQL-Server 2005 glaube ich die Verschlüsselung aktiviert.

Gruß,
KM

[gue_br]

Hallo,

gib im Connection-String mal die Option encrypt=false an. Standardmäßig wird beim SQL-Server 2005 glaube ich die Verschlüsselung aktiviert.

Gruß,
KM

Hab ich auch schon probiert. Soweit ich es bis jetzt verstanden habe, steuert dieser Parm nur, ob später die Daten verschlüsselt übertragen werden.
Die Anmeldung scheitert aber schon an der SSL-Verbindung.

[Fuerchau]

Ich glaube, hier wirst du fündig:
"WARNING: TDSChannel" When Attempting to Connect - TechNet Forums

[gue_br]

Ich glaube, hier wirst du fündig:
"WARNING: TDSChannel" When Attempting to Connect - TechNet Forums

Danke, da hab ich das mit der verschlüsselten Anmeldung gelesen und das der Parm "encrypten=false" nur für das was danach gilt, gelesen.

Werd mir das mit der JRE-Konfiguration für das JSSE nochmal genau durchlesen und anschauen.

Es ist halt mühsam, wenn man von der grünen Wiese (bzw. Schirm) kommt und in so ein, meiner Meinung nach, komplexes Gebiet vorstößt.

Günter

[gue_br]

Ich habe noch eine Frage zum Speicherort des sqljdbc.jar - Files.
Da ich mittlerweile so ziemlich alle Versionen von 1.0 über 1.1, 1.2 bis 2.0 des Microsoft JDBC-Treiber für SQL Server 2005 ausprobiert habe und nichts geholfen hat, stellt sich mir die Frage, ob die überhaupt verwendet/aufgerufen wurden.

Ich bin nämlich jetzt hergegangen und habe mit wrkenvvar einen falschen Eintrag in CLASSPATH zum Treiber hin gemacht (ich setze das im RPG). Und siehe da, es hat trotzdem gleich nicht funktioniert wie sonst auch.

Eigentlich bin ich davon ausgegagnen, daß der Treiber in dem im CLASSPATH angegeben Pfad liegen sollte:
/QIBM/UserData/Java400/ext/sqljdbc.jar

Oder irre ich mich da.


Danke,
Günter

[BenderD]

ich würde die Finger von dem Wackelhaufen java calls aus RPG lassen. Das wird nie stabil, da die JVM implizit gestartet wird (und wenn das im Job ein anderer Aufruf gemacht hat, dann passts wieder nicht). ich würde auch irgendwelche Treiber nicht global vernageln (korrekter Weise müsste der auch in ...ProdData... liegen), über welchen Weg auch immer.
Ein Java Environment gehört mit java gestartet, da kann man den Classpath per Parameter einstellen und auch z.B.: -verbose angeben, damit man sieht, was da wirklich aufgerufen wird. Wenn ich das aus RPG aufrufen will, dann macht man da einen Serverdienst draus und lässt den asynchron per DataQ oder MSGQ mit dem RPG Teil kommunizieren. Dann wird das ganze auch performat, skalierbar, stabil und wartbar.
Zu letzterem habe ich ein Framework AppServer4RPG auf meiner Homepage und bei Sourceforge.net als OpenSource veröffentlicht.

D*B

Ich bin nämlich jetzt hergegangen und habe mit wrkenvvar einen falschen Eintrag in CLASSPATH zum Treiber hin gemacht (ich setze das im RPG). Und siehe da, es hat trotzdem gleich nicht funktioniert wie sonst auch.

Eigentlich bin ich davon ausgegagnen, daß der Treiber in dem im CLASSPATH angegeben Pfad liegen sollte:
/QIBM/UserData/Java400/ext/sqljdbc.jar

Oder irre ich mich da.


Danke,
Günter

[gue_br]

ich würde die Finger von dem Wackelhaufen java calls aus RPG lassen. Das wird nie stabil, da die JVM implizit gestartet wird (und wenn das im Job ein anderer Aufruf gemacht hat, dann passts wieder nicht). ich würde auch irgendwelche Treiber nicht global vernageln (korrekter Weise müsste der auch in ...ProdData... liegen), über welchen Weg auch immer.
Ein Java Environment gehört mit java gestartet, da kann man den Classpath per Parameter einstellen und auch z.B.: -verbose angeben, damit man sieht, was da wirklich aufgerufen wird. Wenn ich das aus RPG aufrufen will, dann macht man da einen Serverdienst draus und lässt den asynchron per DataQ oder MSGQ mit dem RPG Teil kommunizieren. Dann wird das ganze auch performat, skalierbar, stabil und wartbar.
Zu letzterem habe ich ein Framework AppServer4RPG auf meiner Homepage und bei Sourceforge.net als OpenSource veröffentlicht.

D*B

------------------------------------------

[gue_br]

Danke,

Und was schließe ich jetzt daraus?
Wir haben schon eine JDBC-Verbindung zu einer Oracle-DB und einer SQL-Server 2000 erfolgreich zum Laufen gebracht. Mag sein, daß es bessere Methoden gibt. Aber nach dem die div. Fremdfirmen unfähig sind, ordentliche Schnittstellen bereitzustellen, bleibt natürlich alles bei uns (der i5-Truppe) hängen.
Auf die Schnelle (Anfang Nov.) soll eine Schnittstelle gebastelt werden, denn dann geht ein PC-Fremdsystem in Echtbetrieb und ich hänge jetzt schon drei Tage mit dem blöden jdbc-Zugriff herum.

Ob es angesichts der Tatsachen sinnvoll ist, mir jetzt noch Java oder sonstiges Frame-Zeug reinzuziehen, sei dahingestellt.

Ich bin mir sicher, es klemmt nur an einer Kleinigkeit.
Dachte mir halt, vielleicht hat jemand von den Profis hier im Forum einen brauchbaren Tipp.

Danke,
Günter

[RobertPic]

Welche Javaversion wird verwendet?

Ich habe mal kurz bei mir angetestet und kann die Infos aus dem Internet bestätigen:

Mit der Version 1.2 der JDBC-Treiber haben manche Java 1.4 Implementierungen (dazu gehört auch die i5) das SSL Problem. Mit den Treibern davor (1.0, 1.1) hatte ich keine Probleme. Durch Konfigurationseinträge sollte sich das aber auch für die Version 1.4 fixen lassen (laut Internetforen, beschrieben für Linux).

Mit der (Java) Version 1.5 hatte ich mit keinem Treiber ein Problem.

Getestet hab ich in der QSH:

 java -Djava.version=1.4 -cp MSSQL.jar:ext/sqljdbc_1.2/deu/sqljdbc.jar com.at.od.kattools.TestMSSQL

Die Default-JVM findet man normalerweise mit

java -version

heraus.

Noch zum Pfad /QIBM/UserData/Java400/ext/sqljdbc.jar

Das funktioniert prinzipiell und ist auch recht reizvoll, weil einfach. Diese Jar's sind 1.) heiße Kanditaten um beim Maschinenwechsel vergessen zu werden.
2.) von jedem Javapgramm zu durchsuchen, egal ob sie immer gebraucht werden oder nur für ein paar bestimmte Fälle. (nicht so relevant im Serverbetrieb, aber langsamer Start bei Einzelaufrufen).


/Robert

[Fuerchau]

Ich mache das seit einiger Zeit mit Oracle ohne Probleme (in beide Richtungen).
Hierzu habe ich den Treiber in mein Home-Verzeichnis kopiert und entsprechend im CLASSPATH angegeben.
Der Treiber wird automatisch gefunden.

Ich benutze als Basis die Programme von Dieter Bender mit Modifikation.
Das schöne daran ist, dass ich die Programme auch unter z.B. Eclipse testen kann.

[gue_br]

Danke Fuerchau!

Wir haben auch mit Oracle (in beiden Richtungen) angefangen und dann von einer SQL-Server 2000 gelesen. Jetzt sollte eben SQL-Server 2005 in beiden Richtungen dazukommen.

[gue_br]

Danke,

An Robert:
Wir verwenden Java 1.5 auf i5.