Connect refused for good credentials

armplinker · May 12, 2016 9:51AM

Version: 3.0.5.1416

I can connect to a particular instance with PL/SQL Developer, but when I attempt to do so from RG Source Control for Oracle, it says invalid login userid or password. I have tried the credentials several times painstakingly to no avail. This is a VPN connection but as mentioned, PL/SQL Developer has no issues with it.

Also for some reason the option to use a SERVICE to connect instead of an SID is not presented in the UI.

Is there an application log that indicates what is going on as it attempts to connect?

I remember vaguely this sort of problem from the older version.

Sarah B · May 17, 2016 11:11AM

Hi Allen,

You try could entering the service name or SID in the SID box using a manual connection as per the following documentation:
https://documentation.red-gate.com/disp ... connection

armplinker · May 20, 2016 8:06AM

The problem is with Source Control for Oracle, not Schema Compare. The latter works fine. It is the Source Control product that is behaving badly. I see at the least these 3 problems:

1) Connections do not work for perfectly good logins that work in another tool at the same time.
2) SID seems to be the only option available in Source Control
3) I frequently get a message that it cannot lock a system file when updating Git from the local files. This trashes the source control local repository (project) and I have had to rebuild it. This appears to be specific to working with Git. I do not see this behavior when I just make a local working folder with no remote repository link.

Another problem which occurs is that any script failures, for example, trying to use Source Control to apply a script to create an index and failing because an index on the same columns already exists, does not seem to exit very gracefully. Yes, it should raise an exception, and report it to the user, and maybe keep going with the remainder of scripts in the 'apply' effort, but that is not what happens. The SC project gets hosed up. SC should never compromise/trash the source control project because a script fails.

Sarah B · May 24, 2016 10:20AM

Hi Allen,

The ability to use the service name depends if an Oracle client is installed on the machine running SOCO.
Do you have the Oracle Client installed on the machine running SOCO? If yes , is it the 32-bit or 64-bit client? It could be that you're using the 32-bit client with the 64-bit version of SOCO in which case you'd need to use the 32-bit version of SOCO instead.

Regarding the connection issue, a bug report has been created with the reference OSC-655.

armplinker · June 3, 2016 9:07AM

OK, then SOCO should report this mismatch rather than act mysteriously IMHO. There must be a signature of some sort that could be checked to ensure that SOCO and the Oraacle client are both 64-bit.

Connect refused for good credentials

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk