13.01.2013 Views

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 6: Connecting the <strong>Data</strong><strong>Server</strong><br />

Connection troubleshooting<br />

Here are some reasons why a connection attempt to an MS <strong>SQL</strong> <strong>Server</strong> database<br />

might fail:<br />

• The schema holder is not connected.<br />

• The <strong>OpenEdge</strong> or MS <strong>SQL</strong> <strong>Server</strong> required environment variables are not set<br />

correctly when using the <strong>Data</strong><strong>Server</strong> and a broker. For environment-variable<br />

in<strong>for</strong>mation, see Chapter 5, “Configuring the <strong>Data</strong><strong>Server</strong>.”<br />

• The data source is not registered properly <strong>for</strong> ODBC client connectivity. See your<br />

<strong>Microsoft</strong> <strong>SQL</strong> <strong>Server</strong> documentation <strong>for</strong> in<strong>for</strong>mation on configuring a user,<br />

system, or file DSN to properly connect to your data source.<br />

• You have an outdated version of an ODBC DLL; <strong>for</strong> example, ODBC16.DLL, which<br />

runs on 16-bit machines only. This prevents <strong>OpenEdge</strong> from accessing the data<br />

source, though you might still be able to access the data source through your<br />

ODBC driver using another product, such as Query Analyzer.<br />

• The data source has not been started or is not running correctly. Use the data<br />

source utilities to check the status of the data source and the ability to connect to it.<br />

• The login name and password combination that you provided during connection<br />

is invalid <strong>for</strong> the data source.<br />

• You specified an incorrect ODBC data source name when you created the<br />

schema holder.<br />

For more in<strong>for</strong>mation, see Chapter 8, “Troubleshooting.”<br />

Managing connections to an MS <strong>SQL</strong> <strong>Server</strong> database<br />

Typically, the <strong>Data</strong><strong>Server</strong> maintains one connection to an MS <strong>SQL</strong> <strong>Server</strong> data source.<br />

In some instances, such as <strong>for</strong> joins and catalog queries, the <strong>Data</strong><strong>Server</strong> automatically<br />

starts separate connections. However, there are circumstances in which a <strong>Data</strong><strong>Server</strong><br />

application might require more than one connection. For example, the <strong>Data</strong><strong>Server</strong><br />

cannot send a query to a data source while a stored procedure is still open unless you<br />

specify that the <strong>Data</strong><strong>Server</strong> uses separate connections <strong>for</strong> each request. Depending<br />

on the capabilities of the ODBC driver being used, the following cases may be<br />

candidates <strong>for</strong> using additional connections to accommodate additional cursors:<br />

• Running multiple stored procedures<br />

• Running a stored procedure and a send–sql–statement simultaneously<br />

• Per<strong>for</strong>ming a join on the server<br />

• Creating or updating the schema image <strong>for</strong> the data source<br />

In the first case, additional connections are necessary only if your application executes<br />

additional database requests while a cursor on a stored procedure is still open.<br />

244 <strong>OpenEdge</strong> <strong>Data</strong> <strong>Management</strong>: <strong>Data</strong><strong>Server</strong> <strong>for</strong> <strong>Microsoft</strong> <strong>SQL</strong> <strong>Server</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!