Hi.
Thanks for your reply.
It was the first half that was returned. The code calls the PEAR:DB numRows function to see how many rows are returned by the query - this is approx half of the rows inserted seconds before. The same SQL run some time later (in a different session) yielded all the rows, so I know they were inserted fine and that the 'select' sql is correct.
The code is used in a batch application, so it doesn't go near a website. The counters are stored in a log file, so we know what they were.
Worth addidng that this code has run flawlessly for years, I'm at a loss to explain why (one one single occasion) the select didn't return the data it was supposed to..
// MODULE TO INSERT THE DATA
$b2_insert_sql = "insert into mytable (id, ctfdate, //snip a whole bunch of fields// )" .
" values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,'". IS_APPROVED ."',?,?,?,?,?, ". NOT_REVERSED .", ". NOT_CHARGED_BACK .", ". NOT_REPRESENTED .",?)";
$prh_b2_insert = $db->prepare("$b2_insert_sql");
// inside a loop later //
$insert_data = array("$b2_rcd_id", "$run_ctf_date", //snip a whole bunch of fields// );
$result = $db->execute($prh_b2_insert, $insert_data)
if (!DB::isError($result)) { // keep counters for inserted txns // }
// IN A DIFFERENT MODULE (Same ORA session)
$b2_sql = "select id, matchedflag, failureflag, presentmentflag ".
"from mytable ".
"where ctfdate = '$active_date' ";
$b2_result = $db->query("$b2_sql");
$num_rows = $b2_result->numRows(); // << This counter doesn't agree with the counters above
// process each row
There is an index on the CTFDATE field.
$run_ctf_date and $active_date are the same value