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.

Troubleshooting<br />

8–8<br />

For example, the following connection string sets the user ID and password <strong>for</strong> the server<br />

and user ID and password <strong>for</strong> the data source:<br />

DSN=sports;UID=engine-login-name;PWD=engine-login-pass;UIDDBMS=dblogin;<br />

PWDDBMS=dblogin-pass<br />

For more in<strong>for</strong>mation and syntax examples, see the “Special connection issues” section on<br />

page 6–14.<br />

Key-buffer size—the PRGRS_IDBUF option<br />

The PRGRS_IDBUF option sets the size of the keys buffer. Generally, a default of 25 keys is<br />

sufficient. If the ODBC driver being used to access the MS <strong>SQL</strong> <strong>Server</strong> database has preserved<br />

cursors enabled across a transaction boundary, the keys buffer is used with all non-lookahead<br />

cursors. If the driver does have preserved cursors enabled, the PROGRS_IDBUF value and the keys<br />

buffer are unused.<br />

Locking error messages—the PRGRS_LOCK_ERRORS option<br />

<strong>Data</strong><strong>Server</strong> <strong>for</strong> MS <strong>SQL</strong> <strong>Server</strong> identifies and handles conditions and errors. However, the<br />

PRGRS_LOCK_ERROR option lets you control how your application reacts if it encounters an error<br />

that is actually a lock problem when accessing a data source. Use this option to pass the native<br />

error number to the <strong>Data</strong><strong>Server</strong> so that it handles this error as it would an <strong>OpenEdge</strong> database<br />

lock problem; that is, the <strong>Data</strong><strong>Server</strong> waits and retries, rather than halting the application:<br />

CONNECT data-source-name -ld logical-name -dt mss<br />

-Dsrv PRGRS_LOCK_ERRORS,error-number1,error-number2.<br />

Large rows—the PRGRS_MINBUF option<br />

Some data rows can be very large; <strong>for</strong> example, in a MS <strong>SQL</strong> <strong>Server</strong> database, rows often have<br />

large fields such as IMAGE and MEMO. The ODBC protocol specifies a dynamic buffer allocation<br />

process <strong>for</strong> handling large rows that do not initially fit into clients’ buffers; however, some<br />

drivers do not yet follow the correct ODBC protocol and do not handle these large rows<br />

correctly. Use the -Dsrv PRGRS_MINBUF,size option to <strong>for</strong>ce a minimum buffer size. For<br />

example, -Dsrv PRGRS_MINBUF,15000 enables the <strong>Data</strong><strong>Server</strong> to handle 15K rows even with<br />

drivers that fail to follow the ODBC protocol.<br />

The optimal setting <strong>for</strong> PRGRS_MINBUF is the size of the largest record data size plus 500 bytes.<br />

This can prevent run-time record expansion during the retrieval of query results.<br />

Notes: Do not use this option when the -Dsrv BINDING switch is set to 3. With the binding set<br />

to 3, the size of the data is known, and this switch will cause the allocation of unneeded<br />

additional memory.<br />

It is often difficult to determine when there is a buffer size problem and how to choose<br />

the correct value <strong>for</strong> PRGRS_MINBUF. Be careful when using this option.

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

Saved successfully!

Ooh no, something went wrong!