I'd like to access a Firebird DB 2.5 from clients. Firebird is installed in Windows 2008 Server, running and operational. There's no connection problems when trying to do it in the server itself. But I'm not reaching do the same when in clients. I've opened 3050 port in Win 2008 Firewall, but nothing happens. When I test the conection using IBExpert, for example, the following erro message appears:
Attempting to connect to:
XX.XXX.XXX.XX:SuperFireBD\SuperFireDB.FDB
Connecting... Failed!
------------------------------------
Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
I/O error during "CreateFile (open)" operation for file "SuperFireBD\SuperFireDB.FDB".
Error while trying to open file.
The system cannot find the path specified. .
Attempting to connect to services manager... Passed!
Disconnecting from database... Passed!
I'm operating over a domain, and I'm not sure wether I have all the grants of the domain's network firewall. Thus, how can I test the 3050 port without telnet? What would I doing wrong? Thanks!
It looks to me it is connecting, but Firebird cannot open your database file.
Try an absolute path like x.x.x.x:c:\SuperFireDB\SuperFireDB.FDB
If that works, I highly suggest making use of aliases.conf located in the Firebird install directory. Then, clients only have to connect to x.x.x.x:SuperFireDB or whatever you decide to name it. If you need to move the database file later, you only have to update aliases.conf and not every client.
Hope this helps! Also if you install firebird server on your machine (no need to run it), you can try to connect through Firebird's own command line client (ISQL).
Some help here: http://www.firebirdsql.org/manual/qsg10-connecting.html.
I met the same problem.
Answer is very simple: fbserver.exe process has no permissions to read/write file *.fdb.
I added read/write permissions for the user SYSTEM on file *.fdb (fbserver.exe runs as windows service as user SYSTEM) and problems disappear.
Related
I was happily using mysql command line in my mac to connect Azure Database for MySql. But all of sudden it started throwing an error saying:
ERROR 2003 (HY000): Can't connect to MySQL server on 'XXXXXXXX.mysql.database.azure.com' (61)
I can see the the database instances is running alright, as I'm able to use the database from an application that is running in Azure.
Has anyone else experienced this?
This problem occurred because the particular network i was connected to not allowing any such connections. Later when i tried from my usual network ( home / office )it got connected. I haven't made any changes in my Azure Db for MySql nor in my local machine, this proves that problem was with that particular network.
It sounds like firewall rules were not setup for that specific network. Can you confirm by looking at this doc?
https://learn.microsoft.com/en-us/azure/mysql/concepts-firewall-rules
Basically, you can click "Add my IP" which would add your current network's Client IP. However, if the network you are on SNAT's out with multiple IP's, you would need to add the entire range from your networking team.
Thanks.
James
I have been trying to run debugging within SQl server management studio and for some reason the debugger has just stopped working.
This is the message I get:
Unable to start the Transact-SQL debugger, could not connect to the
database engine instance 'server-sql'. Make sure you have enabled the
debugging firewall exceptions and are using a login that is a member
of the sysadmin fixed server role. The RPC server is unavailable.
Before this I get two messages, one requesting firewall permissions and the next says 'usage' with some text that makes little sense.
I have looked at the other similar answers on there for the same message which suggest adding the login as a sysadmin but that is already set. I also tried adding sysadmin to another account but that also didn't work.
In the end I was able to start it by right clicking and selecting run as administrator.
I encountered this issue while connected to SQL using a SQL Server Authenticated user. Once I tried using a Windows Authenticated user I was able to debug without issue. That user must also be assigned the sysadmin role.
This happened to me and I could not find the resolution anywhere. My firewall is disabled so I knew that couldn't be the issue.
According to Microsoft: Configure firewall rules before running the TSQL Debugger:
The server needs to communicate back to the client via RPC. The
account under which SQL Server service is running should have
authenticate permissions to the client.
We had a group policy that was preventing this:
Deny access to this computer from the network (Local account, Guests)
In order to resolve the issue, I had to add the SQL Server service account to the local group "Remote Desktop Users" on my desktop. Hope this helps someone else resolve this frustrating issue.
I try with the following steps, but it did not work (maybe because I'm on a PC in a office and I don't have control of the firewall). But you can try the following.
Check the users role:
IF IS_SRVROLEMEMBER ('sysadmin') = 1
print 'Current user''s login is a member of the sysadmin role'
Follow these instructions:
configure the transact-SQL Debugger
Run SQL Server Management Standard Edition 64 bits (with SQL Server Account)
In my case, I received this error message:
Unable to start the Transact-SQL debugger, could not connect to the computer "local".
I end up close the existing connection, then reconnect to my local SQL server using IP 127.0.0.1 and it works.
What helped me, was from here:
SQL Server Management Studio must be running under a Windows account that is a member of the sysadmin fixed server roll.
The Database Engine Query Editor window must be connected by using
either a Windows Authentication or SQL Server Authentication login
that is a member of the sysadmin fixed server role.
So, I've added sysadmin role to my windows account and run ssms as administrator. Debugger started working normally.
In addition to above works, what make our 2 computers remote debug able, was running: (right click on Window's Start button)
System--> Advanced System Properties-->Computer Name-->Click on Network ID... button
and running that wizard to join workgroup on both computers.
I found this solution by looking at my Windows' Event Viewer and looking for a solution to errors with NetBT Source, that is related to workgroup and computer Name.
Update: after some days, it stop working again.
I had the same problem and double checked al recommended settings. At some point I disabled the firewall on the database server and it worked like a charm. By enabling and checking the Firewall log I noticed this entry:
2019-10-31 16:07:50 DROP TCP 192.168.xxx.xxx 192.168.xxx.xxx 65231 61214 52 S 56576751 0 8192 - - - RECEIVE
When I allowed TCP port 61214 (Inbound rule) and switched the firewall back on, it worked. I don't know why this port is needed, maybe some here on SO?
Anyway, maybe the firewall log can be of help too.
Struggled through many hours and got the answer
You can do the configuration through this doc
https://learn.microsoft.com/en-us/sql/ssms/scripting/configure-firewall-rules-before-running-the-tsql-debugger?view=sql-server-ver15
(1) 2 settings need to done on the remote server where Sql server is installed
(2) 1 setting at client computer (i.e) our computer
Has anyone accomplished pushing files to a BOE server using SSIS? I am trying to develop a SQL Server 2008 SSIS package that will push report (Excel) files to our Business Objects Enterprise (BO XI 3.1) server. Via a Script Task, I am using the Business Objects .NET SDK components to authenticate and connect to the BOE Server.
I have a copy of the package deployed to a local instance of SQL Server 2008 running on my Windows XP desktop. The package executes successfully (via a SQL Agent Job) and delivers the file to the designated location on the BOE server.
When I deploy the package to our development SQL server (SQL Server 2008 on Windows Server 2008 64-bit) and attempt to execute the package via a SQL Agent job, I receive the error message "File Repository Server Input is down" when the script task attempts to "Commit" the file to the BOE server. The package is able to open a session with the BOE Server, create a new info object, but fails on the infoStore.Commit command.
I have another SSIS package that executes successfully from our development SQL server - it communicates with the BOE server and searches for user sessions. It does not communicate with the Input File Repository - that seems to be the key distinction.
I have found limited information related to this error that indicates firewalls and ports between the SQL Server and BOE server may be the cause. I have reviewed the BOE Administrator's Guide to no avail (most likely due to my lack of understanding related to firewalls and ports). Both servers are within the same subnet and neither server has the firewall turned on. The ports for the BOE CMS servers and the Input/Output File Repository servers have been set to static port ids. Our network guy indicates there should be nothing preventing communication between the servers based on firewall or port settings.
Any help would be greatly appreciated!
Have you tried all the usual 'run as 32 bit' solutions? I guess yuor SDK is a 32 bit one, not a 64 bit one.
http://www.bidn.com/blogs/ShawnHarrison/ssis/2362/ssis-basics-running-a-package-in-32-bit-mode
However the fact the the SDK works for different services implies that it runs OK in 64 bit. So if you want to troubleshoot ports, I found this link http://scn.sap.com/thread/2027785 which indicates that the BOE ports are 6400 to 6411. To check that a given port is open, you go to a DOS prompt and type
TELNET hostname port
So if your BOE server is BOESERVER then you'd try this:
TELNET BOESERVER 6400
to test port 6400. You should get a black screen to indicate it's connected.
However, again, the fact that you seem to be able to connect and operate but not commit implies there is not a port problem as you can connect, just can't commit.
Are there any logs in the BOE side to give you a better idea of the issue?
A resolution to this issue has been identified and verified. The Windows AD account used by the proxy the SQL Agent job uses to execute the SSIS package did not have sufficient privileges on the network. Our DBA gave the account local Windows administrator privileges on the SQL server and this resolved the "File Repository Server Input is down" error I was receiving.
Thanks to those who responded and gave me other ideas to investigate.
A client of mine gave me a server name which is fully qualified [servername].somedomain.net
to try to connect to their SQL Server instance over VPN.
So I tried, using the username and password they gave me. No luck. I can ping it but cannot connect, I get the error that the username and password is incorrect.
So I log onto the actual server, verify that my login is in security and has rights and it appears there. Workgroup\mylogin and it appears that workgroup\ actually is the same as somedomain.net\mylogin. Because when I try to add somedomain.net\mylogin, it resorts to saying that it's already added which is workgroup\mylogin.
Not sure what else to check here. I gave myself sysadmin role in SQL Server. I can ping the server's IP.
I looked at how they are authenticating me and they have my user in SQL Server set up to use Windows Auth. Well, the error I get is that it cannot trust cross domain when trying to use windows auth when I try to connect locally here in my management studio. I'm connected tot their VPN so what could be the problem?
They're not available right now to try to troubleshoot it and I'm just curious what else I might try to try and resolve this on my own if I can.
Basically, when you failed to connect to your SQL Server, the issue could be:
Network issue,
SQL Server configuration issue.
Firewall issue
Client driver issue
Application configuration issue.
Authentication and logon issue.
Step 1: Network issue
You might be able to make local connection without a working network, but that's a special case. For remote connection, a stable network is required. The first thing to trouble shoot SQL connectivity issues is to make sure the network we rely on is workable and stable. Please run the following commands:
ping -a (use -4 and -6 for IPv4 and IPv6 specifically)
ping -a
nslookup (type your local and remote machine name and IP address multiple times)
Be careful to see any mismatch on the returned results. If you are not able to ping your target machine, it has high chance that either the network is broken or the target machine is not running. It's possible the target machine is behind a firewall and the firewall blocks the packets sent by ping, though. Windows firewall does not block ping (ECHO) packet by default. The correctness of DNS configuration on the network is vital to SQL connection. Wrong DNS entry could cause of all sorts of connectivity issue later. See this link for example, "Cannot Generate SSPI Context" error message, Poisoned DNS.
Step 2: SQL Server configuration issue
You need to make sure the target SQL Server is running and is listening on appropriate protocols. You can use SQL Server Configuration Manager (SCM) to enable protocols on the server machine. SQL Server supports Shared Memory, Named Pipes, and TCP protocols (and VIA which needs special hardware and is rarely used). For remote connection, NP and/or TCP protocols must be enabled. Once you enabled protocols in SCM, please make sure restart the SQL Server.
You can open errorlog file to see if the server is successfully listening on any of the protocol. The location of errorlog file is usually under:
%ProgramFile%Microsoft SQL Server/MSSQLxx.xxx/MSSQL/Log
If the target SQL instance is a named instance, you also need to make sure SQL Browser is running on the target machine. If you are not able to access the remote SQL Server, please ask your admin to make sure all these happen.
Step 3: Firewall issue
A firewall on the SQL Server machine (or anywhere between client and server) could block SQL connection request. An easy way to isolate if this is a firewall issue is to turn off firewall for a short time if you can. Long term solution is to put exception for SQL Server and SQL Browser.
For NP protocol, please make sure file sharing is in firewall exception list. Both file sharing and NP use SMB protocol underneath.
For TCP protocol, you need put the TCP port on which the SQL Server listens on into exception.
For SQL Browser, please put UDP port 1434 into exception.
Meanwhile, you can put sqlservr.exe and sqlbrowser.exe into exception as well, but this is not recommended. IPSec between machines that we are not trusted could also block some packets. Note that firewall should never be an issue for local connections.
Step 4: Client driver issue
At this stage, you can test your connection using some tools. The tests need to be done on client machine for sure.
First try:
telnet
You should be able to telnet to the SQL server TCP port if TCP is enabled. Otherwise, go back to check steps 1-3. Then, use OSQL, SQLCMD, and SQL Management Studio to test sql connections. If you don't have those tools, please download SQL Express from Microsoft and you can get those tools for free.
OSQL (the one shipped with SQL Server 2000) uses MDAC.
OSQL (the one shipped with SQL Server 2005 & 2008) uses SNAC ODBC.
SQLCMD (shipped with SQL Server 2005 & 2008) uses SNAC OLEDB.
SQL Management Studio (shipped with SQL Server 2005 & 2008) uses SQLClient.
Possilbe command use be:
osql -E -SYour_target_machine\Your_instance for Windows Auth
osql -Uyour_user -SYour_target_machine\Your_instance for SQL Auth
SQLCMD also applies here. In addition, you can use “-Stcp:Your_target_machine, Tcp_port” for TCP, “-Snp:Your_target_machine\Your_instance” for NP, and “-Slpc:Your_target_machine\Your_instance” for Shared Memory. You would know if it fails for all protocols or just some specific procotols.
At this stage, you should not see general error message such as error 26 and error 40 anymore. If you are using NP and you still see error 40 (Named Pipes Provider: Could not open a connection to SQL Server), please try the following steps:
a) Open a file share on your server machine.
b) Run “net view \your_target_machine” and “net use \your_target_machine\your_share” (You can try Map Network Drive from Windows Explorer as well)
If you get failure in b), it's very likely you have OS/Network configuration issue, which is not SQL Server specific. Please search on internet to resolve this issue first.
You can try connection using both Windows Authentication and SQL Authentication. If the tests with all tools failed, there is a good chance that steps 1-3 were not set correctly, unless the failure is logon-related then you can look at step 6.
If you succeeds with some of the tools, but fails with other tools, it's probably a driver issue. You can post a question on our forum and give us the details.
You can also use “\windows\system32\odbcad32.exe” (which ships with Windows) to test connection by adding new DSN for various drivers, but that's for ODBC only.
Step 5: Application issue
If you succeed with steps 1-4 but still see failure in your application, it's likely a configuration issue in your application. Think about couple of possible issues here.
a) Is your application running under the same account with the account you did tests in step 4? If not, you might want to try testing in step 4 under that account or change to a workable service account for your application if possible.
b) Which SQL driver does your app use?
c) What's your connection string? Is the connection string compatible to your driver? Please check http://www.connectionstrings.com/ for reference.
Step 6: Authentication and logon issue
This is probably the most difficult part for sql connectivity issues. It's often related to the configuration on your network, your OS and your SQL Server database. There is no simple solution for this, and we have to solve it case by case. There are already several blogs in sql_protocols talking about some special cases and you can check them see if any of them applies to your case. Apart from that, things to keep in mind:
a) If you use SQL auth, mixed authentication must be enabled. Check this page for reference http://msdn.microsoft.com/en-us/library/ms188670.aspx
b) Make sure your login account has access permission on the database you used during login ("Initial Catalog" in OLEDB).
c) Check the eventlog on your system see if there is more information
Reference: http://blogs.msdn.com/b/sql_protocols/archive/2008/04/30/steps-to-troubleshoot-connectivity-issues.aspx
Sorry for this wall of text, i hope that something from here can help you solve your issue!
Regards.
If you want to access that server you are going to need a domain account from that domain or use SQL authentication. I would recommend just using SQL authentication - it's a lot more straight forward - if they allow it.
I had the same problem, other machines could connect to sql server but one computer was not connecting and displaying the error "a network related or instance specific error...", the problem was solved when I changed the network protocol in the login window of SSMS, in advanced options from TCP/IP to Named Pipes. Please see the below screenshots.
Please note that you should be on the same domain, and your credentials should be valid on the server.
My dad built an MS Access Database to do property management. Now he wants to share it with other users over the internet. So I got a hosted SQL Server account at Network Solutions. Now I'm trying to connect the Access 2003 client to a test SQL database using these guidelines from MS:
http://office.microsoft.com/en-us/access/HP052745861033.aspx
However, the error message I get is "Connection Failed because of an error initializing the provider. Server does not exist or access is denied".
I've run the MSComponentChecker to make sure I have MDAC 2.7 or above. Mine is 2.8 SP1 on XP.
It sounds like either:
(1) your workstation is unable to connect to the SQL server instance because
(a) the hostname isn't resolving correctly
or
(b) a firewall in your network or on your workstation is preventing the outbound connection on the needed port
or
(2) you can connect and have the correct username and password but don't have sufficient privileges to get to the database you're attempting to use. Access gives a different error than what you received if you have a bad username or password ("Login failed for user 'xxxx').
You can check the networking by running "telnet example.com 1433" (whatever hostname and port you were given to use; if you weren't given a port, use 1433) and making sure you can connect (the command window will go to a blank screen). If that works, you can then confirm with your provider that the account you're using has been granted the needed permissions. If you can't telnet to the address you need, check you have the right hostname and the existence of any firewalls.
After a little more research, I figured it out.
In MS Access 2003, you have to enter the server name in this format:
serverName\instanceName,portNumber
This is a BackSlash, not a ForwardSlash. Thank you MS.
Not sure why I had to specify the port number when it's the default.
Special thanks to this post:
http://dbaspot.com/forums/sqlserver-server/251219-error-connecting-remote-server.html
It should be noted that you can't do much design work in Access 2003 once you are connected. So I needed to upgrade to 2007 to change the SQL schema. Hopefully, 2003 users will still be able to connect and use the app.