This is correct. Pharos Reports uses Crystal Reports Runtime as the platform for the report system. It requires access to the SQL server database, typically using port 1433, to function. You are correct to open that port in order to allow Pharos Reports to run from another computer.

Is it possible the SQL Server administrator may have set up the SQL Server to use different ports for communication (and didn't tell you)?

Is there a fairly simple way to check/detect which ports should be used?

If there a fairly simple way (aside from normal usage) to test port communication reliability?

My SQL Server is most likely using the typical ports (ports 1433 (TCP) and 1434 (UDP) according to Pharos documentation), but I'm seeing (only just recently) intermittently the same error Takaki Matsumoto is seeing. Since my SQL Server is not on my principle server (but the "Pharos Database Server" service is running on the principle server), would I need those ports to be open to the server hosting the SQL database, or the Pharos principle server (where the "Pharos Database Server" service resides)? Or to both? Or just between the server hosting the "Pharos Database Server" service and the SQL Server?

Yes, it is possible to use different ports other than the default. You'd have to check with your SQL administrator to know for sure what they use. Also, yes, if your SQL server is separate from the Uniprint Principal server, then you'll need to allow access to both servers on the necessary ports from the computer that is running Reports. See a snippet below from the Installation and planning guide for the ports and note that it refers to the default ports. As for why you are having intermittent problems, I can't say. That's not normal though.

Pharos Reports makes use of an ODBC configuration on client computers, or utilizes the information in the \Database registry key on the Principal server, to make its SQL connection. It does not go through the Pharos Database Service / Principal server to make its connection.

Because the Pharos Reports application is 32-bit, it will use the 32-bit ODBC management application and drivers on the local computer if the operating system is 64-bit. This is found in C:\Windows\SysWOW64 as odbcad32.exe. This is, in the SQL world, the better way of determining client-side configuration is correct. So once launched:

The User DSN tab comes up first. This is fine if you are only configuring a database connection for your account. If you've opened the application with administrative access, you can also configure a System DSN, which allows all users access from that computer. This is how Pharos Reports creates its DSN.

Click the "Add..." button from the User DSN tab.

and slide all the way down to "SQL Server" and click the "Finish" button.

This starts the "Create a new Data Source to SQL Server" wizard. You need to fill in, at the very least, the "Name" and "Server" fields. Note that if you are using SQL named instances, that has the format Server\Instance (as I have in my example). Descriptions can help identification, but aren't required.

Click the "Next" button to continue.

The next step configures your credentials and client configuration. Within the Pharos software, database access is normally via a SQL Login, so choose the second radio button.

Type the valid SQL login ID and its password. Then click the "Client Configuration" button.

The Client Configuration button takes you to the "Add Network Library Configuration" interface, which is where a lot of the magic happens. In most cases, you won't need to tamper with the "Server alias" or "Server name" fields. Verify with the SQL administration team that TCP/IP has been enabled on the SQL server (it is often not), because that is how you will need to connect. Also, SQL Server from 2005 has come to support dynamic, versus specified, TCP ports for client access. If your SQL Server instance has been configured for dynamic ports, go ahead and leave that checked (it is by default in this wizard). If the server is listening on a non-standard (so, not TCP port 1433), untick the dynamic option and plug your server's port in the "Port number" field.

Click "OK" when finished. NOTE: If you know that your server is using a non-standard TCP port up front, you can bypass the "Network Library Configuration" component and specify this port within the "Server" field of step 3, above. For example, if the server's TCP port was 14033, I would have specified the server name and then added a comma then the port. For example: "SO-DCSQL\BP52,14033". Of course, do not use the quotation marks; I just use those to separate the entered text from the explanation.

Click "Next" to move on to the next step. After you click "Next" the New Data Source wizard will attempt to connect to your server with the supplied credentials. If you are successful, you will see the screen in step 7. If not, you will get some kind of SQL error. The Internet has several resources for troubleshooting connectivity errors.

Once connected, you will get some more connection options:

Each SQL Login can be provided a default database for the connection. In this instance, the "sa" login has the 'master' database as its default. It is preferable to tick this box and select the database (pharos, psbprint, etc.) for the connection. That way, your query/application does not need to preface everything with "USE pharos GO" all the time. You can keep everything else set as it is, and click "Next."

The almost last screen of the wizard can usually be ignored.

Just click "Finish."

At the end! All you really have to do here is validate your settings by clicking the "Test Data Source..." button.

which looks like this, when all is well:

I usually see the following cause the problems:

The server isn't configured to support TCP/IP connections. That's usually on new servers. Established servers don't have this problem unless a DBA makes a mistake.

The server has been configured for a non-standard (not TCP 1433) port, but nobody has relayed that information. This can happen on both new and existing servers. I know of organizations that change their TCP port assignments for SQL servers semi-annually.

The server isn't configured to support remote connections to the database. Again, usually on new servers. This is a "noob" mistake when it occurs. Please note that this is how all "Express" editions of SQL Server (any version, since 2005) install.

A named instance is in use, but that hasn't been communicated.

DNS resolution is getting in the way.

The SQL Server is licensed "per connection" instead of "per CPU" and there aren't any more client connection licenses available.

The SQL login account specified for the connection is using an invalid password (maybe unintentionally; in SQL Server 2008 and newer, password enforcement and aging are default options).