Discussion :

[Médinoc]

Bonjour,
J'ai un problème étrange: Nous avons deux machines se connectant à une base Oracle et possédant deux fichiers tnsnames.ora identiques. Or, sur l'une d'elles, le nom de base n'est pas reconnu dans SQLPlus ou nos logiciels (qui font une erreur ORA-12154). Pourtant, Orable Enterprise Manager voit les bases configurées...

[pifor]

Vous avez peut-être plusieurs ORACLE_HOME sur une machine.

Vérifiez la localisation et le contenu du fichier tnsnames.ora. Par défaut tnsnames.ora est dans <ORACLE_HOME>/network/admin. Il peut aussi être dans le répertoire désigné par la variable d'environnement TNS_ADMIN:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
$ oerr ora 12154
12154, 00000, "TNS:could not resolve the connect identifier specified"
// *Cause:  A connection to a database or other service was requested using
// a connect identifier, and the connect identifier specified could not
// be resolved into a connect descriptor using one of the naming methods
// configured. For example, if the type of connect identifier used was a
// net service name then the net service name could not be found in a
// naming method repository, or the repository could not be
// located or reached.
// *Action:
//   - If you are using local naming (TNSNAMES.ORA file):
//      - Make sure that "TNSNAMES" is listed as one of the values of the
//        NAMES.DIRECTORY_PATH parameter in the Oracle Net profile
//        (SQLNET.ORA)
//      - Verify that a TNSNAMES.ORA file exists and is in the proper
//        directory and is accessible.
//      - Check that the net service name used as the connect identifier
//        exists in the TNSNAMES.ORA file.
//      - Make sure there are no syntax errors anywhere in the TNSNAMES.ORA
//        file.  Look for unmatched parentheses or stray characters. Errors
//        in a TNSNAMES.ORA file may make it unusable.
//   - If you are using directory naming:
//      - Verify that "LDAP" is listed as one of the values of the
//        NAMES.DIRETORY_PATH parameter in the Oracle Net profile
//        (SQLNET.ORA).
//      - Verify that the LDAP directory server is up and that it is
//        accessible.
//      - Verify that the net service name or database name used as the
//        connect identifier is configured in the directory.
//      - Verify that the default context being used is correct by
//        specifying a fully qualified net service name or a full LDAP DN
//        as the connect identifier
//   - If you are using easy connect naming:
//      - Verify that "EZCONNECT" is listed as one of the values of the
//        NAMES.DIRETORY_PATH parameter in the Oracle Net profile
//        (SQLNET.ORA).
//      - Make sure the host, port and service name specified
//        are correct.
//      - Try enclosing the connect identifier in quote marks.
//
//   See the Oracle Net Services Administrators Guide or the Oracle
//   operating system specific guide for more information on naming.

[Vincent Rogier]

Tiens donc, Médinoc, toi ici ?

tes sqlnet.ora sont il les mêmes ?
n'as tu pas plusieurs client oracle sur une des machines ?
etc..

[Médinoc]

Tiens donc, Médinoc, toi ici ?

Bah, que veux-tu, je n'utilise jamais l'horrible Orable (je préfère la magnifique interface graphique de SQL Server, comme tout le monde à mon boulot), donc des qu'on a un problème, on est un peu perdu vu qu'on n'a pas de Redneck au boulot...

[Vincent Rogier]

et sinon, toujours le même soucis ?

[Médinoc]

Ben y'a pas trop de risques que ça change entre 19h et 9h...

[Médinoc]

Tiens, encore plus bizarre: La version qui marche n'a pas de SQLNET.ORA dans <ORACLE_HOME>/network/admin (il n'y a que la version dans SAMPLE)...
Et encore plus bizarre, elle n'a pas de SQLPlus.

[Vincent Rogier]

donc as tu un sqlnet.ora et quel est son contenu ?
As tu une variable d'environnement TNS_ADMIN
sous quel plateforme es tu et quelle version d'oracle ?

[Médinoc]

Grosse update: En fait, SQLPlus marche, seuls les programmes foirent.

Mon manque d'habitude de SQLPlus et le fait que ce soit une version Norvégienne ont entraîné une mauvaise utilisation de SQLPlus (je confondais serveur, user et password).

Mais ça n'explique pas pourquoi les programmes ne marchent pas.

La version d'Oracle est 9.2.0.6.0 sur la machine qui foire (je ne sais pas comment l'obtenir sur celle qui marche, vu qu'elle n'a pas SQLPlus).

Les deux machines ont apparemment oracle dans le path, pas de variable d'environnement TNS_ADMIN ou ORACLE_HOME sur aucune des deux.

[Vincent Rogier]

quel OS client ?
quel est le contenu du sqlnet.ora
quel est le contenu du sqnlet.log situé le répertoire du binaire qui ne se connecte pas ?

[Médinoc]

Problème résolu en supprimant les fichiers .ORA et .CFG supplémentaires sur la machine qui foirait: Maintenant elle a juste le TNSNAMES.ORA, et elle marche à nouveau.

PS: SQLNET.LOG? Kézako?

[Vincent Rogier]

lorsqu'une des erreurs SQL*NET surviennent, elles sont stockées dans un fichier sqlnet.log qui est crée dans le répertoire courant du binaire qui a rencontré l'erreur SQL*NET

[Médinoc]

Eh bien dans ce cas, il y a fort à supposer que System.Data.OracleClient ne repose pas sur ce "SQL*NET" dont tu parles... (oui, j'ai oublié de le préciser, ce sont des programmes pour .Net)

[Vincent Rogier]

en si ...

- ton provider est basé sur OCI
- OCI utilise SQL*NET
- SSQL*NEt est le protocole réseau Oracle

Mais en fonction de l'install ou des options du client sql*net, les logs ne sont pas toujours générés ou générés dans des répertoires qui peuvent varier