Fetching resultset is slow
I am using following JDBC driver.
Manifest-Version: 1.0
Specification-Title: Oracle JDBC driver classes for use with JDK14
Created-By: 1.4.2_08 (Sun Microsystems Inc.)
Implementation-Title: ojdbc14_g.jar
Specification-Vendor: Oracle Corporation
Specification-Version: Oracle JDBC Driver version - "10.2.0.1.0"
Implementation-Version: Oracle JDBC Driver version - "10.2.0.1.0"
Implementation-Vendor: Oracle Corporation
Implementation-Time: Wed Jun 22 19:13:16 2005
I am using Weblogic 8.1 application server.
When I set rowprefetch value to 500 then also it fetches not more then 20 rows. Please help to set this value.
Thanks in Advance.
Manoj.
My JDBC code is in my application driven by JSF frame work.
I can get all log information of row fetching from connection.
Code is:
pStmt = (OraclePreparedStatement) conn.prepareStatement(sSql);
logger.info("pStmt.getFetchSize(): " + pStmt.getFetchSize());
logger.info("pStmt.setRowPrefetch(): " + pStmt.getRowPrefetch());
pStmt.setRowPrefetch(500);
while (rs.next()) {
count++;
logger.info("count: " + count);
Output is:
2006-06-28 16:13:30,0437, sSql: SELECT /*+ FIRST_ROWS(1) */ wo.workorder_id workorder_id, wo.invoice_id invoice_id, wo.contractor_id contractor_id, wo.tech tech, wo.corp corp, wo.status_code status_code, TO_CHAR (wo.workorder_date, 'MM/DD/YYYY') workorder_date, wo.house house, wo.cust cust, wo.parent_workorder_id parent_workorder_id, TO_CHAR (wo.created, 'MM/DD/YYYY') created, wo.created_by, TO_CHAR (wo.updated, 'MM/DD/YYYY') updated, wo.updated_by updated_by, wo.comments comments, wo.process_type process_type, wo.cnt_submit_count cnt_submit_count, wo.wo_exception_type wo_exception_type, TO_CHAR (wo.fin_date, 'MM/DD/YYYY') fin_date, wo.alert_flag alert_flag, wo.zip,TO_CHAR (wo.approved_date, 'MM/DD/YYYY') approved_date, wo.approved_by, wo.WEEKENDING_ID WEEKENDING_ID, wo.REQUEST_WEEKENDING_ID REQUEST_WEEKENDING_ID , wo.corp || '-' || wo.house || '-' || wo.cust account, li.lineitem_id lineItemId, li.reason_code reasonCode, nvl(reason.value, '') reasonValue, li.price price, li.adj_price adjPrice, li.qty, li.price * li.qty extend, li.job_cat_id jobCatId, jt.name jobTypeName, cat.name category, r.name regionName, t.name tierName, a.entity entity, a.dept dept, a.account account, a.event event, a.performance performance, a.program program, a.interco interco, a.paygroup paygroup from invoice i, workorder wo, lineitem li, job_category jc, jobtype jt, category cat, region r, tier t, region_tier rt, weekending we, reason reason, area a where i.invoice_id = wo.invoice_id and wo.workorder_id = li.workorder_id and li.job_cat_id = jc.job_cat_id and jc.category_id = cat.category_id and jc.jobtype_id = jt.jobtype_id and wo.zip = rt.zip and wo.corp = rt.corp and rt.region_id = r.region_id and rt.tier_id = t.tier_id and wo.weekending_id = we.weekending_id and li.reason_code = reason.reason_code(+) and wo.corp = a.corp AND wo.zip = a.zip and wo.invoice_id = :invoiceId and rt.region_Id in ( 1,2,3,4,5,6 )
2006-06-28 16:13:30,0437, pStmt.getFetchSize(): 10
2006-06-28 16:13:30,0437, pStmt.setRowPrefetch(): 10
2006-06-28 16:13:30,0437, before executeQuery
2006-06-28 16:13:30,0671, rs.getFetchSize: 500
2006-06-28 16:13:30,0671, after executeQuery
2006-06-28 16:13:30,0671, count: 1
2006-06-28 16:13:30,0671, count: 2
2006-06-28 16:13:30,0671, count: 3
2006-06-28 16:13:30,0671, count: 4
2006-06-28 16:13:30,0671, count: 5
2006-06-28 16:13:30,0671, count: 6
2006-06-28 16:13:30,0671, count: 7
2006-06-28 16:13:30,0671, count: 8
2006-06-28 16:13:30,0671, count: 9
2006-06-28 16:13:30,0671, count: 10
2006-06-28 16:13:30,0671, count: 11
2006-06-28 16:13:30,0671, count: 12
2006-06-28 16:13:30,0671, count: 13
2006-06-28 16:13:30,0671, count: 14
2006-06-28 16:13:30,0671, count: 15
2006-06-28 16:13:30,0687, count: 16
2006-06-28 16:13:30,0687, count: 17
2006-06-28 16:13:30,0687, count: 18
2006-06-28 16:13:30,0687, count: 19
2006-06-28 16:13:30,0687, count: 20
2006-06-28 16:13:30,0687, count: 21
2006-06-28 16:13:30,0687, count: 22
2006-06-28 16:13:30,0687, count: 23
2006-06-28 16:13:30,0687, count: 24
2006-06-28 16:13:30,0687, count: 25
2006-06-28 16:13:30,0687, count: 26
2006-06-28 16:13:30,0687, count: 27
2006-06-28 16:13:30,0687, count: 28
2006-06-28 16:13:30,0687, count: 29
2006-06-28 16:13:30,0687, count: 30
2006-06-28 16:13:30,0687, count: 31
2006-06-28 16:13:30,0687, count: 32
2006-06-28 16:13:30,0687, count: 33
2006-06-28 16:13:30,0687, count: 34
2006-06-28 16:13:30,0687, count: 35
2006-06-28 16:13:30,0687, count: 36
2006-06-28 16:13:30,0687, count: 37
2006-06-28 16:13:30,0687, count: 38
2006-06-28 16:13:30,0687, count: 39
2006-06-28 16:13:30,0687, count: 40
2006-06-28 16:13:30,0687, count: 41
2006-06-28 16:13:30,0703, count: 42
2006-06-28 16:13:30,0703, count: 43
2006-06-28 16:13:30,0703, count: 44
2006-06-28 16:13:30,0703, count: 45
2006-06-28 16:13:30,0703, count: 46
2006-06-28 16:13:30,0703, count: 47
2006-06-28 16:13:30,0703, count: 48
2006-06-28 16:13:30,0703, count: 49
2006-06-28 16:13:30,0703, count: 50
2006-06-28 16:13:30,0703, count: 51
2006-06-28 16:13:30,0703, count: 52
2006-06-28 16:13:30,0703, count: 53
2006-06-28 16:13:30,0703, count: 54
2006-06-28 16:13:30,0703, count: 55
2006-06-28 16:13:30,0703, count: 56
2006-06-28 16:13:30,0703, count: 57
2006-06-28 16:13:30,0703, count: 58
2006-06-28 16:13:30,0703, count: 59
2006-06-28 16:13:30,0703, count: 60
2006-06-28 16:13:30,0703, count: 61
2006-06-28 16:13:30,0703, count: 62
2006-06-28 16:13:30,0703, count: 63
2006-06-28 16:13:30,0703, count: 64
2006-06-28 16:13:30,0703, count: 65
2006-06-28 16:13:30,0703, count: 66
2006-06-28 16:13:30,0703, count: 67
2006-06-28 16:13:30,0703, count: 68
2006-06-28 16:13:30,0718, count: 69
2006-06-28 16:13:30,0718, count: 70
2006-06-28 16:13:30,0718, count: 71
2006-06-28 16:13:30,0718, count: 72
2006-06-28 16:13:30,0718, count: 73
2006-06-28 16:13:30,0718, count: 74
2006-06-28 16:13:30,0718, count: 75
2006-06-28 16:13:30,0718, count: 76
2006-06-28 16:13:30,0718, count: 77
2006-06-28 16:13:30,0718, count: 78
2006-06-28 16:13:30,0718, count: 79
2006-06-28 16:13:30,0718, count: 80
2006-06-28 16:13:30,0718, count: 81
2006-06-28 16:13:30,0718, count: 82
2006-06-28 16:13:30,0718, count: 83
2006-06-28 16:13:30,0718, count: 84
2006-06-28 16:13:30,0718, count: 85
2006-06-28 16:13:30,0718, count: 86
2006-06-28 16:13:30,0718, count: 87
2006-06-28 16:13:30,0718, count: 88
2006-06-28 16:13:30,0718, count: 89
2006-06-28 16:13:30,0718, count: 90
2006-06-28 16:13:30,0718, count: 91
2006-06-28 16:13:30,0718, count: 92
2006-06-28 16:13:30,0734, count: 93
2006-06-28 16:13:30,0734, count: 94
2006-06-28 16:13:30,0734, count: 95
2006-06-28 16:13:30,0734, count: 96
2006-06-28 16:13:30,0734, count: 97
2006-06-28 16:13:30,0734, count: 98
2006-06-28 16:13:30,0734, count: 99
2006-06-28 16:13:30,0734, count: 100
2006-06-28 16:13:30,0734, count: 101
2006-06-28 16:13:30,0734, count: 102
2006-06-28 16:13:30,0734, count: 103
2006-06-28 16:13:30,0734, count: 104
2006-06-28 16:13:30,0734, count: 105
2006-06-28 16:13:30,0750, count: 106
2006-06-28 16:13:30,0750, count: 107
2006-06-28 16:13:30,0750, count: 108
2006-06-28 16:13:30,0750, count: 109
2006-06-28 16:13:30,0750, count: 110
2006-06-28 16:13:30,0750, count: 111
2006-06-28 16:13:30,0750, count: 112
2006-06-28 16:13:30,0750, count: 113
2006-06-28 16:13:30,0750, count: 114
2006-06-28 16:13:30,0750, count: 115
2006-06-28 16:13:30,0750, count: 116
2006-06-28 16:13:30,0750, count: 117
2006-06-28 16:13:30,0750, count: 118
2006-06-28 16:13:30,0750, count: 119
2006-06-28 16:13:30,0765, count: 120
2006-06-28 16:13:30,0765, count: 121
2006-06-28 16:13:30,0765, count: 122
2006-06-28 16:13:30,0765, count: 123
2006-06-28 16:13:30,0765, count: 124
2006-06-28 16:13:30,0765, count: 125
2006-06-28 16:13:30,0765, count: 126
2006-06-28 16:13:30,0765, count: 127
2006-06-28 16:13:30,0765, count: 128
2006-06-28 16:13:30,0765, count: 129
2006-06-28 16:13:30,0765, count: 130
2006-06-28 16:13:30,0765, count: 131
2006-06-28 16:13:30,0765, count: 132
2006-06-28 16:13:30,0765, count: 133
2006-06-28 16:13:30,0765, count: 134
2006-06-28 16:13:30,0765, count: 135
2006-06-28 16:13:30,0765, count: 136
2006-06-28 16:13:30,0765, count: 137
2006-06-28 16:13:30,0765, count: 138
2006-06-28 16:13:30,0765, count: 139
2006-06-28 16:13:30,0765, count: 140
2006-06-28 16:13:30,0765, count: 141
2006-06-28 16:13:30,0781, count: 142
2006-06-28 16:13:30,0781, count: 143
2006-06-28 16:13:30,0781, count: 144
2006-06-28 16:13:30,0781, count: 145
2006-06-28 16:13:30,0781, count: 146
2006-06-28 16:13:30,0781, count: 147
2006-06-28 16:13:30,0781, count: 148
2006-06-28 16:13:30,0781, count: 149
2006-06-28 16:13:30,0781, count: 150
2006-06-28 16:13:30,0796, count: 151
2006-06-28 16:13:30,0796, count: 152
2006-06-28 16:13:30,0796, count: 153
2006-06-28 16:13:30,0796, count: 154
2006-06-28 16:13:30,0796, count: 155
2006-06-28 16:13:30,0796, count: 156
2006-06-28 16:13:30,0796, count: 157
2006-06-28 16:13:30,0796, count: 158
2006-06-28 16:13:30,0796, count: 159
2006-06-28 16:13:30,0796, count: 160
2006-06-28 16:13:30,0796, count: 161
2006-06-28 16:13:30,0796, count: 162
2006-06-28 16:13:30,0796, count: 163
2006-06-28 16:13:30,0796, count: 164
2006-06-28 16:13:30,0796, count: 165
2006-06-28 16:13:30,0796, count: 166
2006-06-28 16:13:30,0796, count: 167
2006-06-28 16:13:30,0812, count: 168
2006-06-28 16:13:30,0812, count: 169
2006-06-28 16:13:30,0812, count: 170
2006-06-28 16:13:30,0812, count: 171
2006-06-28 16:13:30,0812, count: 172
2006-06-28 16:13:30,0812, count: 173
2006-06-28 16:13:30,0812, count: 174
2006-06-28 16:13:30,0812, count: 175
2006-06-28 16:13:30,0812, count: 176
2006-06-28 16:13:30,0812, count: 177
2006-06-28 16:13:30,0812, count: 178
2006-06-28 16:13:30,0812, count: 179
2006-06-28 16:13:30,0812, count: 180
2006-06-28 16:13:30,0812, count: 181
2006-06-28 16:13:30,0812, count: 182
2006-06-28 16:13:30,0812, count: 183
2006-06-28 16:13:30,0812, count: 184
2006-06-28 16:13:30,0812, count: 185
2006-06-28 16:13:30,0812, count: 186
2006-06-28 16:13:30,0812, count: 187
2006-06-28 16:13:30,0812, count: 188
2006-06-28 16:13:30,0812, count: 189
2006-06-28 16:13:30,0812, count: 190
2006-06-28 16:13:30,0812, count: 191
2006-06-28 16:13:30,0812, count: 192
2006-06-28 16:13:30,0812, count: 193
2006-06-28 16:13:30,0828, count: 194
2006-06-28 16:13:30,0828, count: 195
2006-06-28 16:13:30,0828, count: 196
2006-06-28 16:13:30,0828, count: 197
2006-06-28 16:13:30,0828, count: 198
2006-06-28 16:13:30,0828, count: 199
2006-06-28 16:13:30,0828, count: 200
2006-06-28 16:13:30,0828, count: 201
2006-06-28 16:13:30,0828, count: 202
2006-06-28 16:13:30,0828, count: 203
2006-06-28 16:13:30,0828, count: 204
2006-06-28 16:13:30,0828, count: 205
2006-06-28 16:13:30,0828, count: 206
2006-06-28 16:13:30,0828, count: 207
2006-06-28 16:13:30,0828, count: 208
2006-06-28 16:13:30,0828, count: 209
2006-06-28 16:13:30,0828, count: 210
2006-06-28 16:13:30,0828, count: 211
2006-06-28 16:13:30,0828, count: 212
2006-06-28 16:13:30,0828, count: 213
2006-06-28 16:13:30,0828, count: 214
2006-06-28 16:13:30,0828, count: 215
2006-06-28 16:13:30,0828, count: 216
2006-06-28 16:13:30,0828, count: 217
2006-06-28 16:13:30,0828, count: 218
2006-06-28 16:13:30,0828, count: 219
2006-06-28 16:13:30,0828, count: 220
2006-06-28 16:13:30,0843, count: 221
2006-06-28 16:13:30,0843, count: 222
2006-06-28 16:13:30,0843, count: 223
2006-06-28 16:13:30,0843, count: 224
2006-06-28 16:13:30,0843, count: 225
2006-06-28 16:13:30,0843, count: 226
2006-06-28 16:13:30,0843, count: 227
2006-06-28 16:13:30,0843, count: 228
2006-06-28 16:13:30,0843, count: 229
2006-06-28 16:13:30,0843, count: 230
2006-06-28 16:13:30,0843, count: 231
2006-06-28 16:13:30,0843, count: 232
2006-06-28 16:13:30,0843, count: 233
2006-06-28 16:13:30,0843, count: 234
2006-06-28 16:13:30,0843, count: 235
2006-06-28 16:13:30,0843, count: 236
2006-06-28 16:13:30,0843, count: 237
2006-06-28 16:13:30,0859, count: 238
2006-06-28 16:13:30,0859, count: 239
2006-06-28 16:13:30,0859, count: 240
2006-06-28 16:13:30,0859, count: 241
2006-06-28 16:13:30,0859, count: 242
2006-06-28 16:13:30,0859, count: 243
2006-06-28 16:13:30,0859, count: 244
2006-06-28 16:13:30,0859, count: 245
2006-06-28 16:13:30,0859, count: 246
2006-06-28 16:13:30,0859, count: 247
2006-06-28 16:13:30,0859, count: 248
2006-06-28 16:13:30,0859, count: 249
2006-06-28 16:13:30,0859, count: 250
2006-06-28 16:13:30,0859, count: 251
2006-06-28 16:13:30,0859, count: 252
2006-06-28 16:13:30,0859, count: 253
2006-06-28 16:13:30,0859, count: 254
2006-06-28 16:13:30,0859, count: 255
2006-06-28 16:13:30,0859, count: 256
2006-06-28 16:13:30,0875, count: 257
2006-06-28 16:13:30,0875, count: 258
2006-06-28 16:13:30,0875, count: 259
2006-06-28 16:13:30,0875, count: 260
2006-06-28 16:13:30,0875, count: 261
2006-06-28 16:13:30,0875, count: 262
2006-06-28 16:13:30,0875, count: 263
2006-06-28 16:13:30,0875, count: 264
2006-06-28 16:13:30,0875, count: 265
2006-06-28 16:13:30,0875, count: 266
2006-06-28 16:13:30,0875, count: 267
2006-06-28 16:13:30,0875, count: 268
2006-06-28 16:13:30,0875, count: 269
2006-06-28 16:13:30,0875, count: 270
2006-06-28 16:13:30,0875, count: 271
2006-06-28 16:13:30,0875, count: 272
2006-06-28 16:13:30,0875, count: 273
2006-06-28 16:13:30,0875, count: 274
2006-06-28 16:13:30,0875, count: 275
2006-06-28 16:13:30,0875, count: 276
2006-06-28 16:13:30,0875, count: 277
2006-06-28 16:13:30,0890, count: 278
2006-06-28 16:13:30,0890, count: 279
2006-06-28 16:13:30,0890, count: 280
2006-06-28 16:13:30,0890, count: 281
2006-06-28 16:13:30,0890, count: 282
2006-06-28 16:13:30,0890, count: 283
2006-06-28 16:13:30,0890, count: 284
2006-06-28 16:13:30,0890, count: 285
2006-06-28 16:13:30,0890, count: 286
2006-06-28 16:13:30,0890, count: 287
2006-06-28 16:13:30,0890, count: 288
2006-06-28 16:13:30,0890, count: 289
2006-06-28 16:13:30,0890, count: 290
2006-06-28 16:13:30,0890, count: 291
2006-06-28 16:13:30,0890, count: 292
2006-06-28 16:13:30,0890, count: 293
2006-06-28 16:13:30,0890, count: 294
2006-06-28 16:13:30,0890, count: 295
2006-06-28 16:13:30,0890, count: 296
2006-06-28 16:13:30,0890, count: 297
2006-06-28 16:13:30,0890, count: 298
2006-06-28 16:13:30,0906, count: 299
2006-06-28 16:13:30,0906, count: 300
2006-06-28 16:13:30,0906, count: 301
2006-06-28 16:13:30,0906, count: 302
2006-06-28 16:13:30,0906, count: 303
2006-06-28 16:13:30,0906, count: 304
2006-06-28 16:13:30,0906, count: 305
2006-06-28 16:13:30,0906, count: 306
2006-06-28 16:13:30,0906, count: 307
2006-06-28 16:13:30,0906, count: 308
2006-06-28 16:13:30,0906, count: 309
2006-06-28 16:13:30,0906, count: 310
2006-06-28 16:13:30,0906, count: 311
2006-06-28 16:13:30,0906, count: 312
2006-06-28 16:13:30,0906, count: 313
2006-06-28 16:13:30,0906, count: 314
2006-06-28 16:13:30,0906, count: 315
2006-06-28 16:13:30,0906, count: 316
2006-06-28 16:13:30,0906, count: 317
2006-06-28 16:13:30,0906, count: 318
2006-06-28 16:13:30,0921, count: 319
2006-06-28 16:13:30,0921, count: 320
2006-06-28 16:13:30,0921, count: 321
2006-06-28 16:13:30,0921, count: 322
2006-06-28 16:13:30,0921, count: 323
2006-06-28 16:13:30,0921, count: 324
2006-06-28 16:13:30,0921, count: 325
2006-06-28 16:13:30,0921, count: 326
2006-06-28 16:13:30,0921, count: 327
2006-06-28 16:13:30,0921, count: 328
2006-06-28 16:13:30,0921, count: 329
2006-06-28 16:13:30,0921, count: 330
2006-06-28 16:13:30,0921, count: 331
2006-06-28 16:13:30,0921, count: 332
2006-06-28 16:13:30,0921, count: 333
2006-06-28 16:13:30,0921, count: 334
2006-06-28 16:13:30,0921, count: 335
2006-06-28 16:13:30,0921, count: 336
2006-06-28 16:13:30,0921, count: 337
2006-06-28 16:13:30,0921, count: 338
2006-06-28 16:13:30,0921, count: 339
2006-06-28 16:13:30,0921, count: 340
2006-06-28 16:13:30,0937, count: 341
2006-06-28 16:13:30,0937, count: 342
2006-06-28 16:13:30,0937, count: 343
2006-06-28 16:13:30,0937, count: 344
2006-06-28 16:13:30,0937, count: 345
2006-06-28 16:13:30,0937, count: 346
2006-06-28 16:13:30,0937, count: 347
2006-06-28 16:13:30,0937, count: 348
2006-06-28 16:13:30,0937, count: 349
2006-06-28 16:13:30,0937, count: 350
2006-06-28 16:13:30,0937, count: 351
2006-06-28 16:13:30,0937, count: 352
2006-06-28 16:13:30,0937, count: 353
2006-06-28 16:13:30,0937, count: 354
2006-06-28 16:13:30,0937, count: 355
2006-06-28 16:13:30,0937, count: 356
2006-06-28 16:13:30,0937, count: 357
2006-06-28 16:13:30,0937, count: 358
2006-06-28 16:13:30,0937, count: 359
2006-06-28 16:13:30,0937, count: 360
2006-06-28 16:13:30,0937, count: 361
2006-06-28 16:13:30,0937, count: 362
2006-06-28 16:13:30,0953, count: 363
2006-06-28 16:13:30,0953, count: 364
2006-06-28 16:13:30,0953, count: 365
2006-06-28 16:13:30,0953, count: 366
2006-06-28 16:13:30,0953, count: 367
2006-06-28 16:13:30,0953, count: 368
2006-06-28 16:13:30,0953, count: 369
2006-06-28 16:13:30,0953, count: 370
2006-06-28 16:13:30,0953, count: 371
2006-06-28 16:13:30,0953, count: 372
2006-06-28 16:13:30,0953, count: 373
2006-06-28 16:13:30,0953, count: 374
2006-06-28 16:13:30,0953, count: 375
2006-06-28 16:13:30,0953, count: 376
2006-06-28 16:13:30,0953, count: 377
2006-06-28 16:13:30,0953, count: 378
2006-06-28 16:13:30,0953, count: 379
2006-06-28 16:13:30,0953, count: 380
2006-06-28 16:13:30,0953, count: 381
2006-06-28 16:13:30,0953, count: 382
2006-06-28 16:13:30,0968, count: 383
2006-06-28 16:13:30,0968, count: 384
2006-06-28 16:13:30,0968, count: 385
2006-06-28 16:13:30,0968, count: 386
2006-06-28 16:13:30,0968, count: 387
2006-06-28 16:13:30,0968, count: 388
2006-06-28 16:13:30,0968, count: 389
2006-06-28 16:13:30,0968, count: 390
2006-06-28 16:13:30,0968, count: 391
2006-06-28 16:13:30,0968, count: 392
2006-06-28 16:13:30,0968, count: 393
2006-06-28 16:13:30,0968, count: 394
2006-06-28 16:13:30,0968, count: 395
2006-06-28 16:13:30,0968, count: 396
2006-06-28 16:13:30,0968, count: 397
2006-06-28 16:13:30,0968, count: 398
2006-06-28 16:13:30,0968, count: 399
2006-06-28 16:13:30,0968, count: 400
2006-06-28 16:13:30,0984, count: 401
2006-06-28 16:13:30,0984, count: 402
2006-06-28 16:13:30,0984, count: 403
2006-06-28 16:13:30,0984, count: 404
2006-06-28 16:13:30,0984, count: 405
2006-06-28 16:13:30,0984, count: 406
2006-06-28 16:13:30,0984, count: 407
2006-06-28 16:13:30,0984, count: 408
2006-06-28 16:13:30,0984, count: 409
2006-06-28 16:13:30,0984, count: 410
2006-06-28 16:13:31,0000, count: 411
2006-06-28 16:13:31,0000, count: 412
2006-06-28 16:13:31,0000, count: 413
2006-06-28 16:13:31,0000, count: 414
2006-06-28 16:13:31,0000, count: 415
2006-06-28 16:13:31,0000, count: 416
2006-06-28 16:13:31,0000, count: 417
2006-06-28 16:13:31,0000, count: 418
2006-06-28 16:13:31,0000, count: 419
2006-06-28 16:13:31,0000, count: 420
2006-06-28 16:13:31,0000, count: 421
2006-06-28 16:13:31,0000, count: 422
2006-06-28 16:13:31,0000, count: 423
Similar Messages
-
Initializing Vector with ResultSet(TO SLOW!)
Hi
Im creating a JTable from two Vectors. I need to initialize
the one vector from a resultset. This is way to slow for large result sets. Heres my loop:
private Vector getData(int columns[]) throws Exception
rows = new Vector(queue.count);
while (res.next())
Vector newRow = new Vector(columns.length);
for (int i = 0; i < columns.length;i++)
newRow.addElement(res.getString(columns));
rows.addElement(newRow);
return rows;
Any Ideas to speed this up a bit.
Thanks!private Vector getData(int columns[]) throws
Exception
rows = new Vector(queue.count);
while (res.next())
Vector newRow = new Vector(columns.length);
for (int i = 0; i < columns.length;i++)
newRow.addElement(res.getString(columns));
rows.addElement(newRow);
return rows;
Any Ideas to speed this up a bit.
Thanks!
I tested your code using String[][] rows (instead of Vector rows) hoping using arrays will make it faster. But it did not. What really did improve the performance was declaring and alocating memory for String[][] rows before calling the function. That is to say, the most time is spent on rows = new String[ROWS][COLS]. If you your conditions allow you to use String[][] rows instead of Vector rows and allocate memory for String[][] rows before calling your method getData(), then, in my opinion, it will improve the performance.
Cheers! -
Initializing Vector with ResultSet(too Slow!)
Hi
I'm createing a JTable with two Vectors. Im am initializing the Vectors in a while loop, but it is way to slow with large ResultSets.
Does anyone know how I can speed this process up?
Thanks!Heres the full method Ive removed some of hte code in the for loop. But that makes no difference to the speed
private Vector getData(int columns[]) throws Exception
rows = new Vector(queue.count);
while (res.next())
Vector newRow = new Vector(columns.length);
for (int i = 0; i < columns.length; i++)
newRow.addElement(res.getString(columns));
rows.addElement(newRow);
return rows; -
IdcService LOAD_USER_LOCALIZATION does not fetch Resultset SystemTimeZones in UCM11g
Hi,
In UCM11g, when we examine the output after executing IdcService, LOAD_USER_LOCALIZATION we notice that the Resultset SystemTimeZones is not getting fetched. Where as it does get fetched in 10g.
i.e. when i access the following URL in 11g, i cannot see the Resultset SystemTimeZones being fetched,
http://host:16200/cs/idcplg?IdcService=LOAD_USER_LOCALIZATION&IsJava
Where in when i access the same 10g URL, i see Resultset SystemTimeZones.
I am in need of this because we are migrating code from 10g to 11g and there is part of the code i.e. failing because of this.
Is there a way to get Resultset SystemTimeZones in 11g too.
Thanks in advance...
Seshan K.Hi Seshan ,
The resultset cannot be retrieved if it is not there in there in the response of idc service . I think you are looking for some specific output w.r.t 10g , but are not clear on what exactly it is .
What is the exact use case of the section where SystemTimeZone is being retrieved ? It's just a list of all available TZ details and it's offsets.
Thanks,
Srinath -
Fetching resultset from SP - mssql
I am calling an SP from MSSQL database.
The SP creates a temporary table and pushes data into that table. There is a select query on that temporary table at the end of the SP which retrieves records from that temporary table. The table gets deleted at the closure of the SP.
When I am calling this SP the rs.execute() is returning false. (I am supposed to get multiple resultsets)
Is this just because SP is retrieving data from the temp table.
I was successfull in calling the same SP (then it was having a series of select statements returning multiple resultsets)
please suggest.
rk.
SP - Stored Procedure
Message was edited by:
passion_for_javaisnt it possible to fetch rows from a SP that has a temporary table???
-
What is the use of fetching a ResultSet? and how can we implemnet it?,
for better performance in application.
-
Fetching Resultset by rowid..!
Hi,
I have a serious problem..with my application..!
I need to fetch sets of 100 records from a result set at a time..!
I mean if result set of a query consists of 2000 records.. I need to fetch only
first 100 records ..then next 100 and so on and send it to some other external
system..from my application..!
How can we do this ..!
My plan is to use rowid..but can we efficiently use rowid in the where clause of
the Sql queries..!
Regards
RaviYes..! I know this funda..!
But my sql stmt is a combination of fixed string and repeat string..
i mean it will output data into two string variables wherein fixed is to store a
single record and repeat is to store more than one record.
Now if i am using bulk fetch it's giving me error..!
My sample sql stmt output will be like this..!
#K01~~~~~~~1000000>^K01A201070026002~KRW~1000000~1020000~20070102~20080102~~K010000001017268~3991000~~~XXXXXXXXXXXXXXXXXXXXXXXXXX~~20080102~20000~~~K01~20080102~>#KRW~20000~1000000@
starting from # to > is a sinle record stored in fixed field and
starting from ^ to @ are multiple records stored in repeat field..
Now tell me how can i bulk fetch these records..!
Any other ideas..! -
Pls help fetch resultset error(2 rst.next() in one loop)?
hi I got the following problem:, would any help me?
while(rst.next())
{ somtehings
rst.next() <--- error occurs if the ResultSet return odd number rec.?
somtehings
the above statment used to show two records in one row.Hi,
I think it is wrong to use rst.next into the while statment...
the following code is an example of while "loop" and as you can see, I don't use result.next() in the loop, but only in its condition :
while (result.next()){
out.println("<tr>");
out.println("<td valign=top width='25%'>");
out.println(result.getString("username"));
out.println("</td>");
out.println("<td valign=top width='25%'>");
out.println(result.getString("password"));
out.println("</td>");
out.println("<td valign=top width='25%'>");
out.println(result.getString("date_from"));
out.println("</td>");
out.println("<td valign=top width='25%'>");
out.println(result.getString("date_to"));
out.println("</td>");
out.println("</tr>");
I don't understand your question: "do you need to work two lines per loop?"
bye
Ivan -
Advanced table copy and delete slow when done programatically
I am modifying a line in an advanced table, then copying it and deleting it. What I noticed is that
it takes a lot less time to copy and delete manually within the application verses doing it programatically.
To copy or delete 10 lines it takes about 1 or 2 seconds within the form. When I do this programatically
it can take up to 20 seconds. Does anyone know why it takes so much longer?
Here is a sample of my code.
porequisitionlinesvorowimpl.setSelected("Y"); //programatically select line for copy
ArrayList deletearraylist = null;
String s1 = porequisitionlinesvorowimpl.getItemNumber();
java.sql.Connection connection = oadbtransaction.getJdbcConnection();
//Query values from for child item.
OraclePreparedStatement oraclepreparedstatement = null;
ResultSet resultset = null;
try {oraclepreparedstatement = (OraclePreparedStatement)connection.prepareStatement("SELECT I2.DESCRIPTION WHERE I.SEGMENT1 = ?");
int i = 1;
oraclepreparedstatement.defineColumnType(i++, 12, 240); oraclepreparedstatement.setString(1, s1);
resultset = oraclepreparedstatement.executeQuery();
while(resultset.next())
//Collect values from query for child item.
String desc = resultset.getString(1);
porequisitionlinesvorowimpl.setItemDescription(desc);
//Copy modified parent to produce a child line.
ArrayList copyarraylist = new ArrayList(2);
copyarraylist.add("populateAndDuplicate");
copyarraylist.add("lines");
executeServerCommand(oapagecontext, oaapplicationmodule, "CheckoutLinesSvrCmd", copyarraylist);
} //while loop for resultset
resultset.close();
oraclepreparedstatement.close();
catch(SQLException sqlexception) {
ErrorUtil.handleFatalException(oadbtransaction, sqlexception, this);
//Delete original Kit Parent
deletearraylist = new ArrayList(2);
deletearraylist.add("populateAndDeleteReqLines");
deletearraylist.add("lines");
executeServerCommand(oapagecontext, oaapplicationmodule, "CheckoutLinesSvrCmd", deletearraylist);I timed these too and they appeared to completed very quickly. The only events that took a significant amount of time where the calls to the executeServerCommand when I copied and deleted lines.
Can the database connection and looping the resultset be slowing these activities down?
There is no VO existing that generates the query results I am looking for. Do I need to create my own VO? -
Fetching metadata via procedure.
Hi ,
I am trying to fetch resultset from an Oracle procedure, which in turn is selecting the data from meta tables (i.e select * from all_tables). I am getting blank data when i try to get this info. via procedure, but if i write simple select statement in my java code, then i get the values properly.
Is there any such restriction in JDBC API's that i can't fetch metadata table values via a database procedure call ??The question is confusing.
JDBC allows for meta data, for example the names of fields, which one could get when a result set is returned. That isn't the data in the result set but rather the meta data about the result set.
On the other hand so far as I now the following phrase is meainingless both in JDBC and Oracle
"data from meta tables"
A driver is required to return meta data (JDBC) at all so it can certainly choose to return nothing for a stored proc. -
How to Exchange Data and Events between LabVIEW Executables
I am having some trouble determining how to design multiple programs that can exchange data or events between each other when compiled into separate executables. I will layout the design scenario:
I have two VIs, one called Status and the other Graph. The Status VI displays the serial number and status of each DUT being tested (>50 devices). The Status VI has one timed loop along with a while loop that contains an event structure. If the user clicks on the DUT Status Cluster the event structure needs to pass the serial number to the Graph VI. The Graph VI when called fetches the records for the DUT based on the Serial Number and time frame. This VI is a producer/consumer so the user can change the time frame of the records to display onto the front panel graph.
I have a couple reasons the VIs need to be separated into independent applications. One being the underlying database fetches tends to slow the threads down between the two VIs; the other is that they may be distributed into separate systems (don't consider this in the design criteria).
I have been researching the available methods to pass the serial number to the Graph VI. My initial idea was to us a command line argument, but this does not allow the Status VI to pass another Serial Number to the Graph once it has started (I do not want to allow the user to execute multiple Graph applications because the database query can load down the server).
Is there a program method that I can implement between the two VIs that will allow me to compile them as two executables, and allow the Status program the repeatedly send an updated serial number event to the Graphs program.
I have reviewed many methods; Pipes (oglib_pipe), Action Engine, and Shared Variable. I am not sure which method will give me the ability to use a Event driven structure to inform the Graphs program when to update the serial number. Any suggestions and tutorials or examples would be greatly appreciated.I have used the Action Engine (aka: functional global) approach for many years and it works well. Something to think about is that if you make the event's datatype a variant the only code that will need to know the actual structure of the event will be the function that needs to respond to it. Hence, a single event can service multiple functions.
Simply create a cluster containing an enum typedef that is a list of the functions that the event will service, and a variant that will be the function event data. From anywhere in the code you can fire the event (via the functional global) by selecting the function from the enum and converting function specific data to a variant. On the receiving end the event handler uses the enum to determine the function that is to get the data and sends the variant to it. The event handler doesn't know or care what the actual event data is so you could in theory add new functions without modifying the event handler.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps -
DBLINK truncation with SAP HANA db
Hi - I have Oracle 11g installed in my Windows laptop and dblink connected to SAP's HANA database via ODBC using the HANA odbc driver. My NVARCHAR data in HANA is being truncated in half. I am working thru sqlplus. Same result in SQL developer client tool. The VARCHAR data is ok. I created three Oracle instances with the only difference being the NLS_CHARACTERSET & NLS_NCHAR_CHARACTERSET values. I have three SIDS: orcl, orulu, and orclutf8. All with the same result. My gateway settings for each are all the same. I started testing with SID orcl and once I found that out I decided to create orclu and orclutf8. In our Unix boxes, we have orcl and orclu settings and those are behaving the same (we use unixodbc.org as the mgr).
I provided orclutf8 gateway .ora file and the orclut8 system info below.
Symptoms/Info:
The character set of HANA db is AL32UTF8.
The HANA db table contains NVARCHAR and have Unicode values (eg: em dash, even Chinese char). NVARCHAR columns gets cut in half as shown in sqlplus (same in sql developer).
For the half that do show up, the actual Unicode character shows up in sqlplus as either unprintable character or upside down question mark or a \u character. This is ok coz no abends therefore data gets process and let my customers deal with the non-converted data – it is ok with them.
Since all SIDs are behaving the same way, I provided you information for orclutf8: initdwutf.ora, the system info, and the trace file. Of all things that SHOULD work, it is the one with the exact character set to HANA.
I have two tables in HANA with the same number of columns and rows. Only difference is NVARCHAR versus VARCHAR.There are three columns with 3, 20, and 150 length.
I took a Oracle trace when selecting from each table and compared them both. I pasted a picture at the bottom. The left side is the VARCHAR and right side NVARCHAR. You can see the HANA odbc driver report a truncation issue on line 209 but I do not see this error in sqlplus. I have a SAP incident open on this.
Is there something in the Oracle side that can be tried? For example, in the trace compare picture, the VARCHAR trace shows that is doubled the data size for each column from 3, 20, and 150 to 6, 40, and 300. In the NVARCHAR it did not.
SID: orcl
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET’;
WE8MSWIN1252
SELECT value$ FROM sys.props$ WHERE name = 'NLS_NCHAR_CHARACTERSET’;
AL16UTF16
SID: orclu
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET’;
AL32UTF8
SELECT value$ FROM sys.props$ WHERE name = 'NLS_NCHAR_CHARACTERSET’;
AL16UTF16
SID: orclutf8
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET’;
AL32UTF8
SELECT value$ FROM sys.props$ WHERE name = 'NLS_NCHAR_CHARACTERSET’;
UTF8
initdw7utf.ora:
# This is a sample agent init file that contains the HS parameters that are
# needed for the Database Gateway for ODBC
# HS init parameters
#HS_FDS_CONNECT_INFO = <odbc data_source_name>
HS_FDS_CONNECT_INFO = HANADW7
HS_FDS_TRACE_LEVEL=DEBUG
#HS_LANGUAGE=AL32UTF8
HS_LANGUAGE=AMERICAN_AMERICA.AL32UTF8
HS_FDS_REMOTE_DB_CHARSET=AL32UTF8
# Environment variables required for the non-Oracle system
#set <envvar>=<value>
SELECT * FROM sys.props$:
DICT.BASE 2
DEFAULT_TEMP_TABLESPACE TEMP
DEFAULT_PERMANENT_TABLESPACE USERS
DEFAULT_EDITION ORA$BASE
Flashback Timestamp TimeZone GMT
TDE_MASTER_KEY_ID
DST_UPGRADE_STATE NONE
DST_PRIMARY_TT_VERSION 11
DST_SECONDARY_TT_VERSION 0
DEFAULT_TBS_TYPE SMALLFILE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET AL32UTF8
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET UTF8
NLS_RDBMS_VERSION 11.2.0.1.0
GLOBAL_DB_NAME ORCLUTF8
EXPORT_VIEWS_VERSION 8
WORKLOAD_CAPTURE_MODE
WORKLOAD_REPLAY_MODE
NO_USERID_VERIFIER_SALT 57505D68AFECC3BCECE484A1C42CC8CE
DBTIMEZONE 00:001) When I tried HS_KEEP_REMOTE_COLUMN_SIZE=LOCAL the nvarchar select statement still truncated and displayed them in sqlplus.
For the varchar select statement, it just error'ed out in sqlplus.
ERROR:
ORA-28562: Heterogeneous Services data truncation error
ORA-02063: preceding line from DEVUTF8
no rows selected
I commented out the HS_KEEP_REMOTE_COLUMN_SIZE=LOCAL for now.
2) For the nvarchar select statement, I do not get an error messages via sqlplus. I get the records displayed truncated in half they should be. A native odbc error do show up in the Oracle Trace file. I think that comes from the HANA odbc driver. It is line 209 of the picture in my original thread.
3) DESCRIBE commands output below:
SQL> desc ESBA_DB.ZTESTSAP@DEVUTF8 - THIS IS THE NVARCHAR TABLE. The sizes match what is in HANA db.
Name Null? Type
MANDT NOT NULL NVARCHAR2(3)
NAME NOT NULL NVARCHAR2(20)
NAME_150 NOT NULL NVARCHAR2(150)
SQL> desc PTAN.ZTESTSAP_VC@DEVUTF8 - THIS IS THE VARCHAR TABLE.The sizes do not match what is in HANA db.
Name Null? Type
MANDT VARCHAR2(1)
NAME VARCHAR2(6)
NAME150 VARCHAR2(50)
4) Below is the gateway trace. I included from the first occurence of hgodscr and all the way to the end of it. You can see the HANA odbc driver truncation.
Entered hgodscr, cursor id 1 at 2014/10/02-11:15:41
Allocate hoada @ 03705518
Entered hgopcda at 2014/10/02-11:15:41
Column:1(M): dtype:-9 (WVARCHAR), prc/scl:3/0, nullbl:1, octet:3, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/10/02-11:15:41
Entered hgopcda at 2014/10/02-11:15:41
Column:2(N): dtype:-9 (WVARCHAR), prc/scl:20/0, nullbl:1, octet:20, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/10/02-11:15:41
Entered hgopcda at 2014/10/02-11:15:41
Column:3(N): dtype:-9 (WVARCHAR), prc/scl:150/0, nullbl:1, octet:150, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/10/02-11:15:41
hgodscr, line 910: Printing hoada @ 03705518
MAX:3, ACTUAL:3, BRC:100, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
12 VARCHAR Y 3 3 128/ 3 1000 0 40 MANDT
12 VARCHAR Y 20 20 128/ 20 1000 0 40 NAME
12 VARCHAR Y 150 150 128/150 1000 0 40 NAME_150
Exiting hgodscr, rc=0 at 2014/10/02-11:15:41
Entered hgoftch, cursor id 1 at 2014/10/02-11:15:41
hgoftch, line 130: Printing hoada @ 03705518
MAX:3, ACTUAL:3, BRC:100, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
12 VARCHAR Y 3 3 128/ 3 1000 0 40 MANDT
12 VARCHAR Y 20 20 128/ 20 1000 0 40 NAME
12 VARCHAR Y 150 150 128/150 1000 0 40 NAME_150
Performing delayed open.
SQLBindCol: column 1, cdatatype: -8, bflsz: 6
SQLBindCol: column 2, cdatatype: -8, bflsz: 22
SQLBindCol: column 3, cdatatype: -8, bflsz: 152
Entered hgopoer at 2014/10/02-11:15:41
hgopoer, line 233: got native error 0 and sqlstate 01004; message follows...
[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}
Exiting hgopoer, rc=0 at 2014/10/02-11:15:41
hgoftch, line 740: calling SQLFetch got sqlstate 01004
SQLFetch: row: 1, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 1, column 1, bflsz: 6, bflar: 6, (bfl: 3, mbl: 3)
SQLFetch: row: 1, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 1, column 2, bflsz: 22, bflar: 6, (bfl: 20, mbl: 20)
SQLFetch: row: 1, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 1, column 3, bflsz: 152, bflar: 0, (bfl: 150, mbl: 150)
SQLFetch: row: 2, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 2, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 2, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 2, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 2, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 2, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 3, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 3, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 3, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 3, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 3, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 3, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 4, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 4, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 4, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 4, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 4, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 4, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 5, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 5, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 5, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 5, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 5, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 5, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 6, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 6, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 6, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 6, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 6, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 6, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 7, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 7, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 7, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 7, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 7, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 7, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 8, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 8, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 8, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 8, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 8, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 8, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 9, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 9, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 9, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 9, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 9, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 9, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 10, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 10, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 10, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 10, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 10, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 10, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 11, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 11, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 11, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 11, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 11, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 11, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 12, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 12, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 12, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 12, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 12, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 12, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 13, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 13, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 13, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 13, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 13, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 13, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 14, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 14, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 14, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 14, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 14, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 14, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 15, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 15, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 15, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 15, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 15, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 15, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 16, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 16, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 16, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 16, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 16, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 16, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 17, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 17, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 17, column 2, bflsz: 22, bflar: 32
SQLFetch: row: 17, column 2, bflsz: 22, bflar: 32, (bfl: 0, mbl: 20)
SQLFetch: row: 17, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 17, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 18, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 18, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 18, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 18, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 18, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 18, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 19, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 19, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 19, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 19, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 19, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 19, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 20, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 20, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 20, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 20, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 20, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 20, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 21, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 21, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 21, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 21, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 21, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 21, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 22, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 22, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 22, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 22, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 22, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 22, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 23, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 23, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 23, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 23, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 23, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 23, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 24, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 24, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 24, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 24, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 24, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 24, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 25, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 25, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 25, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 25, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 25, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 25, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 26, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 26, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 26, column 2, bflsz: 22, bflar: 32
SQLFetch: row: 26, column 2, bflsz: 22, bflar: 32, (bfl: 0, mbl: 20)
SQLFetch: row: 26, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 26, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 27, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 27, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 27, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 27, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 27, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 27, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 28, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 28, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 28, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 28, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 28, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 28, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 29, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 29, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 29, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 29, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 29, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 29, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 30, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 30, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 30, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 30, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 30, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 30, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 31, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 31, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 31, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 31, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 31, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 31, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 32, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 32, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 32, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 32, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 32, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 32, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 33, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 33, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 33, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 33, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 33, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 33, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 34, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 34, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 34, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 34, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 34, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 34, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 35, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 35, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 35, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 35, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 35, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 35, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 36, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 36, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 36, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 36, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 36, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 36, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 37, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 37, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 37, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 37, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 37, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 37, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 38, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 38, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 38, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 38, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 38, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 38, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 39, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 39, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 39, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 39, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 39, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 39, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 40, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 40, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 40, column 2, bflsz: 22, bflar: 38
SQLFetch: row: 40, column 2, bflsz: 22, bflar: 38, (bfl: 0, mbl: 20)
SQLFetch: row: 40, column 3, bflsz: 152, bflar: 298
SQLFetch: row: 40, column 3, bflsz: 152, bflar: 298, (bfl: 0, mbl: 150)
40 rows fetched
Exiting hgoftch, rc=0 at 2014/10/02-11:15:42 with error ptr FILE:hgoftch.c LINE:740 ID:Fetch resultset data
Entered hgoftch, cursor id 1 at 2014/10/02-11:15:42
hgoftch, line 130: Printing hoada @ 03705518
MAX:3, ACTUAL:3, BRC:40, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
12 VARCHAR Y 4 3 128/ 3 1000 0 40 MANDT
12 VARCHAR Y 6 20 128/ 20 1000 0 40 NAME
12 VARCHAR Y 0 150 128/150 1000 0 40 NAME_150
0 rows fetched
Exiting hgoftch, rc=1403 at 2014/10/02-11:15:42
Entered hgoclse, cursor id 1 at 2014/10/02-11:15:46
Exiting hgoclse, rc=0 at 2014/10/02-11:15:46
Entered hgodafr, cursor id 1 at 2014/10/02-11:15:46
Free hoada @ 03705518
Exiting hgodafr, rc=0 at 2014/10/02-11:15:46
Entered hgocomm at 2014/10/02-11:15:46
keepinfo:0, tflag:1
00: 4F52434C 55544638 2E376265 35343664 [ORCLUTF8.7be546d]
10: 392E312E 32362E36 3630 [9.1.26.660]
tbid (len 23) is ...
00: 4F52434C 55544638 5B312E32 362E3636 [ORCLUTF8[1.26.66]
10: 305D5B31 2E345D [0][1.4]]
cmt(0):
Entered hgocpctx at 2014/10/02-11:15:46
Exiting hgocpctx, rc=0 at 2014/10/02-11:15:46
Exiting hgocomm, rc=0 at 2014/10/02-11:15:46
Entered hgolgof at 2014/10/02-11:15:46
tflag:1
Exiting hgolgof, rc=0 at 2014/10/02-11:15:46
Entered hgoexit at 2014/10/02-11:15:46
Exiting hgoexit, rc=0 -
Using more than one sysrefcursors in a procedure.
Hi,
can we use 2 -3 sysrefcursors to get 3 different resultset out from a single plsql procedure for particular page on front end? each sysrefcursor with with different select?
I have to fetch resultset and fire a query for searching data, finding aggregate on few fields and one more query for finding aggregates.
can we do this?
Could you please reply this with simple example?
Thanks a lot.>
can we use 2 -3 sysrefcursors to get 3 different resultset out from a single plsql procedure for particular page on front end? each sysrefcursor with with different select?
I have to fetch resultset and fire a query for searching data, finding aggregate on few fields and one more query for finding aggregates.
can we do this?
Could you please reply this with simple example?
>
You can pretty use as many as you like. Just define them as OUT parameters (or IN OUT) and open them all before the procedure returns.
I've seen 50 used in one procedure at a large financial institution. Of course they had performance problems related to that.
Keep in mind that every cursor you open causes Oracle to perform ALL of the parsing and read consistency work needed to service ALL of the cursors. So if you open three cursors but the user only uses one of them the work for the other two is wasted and can contribute to performance issues.
Here is an example using one cursor. You can add more to expand the example.
CREATE OR REPLACE TYPE SCOTT.local_type IS OBJECT (
empno NUMBER(4),
ename VARCHAR2(10));
CREATE OR REPLACE TYPE SCOTT.local_tab_type IS TABLE OF local_type;
CREATE OR REPLACE PACKAGE SCOTT.test_refcursor_pkg
AS
TYPE my_ref_cursor IS REF CURSOR;
-- add more cursors as OUT parameters
PROCEDURE test_proc(p_ref_cur_out OUT test_refcursor_pkg.my_ref_cursor);
END test_refcursor_pkg;
CREATE OR REPLACE PACKAGE BODY SCOTT.test_refcursor_pkg
AS
PROCEDURE test_proc(p_ref_cur_out OUT test_refcursor_pkg.my_ref_cursor)
AS
l_recs local_tab_type;
BEGIN
-- Get the records to modify individually.
SELECT local_type(empno, ename) BULK COLLECT INTO l_recs
FROM EMP;
-- Perform some complex calculation for each row.
FOR i IN l_recs.FIRST .. l_recs.LAST
LOOP
DBMS_OUTPUT.PUT_LINE(l_recs(i).ename);
END LOOP;
-- Put the modified records back into the ref cursor for output.
OPEN p_ref_cur_out FOR
SELECT * from TABLE(l_recs);
-- open more ref cursors here before returning
END test_proc;
END;
SET SERVEROUTPUT ON SIZE 1000000
DECLARE
l_cursor test_refcursor_pkg.my_ref_cursor;
l_ename emp.ename%TYPE;
l_empno emp.empno%TYPE;
BEGIN
test_refcursor_pkg.test_proc (l_cursor);
LOOP
FETCH l_cursor
INTO l_empno, l_ename;
EXIT WHEN l_cursor%NOTFOUND;
DBMS_OUTPUT.PUT_LINE(l_ename || ' | ' || l_empno);
END LOOP;
CLOSE l_cursor;
END;
/ -
Problem with boolean type in Informix via ODBC
Hello,
I'm connecting to an Informix database from an Oracle database via the ODBC Gateway. The connection works fine.
However, when I select a boolean type column from a table in the Informix database, nothing is returned and I get the following error:
SQL> select "stat" from bt@informix;
ERROR:
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
[Informix][Informix ODBC Driver]Restricted data type attribute violation.
{07006,NativeErr = -11013}
ORA-02063: preceding 2 lines from INFORMIX
no rows selected
Selecting a boolean type column with isql works fine. Other column types work from Oracle.
Can anyone help me resolve this issue? Please find configuration details and traces below.
Software stack:
Informix Database: Enterprise Edition 12.10 for Linux x86_64
Informix ODBC driver: Informix Client SDK Developer Edition 4.10 for Linux 64-bit
Oracle Database: Enterprise Edition 11.2.0.1.0 64-bit (Oracle Linux 6.6 64-bit)
UnixODBC: 2.3.2 x86_64
odbcinst.ini:
[Informix]
Driver=/opt/IBM/informix/lib/cli/libifcli.so
Setup=/opt/IBM/informix/lib/cli/libifcli.so
APILevel=1
ConnectFunctions=YYY
DriverODBCVer=03.51
FileUsage=0
SQLLevel=1
smProcessPerConnect=Y
[ODBC]
TraceFile=/tmp/odbc.log
Trace = Yes
odbc.ini:
[ol_informix1210]
Driver=Informix
Description=Test connection
Database=sysutils
LogonID=informix
pwd=informix
Servername=ol_informix1210
CursorBehavior=0
DB_LOCALE=en_us.8859-1
TRANSLATIONDLL=/opt/IBM/informix/lib/esql/igo4a304.so
[ODBC]
UNICODE=UCS-2
; Trace file Section
Trace=1
TraceFile=/tmp/odbctrace.out
InstallDir=/opt/IBM/informix
TRACEDLL=idmrs09a.so
Oracle Gateway init.ora:
HS_FDS_CONNECT_INFO=ol_informix1210
HS_FDS_SHAREABLE_NAME=/usr/local/lib/libodbc.so
HS_FDS_TRACE_LEVEL=debug
HS_LANGUAGE=AMERICAN_AMERICA.WE8ISO8859P1
Oracle Gateway trace:
Entered hgoftch, cursor id 1 at 2015/04/14-12:22:03
hgoftch, line 130: Printing hoada @ 0x2007fe0
MAX:1, ACTUAL:1, BRC:100, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x20:NEGATIVE_HOADADTY)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
-7 BIT Y 1 1 0/ 0 0 0 20 stat
Performing delayed open.
SQLBindCol: column 1, cdatatype: -28, bflsz: 1
Entered hgopoer at 2015/04/14-12:22:03
hgopoer, line 233: got native error -11013 and sqlstate 07006; message follows...
[Informix][Informix ODBC Driver]Restricted data type attribute violation. {07006,NativeErr = -11013}
Exiting hgopoer, rc=0 at 2015/04/14-12:22:03
hgoftch, line 730: calling SQLFetch got sqlstate 07006
0 rows fetched
Exiting hgoftch, rc=28500 at 2015/04/14-12:22:03 with error ptr FILE:hgoftch.c LINE:730 FUNCTION:hgoftch() ID:Fetch resultset data
ODBC trace:
[ODBC][11041][1429005970.973443][SQLPrepare.c][196]
Entry:
Statement = 0x276ecb0
SQL = [SELECT A1. stat FROM BT A1][length = 29]
[ODBC][11041][1429005970.973914][SQLPrepare.c][371]
Exit:[SQL_SUCCESS]
[ODBC][11041][1429005970.973940][SQLNumResultCols.c][156]
Entry:
Statement = 0x276ecb0
Column Count = 0x26f5868
[ODBC][11041][1429005970.973970][SQLNumResultCols.c][248]
Exit:[SQL_SUCCESS]
Count = 0x26f5868 -> 1
[ODBC][11041][1429005970.974097][SQLDescribeCol.c][247]
Entry:
Statement = 0x276ecb0
Column Number = 1
Column Name = 0x7fffc3ff2d90
Buffer Length = 31
Name Length = 0x7fffc3ff2ed4
Data Type = 0x7fffc3ff2ed8
Column Size = 0x7fffc3ff2e70
Decimal Digits = 0x7fffc3ff2edc
Nullable = 0x7fffc3ff2ee0
[ODBC][11041][1429005970.974140][SQLDescribeCol.c][501]
Exit:[SQL_SUCCESS]
Column Name = [stat]
Data Type = 0x7fffc3ff2ed8 -> -7
Column Size = 0x7fffc3ff2e70 -> 1
Decimal Digits = 0x7fffc3ff2edc -> 0
Nullable = 0x7fffc3ff2ee0 -> 1
[ODBC][11041][1429005970.974192][SQLSetStmtAttr.c][265]
Entry:
Statement = 0x276ecb0
Attribute = SQL_ATTR_ROW_ARRAY_SIZE
Value = 0x64
StrLen = 0
[ODBC][11041][1429005970.974218][SQLSetStmtAttr.c][925]
Exit:[SQL_SUCCESS]
[ODBC][11041][1429005970.974230][SQLSetStmtAttr.c][265]
Entry:
Statement = 0x276ecb0
Attribute = SQL_ATTR_ROW_BIND_TYPE
Value = (nil)
StrLen = -5
[ODBC][11041][1429005970.974249][SQLSetStmtAttr.c][925]
Exit:[SQL_SUCCESS]
[ODBC][11041][1429005970.974837][SQLExecute.c][187]
Entry:
Statement = 0x276ecb0
[ODBC][11041][1429005970.975231][SQLExecute.c][348]
Exit:[SQL_SUCCESS]
[ODBC][11041][1429005970.975255][SQLSetStmtAttr.c][265]
Entry:
Statement = 0x276ecb0
Attribute = SQL_ATTR_ROW_STATUS_PTR
Value = 0x27f5b78
StrLen = -4
[ODBC][11041][1429005970.975280][SQLSetStmtAttr.c][925]
Exit:[SQL_SUCCESS]
[ODBC][11041][1429005970.975291][SQLSetStmtAttr.c][265]
Entry:
Statement = 0x276ecb0
Attribute = SQL_ATTR_ROWS_FETCHED_PTR
Value = 0x26f5850
StrLen = -4
[ODBC][11041][1429005970.975311][SQLSetStmtAttr.c][925]
Exit:[SQL_SUCCESS]
[ODBC][11041][1429005970.975326][SQLBindCol.c][236]
Entry:
Statement = 0x276ecb0
Column Number = 1
Target Type = -28 SQL_C_UTINYINT
Target Value = 0x27f5af8
Buffer Length = 1
StrLen Or Ind = 0x27f5eb8
[ODBC][11041][1429005970.975349][SQLBindCol.c][341]
Exit:[SQL_SUCCESS]
[ODBC][11041][1429005970.975367][SQLFetch.c][162]
Entry:
Statement = 0x276ecb0
[ODBC][11041][1429005970.975455][SQLFetch.c][348]
Exit:[SQL_ERROR]
DIAG [07006] [Informix][Informix ODBC Driver]Restricted data type attribute violation.
[ODBC][11041][1429005970.975574][SQLGetDiagRec.c][758]
Entry:
Statement = 0x276ecb0
Rec Number = 1
SQLState = 0x7fffc3ff2e20
Native = 0x7fffc3ff2c14
Message Text = 0x7fffc3ff2c20
Buffer Length = 510
Text Len Ptr = 0x7fffc3ff2e70
[ODBC][11041][1429005970.975615][SQLGetDiagRec.c][795]
Exit:[SQL_SUCCESS]
SQLState = 07006
Native = 0x7fffc3ff2c14 -> -11013
Message Text = [[Informix][Informix ODBC Driver]Restricted data type attribute violation.]
[ODBC][11041][1429005970.975642][SQLGetDiagRec.c][758]
Entry:
Statement = 0x276ecb0
Rec Number = 2
SQLState = 0x7fffc3ff2e20
Native = 0x7fffc3ff2c14
Message Text = 0x7fffc3ff2c20
Message Text = 0x7fffc3ff2c20
Buffer Length = 510
Text Len Ptr = 0x7fffc3ff2e70
[ODBC][11041][1429005970.975667][SQLGetDiagRec.c][795]
Exit:[SQL_NO_DATA]Here are my findings after consulting the unixODBC mailing list and the IBM documentation.
There are several levels of data types at play here: native Informix SQL types, Informix ODBC driver SQL types and Informix ODBC driver C types (as well as standard C types).
According to the Informix documentation (http://www-01.ibm.com/support/knowledgecenter/SSGU8G_11.70.0/com.ibm.odbc.doc/ids_odbc_108.htm), the ODBC driver SQL type for the native boolean type is SQL_BIT.
The traces show that the ODBC SQL type is SQL_BIT (type code -7) and that this should be converted into the SQL_C_UTINYINT ODBC C type (type code -28).
Oracle ODBC Gateway trace:
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
-7 BIT Y 1 1 0/ 0 0 0 20 stat
Performing delayed open.
SQLBindCol: column 1, cdatatype: -28, bflsz: 1
unixODBC trace:
ODBC][11041][1429005970.975326][SQLBindCol.c][236]
Entry:
Statement = 0x276ecb0
Column Number = 1
Target Type = -28 SQL_C_UTINYINT
Target Value = 0x27f5af8
Buffer Length = 1
StrLen Or Ind = 0x27f5eb8
[ODBC][11041][1429005970.975349][SQLBindCol.c][341]
Oracle tries to bind the SQL_BIT type column to a buffer of SQL_C_UTINYINT type, which requires a conversion from SQL_BIT to SQL_C_UTINYINT that is apparently not supported by the Informix ODBC Driver.
According to the documentation (http://www-01.ibm.com/support/knowledgecenter/SSGU8G_11.70.0/com.ibm.odbc.doc/ids_odbc_108.htm) the Informix ODBC driver can only convert the SQL_BIT ODBC SQL type into SQL_C_BINARY, SQL_C_BIT and SQL_C_CHAR ODBC C types. (The ODBC C types are in turn converted into standard C types, for example the SQL_C_BIT type is converted into UCHAR which is a typedef for the standard C type unsigned char.)
A possible workaround could be to tell Informix to present boolean as a different ODBC SQL type, for example SQL_CHAR (as it would be possible with PostgreSQL by setting BoolAsCharater=1 in odbc.ini), but Informix only seems to supports the SQL_BIT ODBC SQL type.
A cumbersome workaround is to use the Gateway's pass-through feature that allows a query to be passed to Informix as is, which in turn allows us to cast the boolean field into a character field:
SQL> set serveroutput on
SQL> r
1 DECLARE
2 val VARCHAR2(1);
3 c INTEGER;
4 nr INTEGER;
5 BEGIN
6 c := DBMS_HS_PASSTHROUGH.OPEN_CURSOR@informix;
7 DBMS_HS_PASSTHROUGH.PARSE@informix(c,'select cast (stat as character) from bt');
8 LOOP
9 nr := DBMS_HS_PASSTHROUGH.FETCH_ROW@informix(c);
10 EXIT WHEN nr = 0;
11 DBMS_HS_PASSTHROUGH.GET_VALUE@informix(c, 1, val);
12 DBMS_OUTPUT.PUT_LINE(val);
13 END LOOP;
14 DBMS_HS_PASSTHROUGH.CLOSE_CURSOR@informix(c);
15 END;
16*
t
f
PL/SQL procedure successfully completed
Easier solutions are still welcome. -
Connection string for 9i from vb6.0
i am accessing a package and stored procedure inside the package from vb 6.0 application. the record fetch is too slow and takes about 4 mins for just 11 records. if i execute the package directly it takes 3 seconds for the records to be fetched. i am using MSDAORA.1 provider for this with LDAP security permissions
how to overcome the slow retrieval of records from the application?Maybe this one helps.
https://community.oracle.com/message/2310374
or possibly ask them here.
https://www.oracle.com/communities/index.html
Regards, Dave Patrick ....
Microsoft Certified Professional
Microsoft MVP [Windows]
Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
Maybe you are looking for
-
I have just brought 2 mini's for my boys for xmas. 1. can I connect them both to my existing Itunes account or do I need to set up something different. and 2. can they be used on their dads account as well as mine, or only one?
-
Windows 8.1 won't update on my HP 15-G060CA
I have tried everything I can think of - which isn't much - the computer says major error and won't work with recovery or any;thing else I try. It is stuck on an 8.1 update from November 2014. Any ideas?
-
Automatic Parallelism causes Merge statement to take longer.
We have a problem in a new project as part of the ETL load into the Oracle datawarehouse we perform a merge statement to update rows in a global temporary table then load the results into a permanant table, when testing with automatic parallel execut
-
Cannot locate the Ideas Forum where you can post and vote for new enhancements to FormsCentral. Can someone help me with a link? Thank you!
-
Triggering external exe/app minimized (or window focus control) in AIR?
Hello all, I'm wrapping up a big flex/AIR app and very excited about it, but there's one thing that's bugging me: in the program I need to repeatedly open and run external files (speech recognition scripts) but when I do so, the window for that exec