When my colleague attempts to connect he is having no issues. We both have previously been granted access to the server, and have established this is not an issue as my colleague can access the server on my Desktop though I cannot access the server on his desktop. (We both could up until recently when we had had to renew the server connection passwords).
We are both operating off 64-bit, Windows 10 desktops with the same Java version and are both using Oracle SQL Developer 19.2.1.247.
When I go to about properties and compare both in excel we see no differences.
We're quite confused why this is happening.
Related
I have gone through every checklist I could find for configuring SQL Server I could find. I get the same issue on Windows Server 2008 and Windows 7 Pro. First the environment:
SQL Server Express 2012 --installed as main instance (i.e. no named instances)
IP access turned on
Firewall exception for SQLServer
SQL Server user for application access
Windows Server 2008 service pack 2 (also tested with Windows 7 service pack 1)
IIS 7 (also tested with 7.5 with the same results)
.NET 4.0
Our own database code integrated in a .NET MVC 3 application
We have a tool we developed to import data from the old Ruby on Rails app into the new ASP.NET MVC 3 app. The tool can connect to the database using the user account we created, and that's how I discovered some permissions issues for access to stored procedures. This is the tool we are using to verify the connection works.
Data Source=SERVER_IP,1433;Network Library=DBMSSOCN;Database=MYDB;User ID=webuser;Password=webpassword;multipleactiveresultsets=true;
We are using a straight IP address, but to protect our infrastructure I substituted the IP, username, and password. But this is the structure of the connection string we are using. Following the checklists, I was able to connect from another machine on our network using the import tool to the database and import data. I was also able to import data from the same machine that IIS is installed on.
The same connection string provides the dreaded Error 26 "can't find the database server" message on both Windows Server 2008 and Windows 7 Pro:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
I have exhausted every resource I can find, and can't seem to get any closer to an answer. I'm not trying to mount file based database, IIS has read/write access to the web application in any case.
I've ruled out the firewall as a cause for the issue. I've tried the settings with the firewall on and completely turned off. There has to be some other permissions level problem that's happening. Problem is I have no idea what permissions level things I have to check.
After opening a ticket with Microsoft, it turns out I was my own worst enemy. The model classes were set up in their own DLL so I could use them for data migration and other supporting tools for the website.
The DLL was looking in the assembly config for the connection string, and if it wasn't found it would use a reasonable default. Problem is the web application never overrode the location from the Web.config file.
The application couldn't find it because I didn't install the database with the default settings.
I'm using SSH tunneling to connect from a Windows 7 machine to a remote Postgres database.
The tunnel works fine when I use pgAdmin to connect to the remote database. However, I haven't managed to set up an ODBC DSN to connect to the remote database.
I'm creating a System DSN with the same server address/username/password/port/ssl mode as pgAdmin but when I click "Test" I get: "Could not connect to server; No connection could be made because the target machine actively refused it."
Any ideas on where to start debugging? I've ruled out Windows Firewall and remote server configuration, since I can connect with the exact same information in pgAdmin.
Edit
The problem resolved itself after reinstalling Windows.
When debugging this the first thing to do is to start testing the PostgreSQL server with the psql command line utility. This avoids issues of drivers etc to see what is actually going on. Generally speaking my troubleshooting process is:
Can I ping the server?
Can I connect with psql?
When I test my connection via the control panel, does it work?
Now, assuming the problem is on #2, the first thing I would do is try disabling firewalls on both sides (they can be brought up and tuned after trying with both down). This rules out misbehaving firewalls and if it shows this to be a problem then you have the answer on where to troubleshoot.
In my experience Windows firewall can cause all manner of problems. I have even seen it block web pages halfway through the web page. I don't think you can rule out Windows Firewall based on the information you have provided.
If this happens again, the first things to do include disabling both any antivirus software and firewalls.
The other possibility would be a bad ODBC config (maybe port 5423 instead of 5432) or a badly installed DLL of some sort. The latter may be fixed (or not) using sfc /scannow or reinstalling the odbc driver, or other actions.
I am installing Firebird (v1.5.5 - I know it's old but it works) on a new computer which is running Windows 7. I have installed the classic server version as a service. According to documentation at the Firebird site, I modified the firebird.conf file so that IPCName would be global\FirebirdIPI; I did this while the service was not running.
Despite all my efforts, I have been unable to access any of the databases which I copied to this new computer via ISQL. FWIW, the EMS SQL 2005 manager program is successful in accessing the databases, but this program apparently has a direct method which does not require fbclient.dll.
What else should I be checking?
Update from a few days later. After wasting a great deal of time with Windows 7, we decided to downgrade the computer and run XP. After installing the superserver version of FB 1.5.5, I can run my programs and access the databases which are stored on this computer. Attempts to access the databases from other computers connected on the network failed with a variety of error messages, but normally something like 'i/o error for file !firebird!\db\q400.fdb'.
In order to allow people on the network to continue to access the databases, I revived the NT server and started the Firebird service - and all the programs can access these databases successfully from remote computers!
To simplify matters, there are three computers on the network:
the NT server ('zorcomp'), which is running the Firebird service; the fdb files reside on this computer in a directory called 'db' which sits under a shared directory called 'firebird'
a computer running XP, called 'kivserver', which also has a shared directory called 'firebird' and underneath that a directory called 'programs'. Copies of all the fdb files reside in a directory called 'db'.
a computer running XP, which maps \zorcomp\firebird to disk L: and \kivserver\firebird to disk T. From this computer, I can run a program sitting in T:\programs and get it to access successfully a file sitting in L:\db. If I stop the FB service on zorcomp and start the same service on kivserver, the same program cannot access files sitting in T:\db.
I hope this is clear enough. For the life of me, I can't see any difference between all the files which are residing in \kivserver\firebird to those which are sitting in \zorcomp\firebird - but somehow there is a difference!
Obviously, I don't want this arrangement to continue - the NT server has to be retired honourably.
Further edit. I now have the firebird server running on 'kivserver' (NT). I can access the database files locally.
Computers running Win7 can now access these database files using a connection string \\kivserver\firebird\db\database.fdb.
Computers running XP cannot access these database files, although IIRC wisql did succeed with \\kivserver\firebird\db\database.db.
The NT server has been disconnected from the network.
TIA,
No'am
AFAIK EMS SQL uses fbclient.dll (or a wraper around it).
If the only thing you want is to access the databases, I suggest you to do so using TCP protocol instead of the local protocol. To do it connect like this:
c:\>isql localhost:c:\path\to\db.fdb -u sysdba -p masterkey
Unless you're avoiding TCP or the machine have no local interface enabled, it will do the work for you.
Try using this to connect to your database:
hostname:drive:\complete path\filename.fdb
or
\hostname\drive\complete path\filename.fdb
May I know the component you're using?
If your clients are Windows 7 then you might try to use \\hostname\sharename\filename.fdb instead of drive:\filename.fdb connection string.
Several months later, the NT server was somewhat abruptly retired when it displayed 'MBR error' on rebooting after someone unlugged it by accident. Thus I was left with no option but to start running the Firebird server program on 'kivserver'. The connection problems returned.
Eventually I was able to solve the problem with the following connection string
10.0.0.202:e:\firebird\db\manager.fdb
where 10.0.0.202 is the ip address of the server, and e:\firebird\db the directory in which the database sits, relative to the server itself.
I hope that someone else, some time, will find this information useful.
I have a VS2010 DB Project migrated form VS2008 and a couple of schema comparisons created.
I get the following error:
Error 1 An error was received from SQL Server while attempting to reverse engineer elements of type Microsoft.Data.Schema.Sql.SchemaModel.ISqlUser: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Error 2 ExecuteReader requires an open and available Connection. The connection's current state is closed.
I am using VS2010 Premium and SQL Server 20008 R2 on my dev machine.
My database is hosted on local instance of SQL server.
When I use the same schema comparision with a remote server and use the sa login it works. On my dev machine, I tried with sa login as well. but no luck!
Has anyone encountered such an issue and was able to resolve?
Well cracked it! (not sure if that is the solution, at least it now works for me)
The local databases I was using for schema comparison were restored from backups of production databases. The users in the databases will loose their SID (probably) with the ones mapped on the production server.
I simply deleted the database users and recreated them and the schema comparison started working again.
Hoping someone else has already encountered this and has a solution...
I'm trying to install the AppFabric Beta 1 caching service, on a virtual Windows Server 2008 (CacheServer1). My cache configuration information will be held in a SQL Server database on a separate server (SQLServer). As AppFabric only supports Integrated Security for SQL Server, both servers are in the same domain, and I'm installing using an account that has db_owner rights to my VelocityConfig database.
When I run the AppFabric installer and get to entering the connection string for my SQL server, I put in the server name, but when I click the combo box to get the list of databases from the server, it thinks for a minute and then I get a timeout error.
Both servers can ping each other, and I've created a .UDL file on CacheServer1 under the same user, which can connect successfully to SQLServer and retrieve a list of databases.
Can anyone suggest what I need to do to get the installer to succeed?
The solution I found to this was to install the SQL 2008 Client Connectivity bits on CacheServer1, once this was installed I could get a list of databases. Still can't get AppFabric to install successfully but that's another problem for another question I think...
To ensure that there is no network/DNS issues, can you try the following:
1. Use IP address instead of hostname.
2. Are you able to connect to sql server via sql server mgmt studio running on CacheServer1?