I am trying out Toad DataModeller to see if it fits our company. I have stumbled into one problem that I need to resolve. SInce this is a trial can’t I use Quest support (I guess) so I try this forum instead.
When I try to do a reveres enginering of a database can’t I use the native client sice it wont find the tnsname.ora. The log gives me the following reason: 'Assumed oracle home path: c\tnsnames.ora. ’
This is strange since tnsnames.ora is never placed directly under c: Our clients is pointed out in the registry and I have also add the environment key TNS_ADMIN. Even if I place a tnsnames.ora on C: will it not work since the assumed directory is c without :
Toad for Oracle will find the tnsnames.ora file without any problems but TDM will not. The TCP/IP connection works fine.
According to the Release notes:
Reverse engineering, connection method and tnsnames.ora file: TDM3 follows global system variable or registry key tns_admin and then, when there is no such variable or key, searches for the tnsnames.ora in the install directory.
please remove the manually added TNS_ADMIN environment key from your OS. There might be some problem with loading the key. This key has the highest priority and when loading of the data fails then all other sources are ignored.
Please explain what the “Our clients is pointed out in the registry” exactly mean. Thank you.
BTW: If there is a problem wish tnsnames.ora, you can use TCP/IP. There are various methods how to establish connection to Oracle and if one method doesn’t work for some reason (and all of them should work), then you can use another method.
Thank you for your reply. This will answer the problem that I have. But I think that it must be regarded as a bug since it obviously is a function that is not working.
I stumbled in to a new problem and discovered that TDM only can cope with tnsnames.ora files that includes no more than 1041 entries - we have at least 2975… But this is for another thread.
I have tested TCP/IP and it works well. Although would that require that the user know the information and that is why clients are easier. Also will TCP/IP bypass loadbalancing in the RAC environment.
We have mulitiple Oracle Clients installations on most computers. Since we have so many databases is the tnsnames.ora file generated to the machines every day. It is placed in a specific folder that is pointed out in all clients registry with TNS_ADMIN key. That was what I ment.
yes, this was a bug (CR#66138). It was fixed and the next version/patch will contain this fix. Problem was in loading the TNS_NAMES environment key, not in reverse engineering.
We plan to relese the patch in September. If you wish to solve the problem earlier, you can insert appropriate records to registry, under each client. (registry values will be used instead of TNS_NAMES environment key).
Re number of entries: I created new change request for this (CR#66139). Our developers will look into the matter later.
Re TCP/IP and RAC: for TDM, only one database exists. The rest is out of TDM control.
Thank you for sending us additional information. Your usage of the TNS_NAMES key makes sense, of course.
re number of entries: I successfully tested tnsnames.ora with 3000 entries. There might be some problem in the 1042 entry. (We sent the same information to Linda today).
Can you send us the tnsnames.ora file to modeling@quest.com for testing purposes, please?
I am sorry that I have missed that you have entered an answer to this. I find it a bit strange that it would be a error in the tnsnames file since it work just fine in TOAD and all our other products. However will I try to remove a few hundred hosts around row 1042.
Unfortunally is my trial license over. I have requested a longer period from your sales department and when (if) I get that will I try this out.
The quickest way will be if you send us your tnsnames.ora file. We will test it here and will see where the problem is. Thanks in advance.
(Please send it to modeling@quest.com).
You where correct - there where entries in our TNSNames.ora that was causing this problem. We have around 500 entrie that included a part looking like this:
RDB_DATABASE=@SYS$SYSDEVICE:[SQLSRV$DEFLT]MULTI.SQL)(GLOBAL_NAME=SYSADM.810.IKEA.COM
These are old 7.3 databsaes and they should be removed.