ARTGATE und MS-SQL

[ILEMax]

@DB
kann es sein, das das Passwort auf 10 Zeichen beschränkt ist?
Und der user in Großbuchstaben sein muß?

Oder wird das im LOG nur so dargestellt ?

[BenderD]

... das hängt davon ab, woher der User kommt. Wenn Benutzer und Kennwort beim sql connect mitgegeben werden, dann hängt es von DB2/400 ab, was da an ArdGate durchgereicht wird. Probleme gibt es dann, wenn der user case sensitive ist und die Länge ist auf 10 Stellen beschränkt.
Das kann man umgehen, wenn man den Benutzer und Kennwort in den global.properties hinterlegt:
ard.properties.MYRDBNAME.user=myUser
ard.properties.MYRDBNAME.password=myPassWord

das überschreibt dann die Eingabe beim connect und wird transparent durchgereicht.

D*B

PS: existieren muss der remote user lokal nicht.

[Fuerchau]

https://docs.microsoft.com/de-de/dot...-in-sql-server

Das Problem ist, das die Standard Methode die Windows-Authentifizierung ist, die hier natürlich nicht geht.

Integrated Security=false;

Des weiteren muss der User ggf. noch extra in der DB berechtigt werden, da standardmäßig AD-User in der Form "Domäne/UserName" mit ihrem Kennwort angemeldet werden.
Vielleicht muss auch noch die Nicht-AD-Anmeldung bzw. die gemischte Anmeldung am SQL-Server erlaubt werden.

[ILEMax]

@DB
DAS wars, danke
vllt kannst du das bei Gelegenheit in der Doku ergänzen

@alle
Danke für Eure Bemühungen

[ILEMax]

Sehr seltsam.
JVAGATE gestartet
läuft

STRSQL
Connect to XXXXX01
funktionierte

select * from DB.dbo.efm_Tabelle
funktioniert

disconnect all
finktioniert

JVAGATE beendet (mit 4 * immed) oder geht das anders?
Weg isser


JVAGATE gestartet
läuft

Connect to XXXXX01

Weitere Nachrichteninformationen

Nachrichten-ID . . . . : SQL7802 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Information

Nachricht . . . : Ausnahmebedingung bezüglich Verbindung - SQLSTATE 08003,
SQLCODE -30061.
Ursache . . . . : Im Anwendungsserver ist eine Ausnahmebedingung für die
Verbindung aufgetreten. Entweder werden SQLSTATE und SQLCODE von SQL nicht
erkannt oder GET DIAGNOSTICS DB2_TOKEN_STRING ist für die entsprechende
SQL-Nachricht nicht gültig.
Der GET DIAGNOSTICS MESSAGE_TEXT lautet .
Der GET DIAGNOSTICS DB2_TOKEN_COUNT ist 0.
Der GET DIAGNOSTICS DB2_TOKEN_STRING ist .

geht das nur ein mal am Tag? <Scherz>

Was hab ich falsch gemacht?

[BenderD]

Sehr seltsam.
JVAGATE gestartet
läuft

STRSQL
Connect to XXXXX01
funktionierte

select * from DB.dbo.efm_Tabelle
funktioniert

disconnect all
finktioniert

JVAGATE beendet (mit 4 * immed) oder geht das anders?
Weg isser


JVAGATE gestartet
läuft

Connect to XXXXX01


geht das nur ein mal am Tag? <Scherz>

Was hab ich falsch gemacht?

... JVAGATE ist ein Server Job: einmal starten, dann einfach laufen lassen.

Ansonsten noch:
- remote connections laufen unter commit, was für den disconnect bedeutet, dass der nur an einer commit grenze geht. Am einfachsten ist:
exec sql connect to myrdb;
// wenn alles fertig ist:
exec sql release myrdb;
exec sql commit;

- disconnect all beendet alle connects, auch den lokalen (den SQL implizit gemacht hat). Das hat ungewollte Auswirkungen auf nachfolgende Programme im Job und sollte man bleiben lassen.

- get diagnostics ist nyi (not yet implemented)
- relevant ist der SQLSTATE, SQLCODE wird lediglich von ArdGate vom SQLSTATE abgeleitet und ist nur ein Schätzwert.
- in der Doku und im Verzeichnis JVATEST.LIB sind Beispiele, an denen man sich orientieren kann (und sollte).

D*B

[Fuerchau]

Wobei ein Disconnect ignoriert wird (SQLCODE), wenn ein Commit noch offen ist.
Nach einem Select ist der i.d.R. jedoch nicht erforderlich.

[ILEMax]

Hallo *ALL,

Das funktioniert erstmal ganz gut, Danke D*B!!

Eine Frage / Bitte hätt ich noch:
Wenn ich das interaktiv im STRSQL mache, sind danach meine Sitzungsattribute verstellt.
Da passt nix mehr.
Gibt es eine Möglichkeit
- Diese nicht zu verändern (ovrdbf lib/file tofile qtemp/file ovrscope(*job)
- die vorher zu sichern und danach zu restoren

Danke
Der ILEMax

[BenderD]

... remote connects erfordern in jedem Fall commit, was automatisch geändert wird, falls erforderlich. Sinnvoll ist auch naming(*SQL). STRSQL merkt sich das user und session bezogen, man kann aber auch die Startoptionen beim Aufruf mitgeben. Patentlösung kenne ich da eigentlich keine - am ehesten noch einen eigenen Startcommand oder sich an *SQL und commit gewöhnen (mache ich eh seit langem).

D*B