OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Connection troubleshooting<br />
Connection failures and <strong>OpenEdge</strong> responses<br />
Here are some reasons why a connection attempt to an MS <strong>SQL</strong> <strong>Server</strong> database 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 correctly<br />
when using the <strong>Data</strong><strong>Server</strong> and a broker. For environment-variable in<strong>for</strong>mation, see<br />
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, system, or<br />
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 runs on<br />
16-bit machines only. This prevents <strong>OpenEdge</strong> from accessing the data source, though you<br />
might still be able to access the data source through your ODBC driver using another<br />
product, such as Query Analyzer.<br />
• The data source has not been started or is not running correctly. Use the data source<br />
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 is invalid<br />
<strong>for</strong> the data source.<br />
• You specified an incorrect ODBC data source name when you created the 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. In some<br />
instances, such as <strong>for</strong> joins and catalog queries, the <strong>Data</strong><strong>Server</strong> automatically starts separate<br />
connections. However, there are circumstances in which a <strong>Data</strong><strong>Server</strong> application might require<br />
more than one connection. For example, the <strong>Data</strong><strong>Server</strong> cannot send a query to a data source<br />
while a stored procedure is still open unless you specify that the <strong>Data</strong><strong>Server</strong> uses separate<br />
connections <strong>for</strong> each request. Depending on the capabilities of the ODBC driver being used, the<br />
following cases may be candidates <strong>for</strong> using additional connections to accommodate additional<br />
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 />
6–29
Change language