The latest full client will work fine with 10g.
I have experienced similar problems using anything other than the full client, even though according to Oracle the others should work.
Just make sure that you completely uninstall all elements of the previous installs as having multiple clients/versions can create another set of problems.
I'm assuming that you are using a "sql server login" for the vendor's server, and you are using that when creating the linked server.
When you use a linked server, a query running on your server connects to the vendor's server. If a firewall blocks your local server from connecting to the vendor's server, your connection attempt will fail.
If connecting directly from your workstation to the vendor's server you go through a different firewall or no firewall, then the connection may succeed.
This scenario matches the behavior you describe. My usual tests would be:
1. Can I ping from my server to the vendor's server? Both by IP and by hostname? ping usually gets through firewalls.
2. Can I connect using SSMS from my server (using an RDP session) to the vendor's server? Both by IP and by hostname?
If you can ping OK but not connect with SSMS, this usually indicates that the ports for SQL Server probably need to be opened on the firewall.
In short, check all of the firewalls involved. That would include any software firewall on your server or on the vendor's server, or any hardware firewall between them.
In these situations, ping and traceroute are your friends. Ping and traceroute may help you locate the IP of the router that doesn't send your packets on to the vendor's server.
Best Answer
SQL Server uses autocommit mode by default. This cannot be changed permanently.
There are two ways implicit transactions (non-autocommit) can be turned on:
At the server level such that new sessions use it by default, using
sp_configure 'user options'-- this may or may not work depending on how SQL Developer was implemented.For a session, using
SET IMPLICIT_TRANSACTIONS ON.