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
Ravi

Yes..! 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..!

Similar Messages

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_java

isnt it possible to fetch rows from a SP that has a temporary table???

Fetching resultSet

What is the use of fetching a ResultSet? and how can we implemnet it?,

for better performance in application.

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

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

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.

What is the significance of "cost" column in explain plan

Hi,
Can anyone explain what is the meaning of the values which we get in the cost column in the explain plan..For Ex : Cost : 4500 . What does this value mean...and is it measured in which form of units...i mean seconds,nanoseconds etc

kingfisher,
Ok one more link for you but I shall quote the text also here,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i82005
The cost is an estimated value proportional to the expected resource use needed to execute the statement with a particular plan. The optimizer calculates the cost of access paths and join orders based on the estimated computer resources, which includes I/O, CPU, and memory.
And few paragraphs down,
13.4.1.3.3 Cost
The cost represents units of work or resource used. The query optimizer uses disk I/O, CPU usage, and memory usage as units of work. So, the cost used by the query optimizer represents an estimate of the number of disk I/Os and the amount of CPU and memory used in performing an operation. The operation can be scanning a table, accessing rows from a table by using an index, joining two tables together, or sorting a row set. The cost of a query plan is the number of work units that are expected to be incurred when the query is executed and its result produced.
The access path determines the number of units of work required to get data from a base table. The access path can be a table scan, a fast full index scan, or an index scan. During table scan or fast full index scan, multiple blocks are read from the disk in a single I/O operation. Therefore, the cost of a table scan or a fast full index scan depends on the number of blocks to be scanned and the multiblock read count value. The cost of an index scan depends on the levels in the B-tree, the number of index leaf blocks to be scanned, and the number of rows to be fetched using the rowid in the index keys. The cost of fetching rows using rowids depends on the index clustering factor. See "Assessing I/O for Blocks, not Rows".
The join cost represents the combination of the individual access costs of the two row sets being joined, plus the cost of the join operation.
Now I guess if you read this part, it should be pretty clear what cost is.Cost is an evlaution of the resource that is estimated by Oracle for every step incurred in the uery execution.There are no of steps and each may involve doing IO,consuming CPU and/or using memory.Cost is a factor which oracle uses combining all of these 3 (depending on the version) together to propose the work done or expected to be done in exeuting a query.So this actualy should represent the time spent exactly on each and every step.That's what the objective frm cost is.But at the moment,this is not there.There amy be a situation that cost is shown as very high but query is working fine.There are woraround which can bring the cost down for example using and tweaking optimizer_index_cost_adj parameter , we can propose oracle regarding our indexes and it may pick up lesser cost evaluation.What is mentioned is that this model is becoming more and more mature and in the next releases, we may see that cost is representing exactly the time that we would spend inthe query.At the moment,its not there.So as Chris mentioned,Tuning for low cost only is not a good way.
I suggest you grab a copy of JL's book.He has explained it much better in his book.
Hope I said some thing useful.
Aman....

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:00

1) 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.

Master Detail Forms with 2 composite primary keys - Is there a workaround?

Hello All,
I have been searching for a workaround to the maximum 2 part primary key restriction on the multi-row updates, and master-detail forms, and am hoping that someone can help me. I am using HTMLDB v2.0.0.00.49 with IE 6 against a 9.2 DB.
I successfully implemented the workaround of Fred Stoopendaal's (see Updata PK on HTML DB ) and it works fine for single page multi-record updateable forms, but alas I haven't been able to extend it to master detail forms (I think it is something to do with Oracle not allowing the "returning" clause on views).
Here is what I tried:
two tables, one with a 2 part composite primary key, which is the master table, and a detail table with 3 part composite primary key -
--------- BEGIN SQL ---------
create table master_table
( master_col1 number
, master_col2 number
, master_col3 varchar2(30)
, constraint master_pk primary key (master_col1,master_col2));
create table detail_table
(detail_col1 number
,detail_col2 number
,detail_col3 number
,detail_col4 varchar2(30)
, constraint detail_pk primary key(detail_col1,detail_col2,detail_col3)
, constraint master_detail_fk foreign key (detail_col1,detail_col2) references master_table(master_col1,master_col2));
create or replace view v_master_table as
select rowid mata_rowid,mata.*
from master_table mata;
create or replace view v_detail_table as
select rowid deta_rowid,
(select rowid from master_table mata where mata.master_col1 = deta.detail_col1 and mata.master_col2 = deta.detail_col2) deta_mata_rowid
, deta.*
from detail_table deta;
create or replace trigger mata_ins_upd_trg
instead of insert or update on v_master_table
referencing new as new old as old
for each row
begin
if inserting then
insert into master_table (master_col1, master_col2, master_col3)
values (:new.master_col1, :new.master_col2, :new.master_col3);
end if;
if updating then
update master_table
set master_col1 = :new.master_col1,
master_col2 = :new.master_col2,
master_col3 = :new.master_col3
where rowid = :old.mata_rowid;
end if;
end;
create or replace trigger deta_ins_upd_trg
instead of insert or update on v_detail_table
referencing new as new old as old
for each row
begin
if inserting then
insert into detail_table ( detail_col1, detail_col2, detail_col3, detail_col4)
values (:new.detail_col1, :new.detail_col2, :new.detail_col3, :new.detail_col4);
end if;
if updating then
update detail_table
set detail_col1 = :new.detail_col1,
detail_col2 = :new.detail_col2,
detail_col3 = :new.detail_col3,
detail_col4 = :new.detail_col4
where rowid = :old.deta_rowid;
end if;
end;
--------- END SQL ---------
Then I created a master-detail form in Apex on the two views, using the mata_rowid and deta_rowid as primary keys, and mata_rowid=deta_mata_rowid as the link. I realise that using a function to fetch the master rowid within the detail view query is costly, but it was my intention to modify the record fetch queries to use the real FK columns once things were up and running.
It seems to generate the pages ok, and I can insert/update master table records, but as soon as I modify records in the detail table things go a bit haywire. I can't find any documentation on how the inbuilt MRU/MRD logic works, so can't figure out the issue.
Can anyone out there tell me what the problem is with the logic above, or if they have come up with a neat solution to this annoying limitation. I know that many will say that I should modify the data model to use surrogate primary keys, but many of the uses for HTMLDB are new interfaces for old schemas, so a workaround that doesn't involve wholesale data model changes would be preferable.
Thanks in advance,
Mike Cretan

Hi, this is likely not the most elegant way...but perhaps the simplest -- and I didn't have much time to play.
I used Wizard to create two separate Master Detail forms, each with a separate detail table. Thus I ended up with four pages:
Page "A" - "Selector" page for Master (Report), with Edit link driving to Detail-1
Page "B" - Editable Master/Detail-1 page (HTML / Report)
Page "C" - "Selector" page for Master (Report), with Edit link driving to Detail-2
Page "D" - Editable Master/Detail-2 page (HTML / Report)
Then I selected the primary key column TWICE on the Report on Page A. Modified the second instance of this column to navigate to Page D (passing primary key) exactly the way the original instance of this column navigates to Page B. Then I deleted Page C.
Since you can have only one Tabular Entry form per page, this seemed the best way to drive two separate detail tables from a common interface.

ORA-28500: connection Error

I am using Oracle gateway for sqlserver 11.2 on Oracle 11.2 database on Linux.
When i run the following query:
select * from prc.PrcIsr@sqlserver;
then after displaying about 10,000 rows, i get the following error message:
ERROR:
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
ORA-02063: preceding line from SQLSERVERThis error comes for all the tables except for minor tables having less than 1000 rows.
Followings are the contents from the trace file:
hgopoer, line 233: got native error 5701 and sqlstate 01000; message follows...
[Oracle][ODBC SQL Server Driver][SQL Server]Changed database context to 'qai'. {01000,NativeErr = 5701}[Oracle][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english. {01000,NativeErr = 5703}[Oracle][ODBC SQL Server Driver]Invalid connection string attribute {01S00}
Exiting hgopoer, rc=0 at 2011/10/12-07:01:30
hgocont, line 2685: calling SqlDriverConnect got sqlstate 01000
Entered hgolosf at 2011/10/12-07:01:30
Exiting hgolosf, rc=0 at 2011/10/12-07:01:30
DriverName:HGmsss23.so, DriverVer:06.00.0056 (b0041, U0039)
DBMS Name:Microsoft SQL Server, DBMS Version:09.00.4060
Exiting hgocont, rc=0 at 2011/10/12-07:01:30 with error ptr FILE:hgocont.c LINE:2685 FUNCTION:hgocont() ID:SQLDriverConnect
SQLGetInfo returns Y for SQL_CATALOG_NAME
hgopoer, line 233: got native error 104 and sqlstate 01000; message follows...
[Oracle][ODBC SQL Server Driver][libssclient24]ConnectionRead (recv()). {01000,NativeErr = 104}[Oracle][ODBC SQL Server Driver][libssclient24]General network error. Check your network documentation. {08S01,NativeErr = 11}
Exiting hgopoer, rc=0 at 2011/10/12-07:03:27
hgoftch, line 730: calling SQLFetch got sqlstate 01000
0 rows fetched
Exiting hgoftch, rc=28500 at 2011/10/12-07:03:27 with error ptr FILE:hgoftch.c LINE:730 FUNCTION:hgoftch() ID:Fetch resultset data
Listener.ora
# listener.ora Network Configuration File: /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 172.18.2.134)(PORT = 1521))
ADR_BASE_LISTENER = /u01/app/oracle
SID_LIST_LISTENER =
(SID_LIST =
    (SID_DESC =
      (SID_NAME = dg4msql)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
      (PROGRAM = dg4msql)
sqlnet.ora
# sqlnet.ora Network Configuration File: /u01/app/oracle/product/11.2.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = /u01/app/oracle
initdg4msql.ora
# This is a customized agent init file that contains the HS parameters
# that are needed for the Database Gateway for Microsoft SQL Server
# HS init parameters
HS_FDS_CONNECT_INFO=[zeus.lhr.com]:1433//qai
# alternate connect format is hostname/serverinstance/databasename
HS_FDS_TRACE_LEVEL=DEBUG
HS_FDS_RECOVERY_ACCOUNT=RECOVER
HS_FDS_RECOVERY_PWD=RECOVER
# custom init parameters
HS_KEEP_REMOTE_COLUMN_SIZE=LOCAL
HS_NLS_LENGTH_SEMANTICS=CHAR
HS_LANGUAGE=AMERICAN_AMERICA.WE8MSWIN1252
HS_NLS_NCHAR=UCS2

the provided trace file doesn't even show the read error.
It suddenly ends in the middle of a fetch:
SQLFetch: row: 27, column 4, bflsz: 16, bflar: -1
SQLFetch: row: 27, column 4, bflsz: 16, bflar: SQL_NULL_DATA
SQLFetch: row: 27, column 5, bflsz: 16, bflar: 16
SQLFetch: row: 27, column 5, bflsz: 16, bflar: 16, (bfl: 16, mbl: 16)
00: B80B0200 1C000000 00000000 00000000 [................]
SQLFetch: row: 27, column 6, bflsz: 4, bflar: 2
SQLFetch: row: 27, column 6, bflsz: 4, bflar: 2
Just to clarify - did you abort the fetch?
What about your network environment - are all machines located in the same network or is for example the SQL Server located outside of your network?
Is there an rdbms/log directory in your OH /u01/app/oracle/product/11.2.0/db_1?
If yes, does it contain a dump file dated with 2011/10/12-08:04:54?
If there is no rdbms/log directory, please create it and retry the select.
BTW, there's already dg4msql 11.2.0.2 and for some platforms also 11.2.0.3 available. Could you also please make sure you use the latest release?

ORA-28500 Oracle 11g Gateway problem

Hi,
I have installed Oracle database 11g and configured Oracle Gateway 11g on Linux operating system.
I have created a database link through which i access data from SQL Server. By this below command,
select * from tablename@sqlserver; Where sqlserver is the db link.
It fetches the data but after some time connection automatically breaks and displayed below error message.
ERROR:
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
ORA-02063: preceding line from SQLSERVER
Below is the log file
SQLFetch: row: 100, column 3, bflsz: 41, bflar: 23, (bfl: 23, mbl: 40)
SQLFetch: row: 100, column 4, bflsz: 16, bflar: -1
SQLFetch: row: 100, column 4, bflsz: 16, bflar: SQL_NULL_DATA
SQLFetch: row: 100, column 5, bflsz: 16, bflar: 16
SQLFetch: row: 100, column 5, bflsz: 16, bflar: 16, (bfl: 16, mbl: 16)
SQLFetch: row: 100, column 6, bflsz: 4, bflar: 2
SQLFetch: row: 100, column 6, bflsz: 4, bflar: 2, (bfl: 2, mbl: 3)
SQLFetch: row: 100, column 7, bflsz: 2, bflar: 2
SQLFetch: row: 100, column 7, bflsz: 2, bflar: 2, (bfl: 2, mbl: 2)
SQLFetch: row: 100, column 8, bflsz: 2, bflar: 2
SQLFetch: row: 100, column 8, bflsz: 2, bflar: 2, (bfl: 2, mbl: 2)
SQLFetch: row: 100, column 9, bflsz: 4, bflar: 4
SQLFetch: row: 100, column 9, bflsz: 4, bflar: 4, (bfl: 4, mbl: 4)
+100 rows fetched+
Exiting hgoftch, rc=0 at 2011/10/11-09:09:50
Entered hgoftch, cursor id 1 at 2011/10/11-09:09:50
hgoftch, line 130: Printing hoada @ 0x10b55db0
MAX:9, ACTUAL:9, BRC:100, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x200:TREAT_AS_CHAR)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
+4 INTEGER N 4 4 0/ 0 0 0 0 IsrCode+
+4 INTEGER Y 4 4 0/ 0 0 0 0 ParIsrCode+
+12 VARCHAR Y 16 40 0/ 0 0 0 200 IsrName+
+91 DATE Y 0 16 0/ 0 0 -1 0 StartDate+
+91 DATE N 16 16 0/ 0 0 0 0 EndDate+
+12 VARCHAR Y 2 3 0/ 0 0 0 200 IsoCtry+
+5 SMALLINT Y 2 2 0/ 0 0 0 0 FyeMonth+
+5 SMALLINT Y 2 2 0/ 0 0 0 0 SIC+
+4 INTEGER Y 4 4 0/ 0 0 0 0 NAICS+
Entered hgopoer at 2011/10/11-09:09:56
hgopoer, line 233: got native error 104 and sqlstate 01000; message follows...
+[Oracle][ODBC SQL Server Driver][libssclient24]ConnectionRead (recv()). {01000,NativeErr = 104}[Oracle][ODBC SQL Server Driver][libssclient24]General network error. Check your network documentation. {08S01,NativeErr = 11}+
Exiting hgopoer, rc=0 at 2011/10/11-09:09:56
hgoftch, line 730: calling SQLFetch got sqlstate 01000
+0 rows fetched+
Exiting hgoftch, rc=28500 at 2011/10/11-09:09:56 with error ptr FILE:hgoftch.c LINE:730 FUNCTION:hgoftch() ID:Fetch resultset data
Waiting for urgent response.
Regards,
Rizi

# listener.ora Network Configuration File: /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521))
ADR_BASE_LISTENER = /u01/app/oracle
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = dg4msql)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(PROGRAM = dg4msql)
# sqlnet.ora Network Configuration File: /u01/app/oracle/product/11.2.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = /u01/app/oracle
GATEWAY Parameters
# This is a customized agent init file that contains the HS parameters
# that are needed for the Database Gateway for Microsoft SQL Server
# HS init parameters
HS_FDS_CONNECT_INFO=[]:1433//qqq
# alternate connect format is hostname/serverinstance/databasename
HS_FDS_TRACE_LEVEL=DEBUG
HS_FDS_RECOVERY_ACCOUNT=RECOVER
HS_FDS_RECOVERY_PWD=RECOVER
# custom init parameters
HS_KEEP_REMOTE_COLUMN_SIZE=LOCAL
HS_NLS_LENGTH_SEMANTICS=CHAR
HS_LANGUAGE=AMERICAN_AMERICA.WE8MSWIN1252
HS_NLS_NCHAR=UCS2

Need help in getting process form data

Hi,
We have one IT resource type definition say SSH. We have number of IT resources-abc,xyz of same type-SSH .
When user gets provisioned to this resource, then in the resource profile, we can see resource name as SSH. In the process form of SSH we can see the IT resource name -abc,xyz
Now the requirement is I need this IT resource name from process forom of SSH. I have written one java code which sends out an email to application owner when this SSH resource is revoked. But I need to show the IT resource name-abc,xyz in the email to application owners.
Can anybody help to get the process form data?
Thanks,
Kalpana.

yes, add new attribute to the process form and populate using adapter find below code
public long getITResource(String itResource) {
          long returnValue = 0;
          String methodName = "getITResource";
          try {
               tcITResourceInstanceOperationsIntf tcITResourceIntf = (tcITResourceInstanceOperationsIntf)Platform.getService(tcITResourceInstanceOperationsIntf.class);
               HashMap<String, String> map = new HashMap<String, String>();
               map.put("IT Resources.Name", itResource);
               tcResultSet resultSet = tcITResourceIntf
                         .findITResourceInstances(map);
               if (resultSet.getRowCount() <= 0) {
                    logger.error(className, methodName,
                              "Following IT Resource not fetched:" + map);
                    throw new Exception("IT Resource not fetched");
               resultSet.goToRow(0);
               logger.info(className, methodName, "ITResource determined.");
               // Got the result
               returnValue = resultSet.getLongValue("IT Resources.Key");
               tcITResourceIntf.close();
               ops.closeUtilityObject();
               return returnValue;
          } catch (Exception e) {
               logger.error(className, methodName, e.getMessage());
               return returnValue;
pass itResource name as literal in adapter. If it is 10g use tcUtilityFactory instead of Platforml.getService
--nayan

Fetching Resultset by rowid..!

Similar Messages

Maybe you are looking for