OpenEdge Data Management: DataServer for Microsoft SQL Server

More documents

Recommendations

Info

Chapter 2: Initial Programming Considerations Impact of MAX-ROWS The MAX-ROWS qualifier on a query determines the number of rows returned. The MAX-ROWS calculation is applied before any sorting is applied to the query, causing the results to be random. Consider the following example: DEFINE QUERY x FOR customer SCROLLING. OPEN QUERY x FOR EACH customer MAX-R0WS 15. GET LAST x. DISPLAY customer.custnum. REPEAT: GET PREV x. DISPLAY customer.custnum. END. When this example is run with the OpenEdge sports database, the first record return has custnum 54, and the repeat loop displays other custnums in descending order from there. When this example is run with the sports database migrated to MS SQL Server, the first record returned has custnum 15, and the repeat loop displays values in descending order from there. This difference in results is a caused by the MAX-ROWS being applied prior to the sorting. Block cursors Block cursors are available as a performance enhancement. They allow blocks of records to be bound and fetched together from a single database request, thus reducing the network overhead and minimizing record copies for ABL queries and finds, and minimizing record copies. Considering block cursors and firehose cursors Block cursors are the default behavior replacing look-ahead cursors for NO-LOCK queries that are processed on the server side. A NO-LOCK query is one that executes with the NO-LOCK lock condition attached to its ABL statement. Block cursors are the preferred choice to process NO-LOCK queries on the server side. However, server-side cursor processing is not the primary choice overall. Firehose cursors, providing optimum performance for NO-LOCK queries, surpasses the benefits of block cursors because they are client-based. For an in depth presentation of firehose cursors, see the “Firehose and Fast Forward-Only Cursors” section on page 164. Additional details about block cursor behavior DataServer connections that run at the read uncommitted isolation level will also execute queries that specify the SHARE-LOCK condition as NO-LOCK queries and will also utilize block cursors for their result sets. You can shut off block cursor behavior and revert back to look-ahead cursors for NO-LOCK queries by setting the -Dsrv PRGRS_BLOCK_CURS,0. If you leave block cursors on but wish to turn off the block and/or look-ahead cursor optimizations for a specific query, you can set the QUERY-TUNING option QUERY-TUNING(NO-LOOKAHEAD) on your ABL statement. While block cursors increase efficiency, they might also require more memory than look-ahead cursors. Block cursors will try to reuse memory from previous result sets whenever possible. You can adjust the memory available to block cursors according to 106 OpenEdge Data Management: DataServer for Microsoft SQL Server
Cursors your specifications. Adjust the cache size of an individual block with the same connection-level parameter you used to set the look-ahead cache size. The -Dsrv QT_CACHE_SIZE option allows you to specify at connect time how large the block cache should be for individual query results. When block cursors are active, the default QT_CACHE_SIZE is set to 10,000 bytes. When look-ahead cursors are active, this size defaults to 30,000 bytes. You can override the connection-level QT_CACHE_SIZE at the statement level by setting the QUERY-TUNING option called CACHE-SIZE on the query itself. Determining the proper block size should be based on the maximum length of your returned records multiplied by the expected number of resultant rows and then compared to your available memory. Whenever an existing block is not reused, the block of memory allocated for the query will be adjusted downward to an exact multiple of the number of rows that can fit into the allocated area. To prevent large applications from potentially overutilizing memory for block cursors, two other settings can be adjusted to limit the amount of memory available to block cursors. The first is the maximum block memory usage per table. If you have multiple queries open against the same table simultaneously, each query uses its own query block. The -Dsrv PRGRS_TABLE_BLOCKSIZE option puts an upper limit on the total memory available to query blocks of an individual table. This number should normally be set larger than the QT_CACHE_SIZE value. It can be set as high as two or three times the QT_CACHE_SIZE. If the maximum block memory available to the table will be exceeded by allocating space for the current NO-LOCK query in your ABL, the query is instead executed with a look-ahead cursor. The default maximum block memory area per table is set at 65,000 bytes. The second adjustment switch available is the -Dsrv PRGRS_MAX_BLOCKSIZE option. This value sets an upper limit to the overall memory provided to block cursors, irrespective of per table allocations. The default maximum is 1048576 bytes (or 1MB). Your accumulated total memory allocated for block cursors will not exceed this value. If allocating block cursor memory for a NO-LOCK query in your ABL will cause this limit to be exceeded, the query would instead be executed with a look-ahead cursor. The PRGRS_MAX_BLOCKSIZE value should be set with respect to the amount of memory available on your machine. If you are running in client-server mode, the number should be set with respect to both the available memory on the server machine as well as the number of clients that will be connecting. The following example uses the state table in the demo database, which has a maximum record size of 84 bytes: FOR EACH state NO-LOCK QUERY-TUNING(CACHE-SIZE 850): DISPLAY state. END. In this example, the QUERY-TUNING CACHE-SIZE value overrides the -Dsrv QT_CACHE_SIZE query block size default of 10,000 bytes. Ten records at 84 bytes per record totals 840 bytes in the query block. If a previously established block is located for that table that is greater than or equal to the requested size, it will be reused. However, if a new block is established instead, its memory allocation will be adjusted downward to 840 bytes in order to fit an exact multiple of rows in the block. Then, if the result set contains 30 records, the query block will get refilled three times before the end of the result set if read sequentially. OpenEdge Data Management: DataServer for Microsoft SQL Server 107
Page 1 and 2:
® ® PROGRESS® OPENEDGE® OpenEdg
Page 3 and 4:
Contents Preface . . . . . . . . .
Page 5 and 6:
Contents Data output and retrieval
Page 7 and 8:
Contents Migrating an OpenEdge data
Page 9 and 10:
Tables Contents Table 1: DataServer
Page 11 and 12:
Examples Contents Example 1: Passin
Page 13 and 14:
Preface This Preface contains the f
Page 15 and 16:
Chapter 5, “Configuring the DataS
Page 17 and 18:
Before you begin Preface Before att
Page 19 and 20:
In this example, STREAM stream, UNL
Page 21 and 22:
After displaying a message, OpenEdg
Page 23 and 24:
Preface Software Foundation (http:/
Page 25 and 26:
Preface use, copy, modify, and dist
Page 27 and 28:
Preface DISCLAIMS ALL WARRANTIES WI
Page 29 and 30:
Preface INCLUDING ALL IMPLIED WARRA
Page 31 and 32:
Preface WARRANTIES OF MERCHANTABILI
Page 33 and 34:
Preface conditions for packages lik
Page 35 and 36:
Introduction OpenEdge Data Manageme
Page 37 and 38:
DataServer components DataServer co
Page 39 and 40:
DataServer for MS SQL Server logic
Page 41 and 42:
Figure 3 illustrates the schema-loa
Page 43 and 44:
DataServer utilities DataServer uti
Page 45 and 46:
DataServer configurations DataServe
Page 47 and 48:
The remote DataServer configuration
Page 49 and 50:
DataServer configurations Configuri
Page 51 and 52:
Software requirements Software requ
Page 53 and 54:
Guidelines for using the DataServer
Page 55 and 56: Initial Programming Considerations
Page 57 and 58: Database design issues Database des
Page 59 and 60: MS SQL Server DataServer data sourc
Page 61 and 62: Client code page Database design is
Page 63 and 64: Support for Unicode Database design
Page 65 and 66: Indexes and sorting Database design
Page 67 and 68: Database design issues source’s c
Page 69 and 70: Triggers Database design issues Tri
Page 71 and 72: Data types Data types MS SQL Server
Page 73 and 74: Table 9: MS SQL Server data type eq
Page 75 and 76: Processing activities that require
Page 77 and 78: Table 11: MS SQL Server 2008 dateti
Page 79 and 80: Performing data type conversions Da
Page 81 and 82: Enabling Datetime data types using
Page 83 and 84: 2008, or if you use a native driver
Page 85 and 86: Default and Special Datetime Defaul
Page 87 and 88: ABL-to-MS SQL Server data type mapp
Page 89 and 90: Unknown value (?) Data types The Da
Page 91 and 92: Record creation Suppose that you ha
Page 93 and 94: Data source record locking Data sou
Page 95 and 96: Handling lock timeouts Data source
Page 97 and 98: Locking impact on queries Data sour
Page 99 and 100: Data source record locking When thi
Page 101 and 102: To avoid this type of problem, the
Page 103 and 104: Error handling If you use NO-ERROR
Page 105: Cursors Cursors A cursor is like a
Page 109 and 110: • Block cursors are directly link
Page 111 and 112: FIND customer WHERE ROWID(customer)
Page 113 and 114: For example, the following statemen
Page 115 and 116: find.p /* This code accesses an Ope
Page 117 and 118: ABL issues Table 19 summarizes ABL
Page 119 and 120: RDBMS Stored Procedure Details Open
Page 121 and 122: RDBMS stored procedure basics RDBMS
Page 123 and 124: RDBMS stored procedure basics When
Page 125 and 126: Run Stored-Procedure details •
Page 127 and 128: Run Stored-Procedure details An exp
Page 129 and 130: Run Stored-Proc statement execution
Page 131 and 132: Run Stored-Procedure details Also n
Page 133 and 134: Loading results into a temp-table T
Page 135 and 136: Retrieving return codes Interfacing
Page 137 and 138: Interfacing with RDBMS stored proce
Page 141 and 142: Loading result sets into temp-table
Page 143 and 144: Employing additional enhancements I
Page 151 and 152: Handling errors Handling errors The
Page 153 and 154: ROWID Support This section presents
Page 155 and 156: ROWID Support The RUN STORED-PROC c
Page 157 and 158:
ROWID Support If the table uses com
Page 159 and 160:
Additional Features to Enhance Data
Page 161 and 162:
Connection pooling Connection pooli
Page 163 and 164:
DataServer connection management Co
Page 165 and 166:
Firehose exclusions Connection pool
Page 167 and 168:
Cursor downgrades Connection poolin
Page 169 and 170:
Query tuning Query tuning How you s
Page 171 and 172:
LOOKAHEAD NO-LOOKAHEAD SEPARATE-CON
Page 173 and 174:
Query tuning Table 24: Query-tuning
Page 175 and 176:
Join by SQLDB Join by SQLDB For que
Page 177 and 178:
Table 25 describes how these contro
Page 179 and 180:
Modifying the run-time schema check
Page 181 and 182:
Configuring the DataServer Configur
Page 183 and 184:
DataServer components Table 26: Ins
Page 185 and 186:
Configuring a local DataServer Conf
Page 187 and 188:
Configuring a remote DataServer 4.
Page 189 and 190:
5162 Configuring a remote DataServe
Page 191 and 192:
The ubroker.properties file Configu
Page 193 and 194:
Configuring a remote DataServer Tab
Page 195 and 196:
Configuring a remote DataServer The
Page 197 and 198:
Creating a schema holder Creating a
Page 199 and 200:
Creating a schema holder configurat
Page 201 and 202:
Creating a schema holder 3. In the
Page 203 and 204:
Creating a schema holder 10. Choose
Page 205 and 206:
Typical configuration for a remote
Page 207 and 208:
Typical configuration for a remote
Page 209 and 210:
Connecting the DataServer You can s
Page 211 and 212:
Starting a remote DataServer Starti
Page 213 and 214:
Starting a remote DataServer If you
Page 215 and 216:
Starting a remote DataServer Starti
Page 217 and 218:
Connection guidelines Connection gu
Page 219 and 220:
Connecting a schema holder at start
Page 221 and 222:
Single-User Mode (-1) Read-Only (-R
Page 223 and 224:
Using a remote DataServer configura
Page 225 and 226:
Value pairs within the connect stri
Page 227 and 228:
Connecting a schema holder Table 31
Page 229 and 230:
qt_separate_connection qt_no_separa
Page 231 and 232:
Connecting a schema holder Table 33
Page 233 and 234:
Connecting a schema holder 1. Each
Page 235 and 236:
Table 38 lists the DataServer log e
Page 237 and 238:
Logging levels You can choose one o
Page 239 and 240:
Enabling ABL to SQL Correlation in
Page 241 and 242:
Connecting a schema holder Example
Page 243 and 244:
Connection failures and OpenEdge re
Page 245 and 246:
Connection failures and OpenEdge re
Page 247 and 248:
Using the $UNIQUE_DSLOG environment
Page 249 and 250:
The DataServer Tutorial OpenEdge Da
Page 251 and 252:
Demonstration databases for DataSer
Page 253 and 254:
Preparing to create demonstration d
Page 255 and 256:
Page 257 and 258:
Page 259 and 260:
DataServer utilities When you acces
Page 261 and 262:
Prime to ROWID identification ROWID
Page 263 and 264:
Prime to ROWID identification inacc
Page 265 and 266:
Creating a schema holder • Choose
Page 267 and 268:
Creating a schema holder You can se
Page 269 and 270:
Updating a schema holder Updating a
Page 271 and 272:
Verifying a schema holder Verifying
Page 273 and 274:
Verifying a schema holder 2. Type p
Page 275 and 276:
Changing connection information in
Page 277 and 278:
Deleting a schema holder Deleting a
Page 279 and 280:
Managing server attributes See the
Page 281 and 282:
Managing server attributes Defining
Page 283 and 284:
Managing server attributes If the p
Page 285 and 286:
Managing server attributes 6. The P
Page 287 and 288:
Defining a default constraint defin
Page 289 and 290:
Managing server attributes 5. Click
Page 291 and 292:
Managing server attributes • Resu
Page 293 and 294:
Migrating an OpenEdge database to M
Page 295 and 296:
Page 297 and 298:
Page 299 and 300:
Page 301 and 302:
Page 303 and 304:
Delta df to MS SQL Server Increment
Page 305 and 306:
Page 307 and 308:
Page 309 and 310:
Modifying field-level information Y
Page 311 and 312:
Defining the ROWID Modifying a sche
Page 313 and 314:
Adding extended ABL support Adding
Page 315 and 316:
Adding extended ABL support 4. Chan
Page 317 and 318:
Adding extended ABL support 3. Drop
Page 319 and 320:
Troubleshooting This chapter descri
Page 321 and 322:
ODBC options ODBC options The DataS
Page 323 and 324:
ODBC options Table 56: DataServer o
Page 325 and 326:
Using MS SQL Server and DataServer
Page 327 and 328:
Large rows—the PRGRS_MINBUF optio
Page 329 and 330:
ODBC options Wait time for asynchro
Page 331 and 332:
Using the block cursor switches ODB
Page 333 and 334:
Migration Issues This appendix disc
Page 335 and 336:
Modifying your application Note the
Page 337 and 338:
Sample code for the db.owner.Custom
Page 339 and 340:
Server Related Command Line Utiliti
Page 341 and 342:
OpenEdge Management or OpenEdge Exp
Page 343 and 344:
Page 345 and 346:
Page 347 and 348:
Page 349 and 350:
Syntax Parameters service-name PROB
Page 351 and 352:
Other command line utilities for th
Page 353 and 354:
Data Type Details C This appendix s
Page 355 and 356:
nvarchar 8 SQL_NVARCHAR CHARACTER t
Page 357 and 358:
Using qt_debug to Analyze Performan
Page 359 and 360:
Using qt_debug to analyze performan
Page 361 and 362:
Index Numbers 4GLTrans log entry ty
Page 363 and 364:
display format 309 overflow checkin
Page 365 and 366:
INPUT-OUTPUT option retrieving para
Page 367 and 368:
DataServer (-Dsrv) startup paramete
Page 369 and 370:
221, 242, 359 Schema defined 40 loa
show all

OpenEdge Data Management: DataServer for Microsoft SQL Server

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?