Firebird to SQL error - due to firewall

This forum topic includes specific steps for setting firewall exceptions so that networked computers can connect through SQL

I am getting a SQL connection failed error when trying to setup the SQL database.

The error popup is as follows:

SQL Connection failed
Check your connction string
Full error was:
A network-related or instance-specific error occured while establishng 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: Nmed Pipes Provider, error: 40 - Could not open a connection to SQL Server)

The server name is correct and I can log into it with no problems using the SQL Management console. I have enabled remote access, TCP and NamedPipes but the above error pops up when running the Firebird to SQL utility in attempt to create the SQL Ayanova database. Any help on this would be greatly appreciated.

Thanks,
Steve

Hi Steve

Are you performing the Firebird to SQL ON the same server itself with SQL is installed and running?
Or are you running the Firebird To SQL from a different computer? On the same LAN? Through remote access? Etc?
What version of SQL? SQL Express 2008, SQL Server 2005, etc?
What operating system?
What specifically is entered in your Microsoft SQL database connection string: ?
When bring up SQL Management Studio, what specifically is the Server Name: listed there?
Authenticating via SQL Authentication?
What is the User ID and password entered there when log in via SQL Management Studio?
Reconfirm again your SQL settings - doesn’t hurt to do so, and sometimes can accidently set them but they are not applied - so check again that your protocols are enabled, remote access if SQL Express 2005, the firewall exceptions, and that both the SQL Database Engine and the SQL Browser services are running.

Let me know

Hi again Steve

Just to be sure, the actual string is NOT in quotes in the field itself right? It just starts with data source=blah blah blah NOT "data source=…

This server does have TCPIP ?
If you go to another networked computer, and ping the server, you can do so?
And if you ping a networked computer from the server, you can do so?

Try disabling the Named Pipes so only TCPIP is enabled.
Reboot the entire server.
Make sure SQL services are all running and up when the server loads again.
Load SQL Management, make sure able to log in.
Now run the Firebird to SQL utility again, editing the string fields - does it now run?

Maybe there is something blocking because of the Vipre Enterprise. Perhaps check with them if any known issues using the SQL Server for other programs if already in use with that Vipre Enterprise?

  • Joyce

Hi again Steve

Any result with doing the above?
Any result with checking with Vipre if it perhaps has addtional security, or some such that is preventing use with AyaNova?

  • Joyce

Ok this is solved! First of all, I dissabled Named Pipes at the server and that enabled me to convert the Firebird database to SQL. Workstation would not connect and had the same error as the server did when the conversion was first attempted.
Re-enabled Named Pipes and tested logging in at the server - login OK

Added the SQL exceptions in the firewall for SQLservr and SQLbrowser but that did not correct the workstation connectivity issue. Checked Technet for SQL Firewall exceptions and found these instructions worked. The article says:

To assign a TCP/IP port number to the SQL Server Database Engine

  1. In SQL Server Configuration Manager, in the console pane, expand SQL Server Network Configuration, expand Protocols for <instance name>, and then double-click TCP/IP.
  2. In the TCP/IP Properties dialog box, on the IP Addresses tab, several IP addresses appear in the format IP1, IP2, up to IPAll. One of these is for the IP address of the loopback adapter, 127.0.0.1. Additional IP addresses appear for each IP Address on the computer. Right-click each address, and then click Properties to identify the IP address that you want to configure.
  3. If the TCP Dynamic Ports dialog box contains 0, indicating the Database Engine is listening on dynamic ports, delete the 0.
  4. In the IPn Properties area box, in the TCP Port box, type the port number you want this IP address to listen on, and then click OK.
  5. In the console pane, click SQL Server Services.
  6. In the details pane, right-click SQL Server (<instance name>) and then click Restart, to stop and restart SQL Server.
    After you have configured SQL Server to listen on a specific port, there are three ways to connect to a specific port with a client application:
    • Run the SQL Server Browser service on the server to connect to the Database Engine instance by name.
    • Create an alias on the client, specifying the port number.
    • Program the client to connect using a custom connection string.

…and these instructions…

To open a port in the Windows firewall for TCP access

  1. On the Start menu, click Run, type WF.msc, and then click OK.
  2. In the Windows Firewall with Advanced Security, in the left pane, right-click Inbound Rules, and then click New Rule in the action pane.
  3. In the Rule Type dialog box, select Port, and then click Next.
  4. In the Protocol and Ports dialog box, select TCP. Select Specific local ports, and then type the port number of the instance of the Database Engine, such as 1433 for the default instance. Click Next.
  5. In the Action dialog box, select Allow the connection, and then click Next.
  6. In the Profile dialog box, select any profiles that describe the computer connection environment when you want to connect to the Database Engine, and then click Next.
  7. In the Name dialog box, type a name and description for this rule, and then click Finish.

It was a firewall issue with the actual ports being blocked. Followed above instructions. I have both TCP and Named Pipes as SQL enabled protocols. Tested connecting to database from workstation and all is working correctly now! :cool: Woohooo! I am now looking forward to going live with the new Ayanova system! Life is good again! :slight_smile:

Joyce, as always, thank you for your prompt support and help steering me in the correct direction. Awesome support as usual :smiley:

Steve

Excellent!

Thank you also for posting here what you did to resolve - as that would help any other company using SQL that encounters a similar issue too!

Pat yourself on the back for great troubleshooting, and have yourself a good weekend!

  • Joyce

You are most welcome and have a wonderful weekend also!

I have “stuck” this in the forum section so that others encountering firewall issue see your steps.

Steve