Discussion :

[philippe_Aix]

Bonjour à toutes et tous,

je voudrais insérer dans un script (un bien grand mot pour désigner un fichier BATCH sous windows NT) un test de connexion à une base Oracle.

J'ai pensé faire un SPOOL sous SLQ*Plus et tester l'existence du fichier spoolé. Ca marche si la base est accessible, mais si la base n'est pas accessible SQL+ me demande 2 fois supplémentaires le username/pswd. Hors je veux un script automatique, ce test doit être transparent pour l'utilisateur.

Question : est-il possible d'imposer à SQL*Plus de ne pas re-demander le username en cas d'échec (le mode SILENT ne fais que supprimer l'affichage) ?

Ou alors existe-t-il un outil/utilitaire/méthode pour réaliser ce test ? Il faut que je puisse m'assurer du résultat pour orienter ensuite les traitements réalisés par mon script...

Merci d'avance de votre aide.

Cldt,
Philippe.

[lalystar]

Je pense que tu cherches sqlplus -l

Cf. http://download-west.oracle.com/docs...new.htm#970613

SQLPLUS -L Argument
There is a new command-line argument for the SQLPLUS command, SQLPLUS -L which specifies not to reprompt for username or password if the initial connection does not succeed. This can be useful in operating-system scripts that must either succeed or fail. It is also useful for situations where you do not want to be reprompted for connection details if the Server is not running. This option is not available with the SQL*Plus Windows graphical user interface.

C'est seulement à partir de Oracle 9.2

Laly.

[orafrance]

Avec le spool ça peut marcher mais il faut utiliser l'option -s pour silent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sqlplus -s user/pass@base

[philippe_Aix]

Merci Laly

Mais _honte_ à moi : j'ai oublié de préciser que je tourne sur Oracle 8i... Et il n'est à ce jour pas prévu de bascule sur 9i...

Sinon c'était l'argument dont j'avais besoin... (je l'ai essayé sous 8i au cas où... ... mais ça ne marche pas...)

[orafrance]

A noter que tnsping est aussi là pour tester la connexion

[philippe_Aix]

Merci Orafrance

mais j'ai déjà testé l'option -s :
la fenêtre SQL*plus s'ouvre sans aucun affichage (le silence total), mais en cas d'échec de connexion le username/paswd est redemandé 2 fois...

En plus dans ce mode on ne comprend pas que SQL*Plus redemande le username puisque le curseur se contente de clignoter sans texte affiché... Vu de l'utilisateur c'est vraiment sybillin !

[lalystar]

A noter que tnsping est aussi là pour tester la connexion

Je ne suis pas d'accord ou alors pas entièrement : ta base peut très bien être fermée, ton tnsping peut marcher si le listener fonctionne !

Laly.

[orafrance]

ha oui c'est vrai

J'ai la solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
sqlplus /nolog
spool c:\test_connection.txt
connect user/password@base 
spool off

[orafrance]

Je ne suis pas d'accord ou alors pas entièrement : ta base peut très bien être fermée, ton tnsping peut marcher si le listener fonctionne !
Laly.

ha oui, zut ... décidément, ça ne me réussi pas les journées sans café

[lalystar]

Mais c'est vrai que si le tnsping passe pas c'est même pas la peine d'essayer avec SQL*Plus

Laly.

[orafrance]

c'est vrai mais j'essayerai même pas de me raccrocher aux branches

[philippe_Aix]

le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
sqlplus /nolog 
spool c:\test_connection.txt 
connect user/password@base 
spool off

fonctionne très bien !!!!!

Même sans café c'est du bon Mr Orafrance ! 8)

Par contre (en bon français je suis un éternel insatisfait) cela suppose de créer un script avec "user/password" en clair ... Pas cool...

On peut toujours générer à la volée ce fichier puis le détruire dans la foulée... mais ça reste de la bidouille... Je comprends qu'Oracle ait introduit l'arguement -L pour la v9.2. Il aurait pu le faire avant !

Bon. Pas d'autre(s) idée(s) ? Sinon je prends cette solution avec génération à la volée du fichier ".SQL".

:

[orafrance]

Effectivement, mais même avec le -L le password est en clair

[philippe_Aix]

Bien,

il me semble que c'est le mieux que l'on puisse faire. Je vais implémenter une solution avec génération à la volée du fichier SQL et destruction du fichier après le test pour limiter les dégâts...

Merci à tous les 2 et ... ... pour votre rapidité !

Je marque le sujet comme RESOLU pour les suivants.

Philippe.