> Hi Ian,
>
> Well, since I posted this msg I have learned a bit more about the
> problem, but
> I'm just as baffled as to how to fix it or what really causes it.
>
> The main thing is that my trace command was incorrect, so I
> wasn't getting the
> information I thought I was. Once I got that working, I noticed
> that it was
> when Perl went through its last iteration of the fetch that the problem
> occurred. For instance, my query returned six rows, and on the
> seventh time
> around it got an undef row back. At this point there is some
> trace information
> I don't really understand. This is what I get:
>
> ARRAY(0x1a75234)main::(old_vis_date.pl:165): while ( $array_ref =
> $oci_hast->
> fetchrow_arrayref ) {
> DB<1>
> -> fetchrow_arrayref for DBD::ODBC::st
> (DBI::st=HASH(0x1c1bf64)~0x1a75264)
> SQLFetch rc 100
> SQLGetFunctions - supported: 1
> <- fetchrow_arrayref= undef row7 at old_vis_date.pl line 165
> <> DESTROY ignored for outer handle DBI::db=HASH(0x1c0cdb4) (inner
> DBI::db=H
> ASH(0x1c21274))
> -> DESTROY for DBD::ODBC::db (DBI::db=HASH(0x1c21274)~INNER)
> <- DESTROY= undef
> <> DESTROY ignored for outer handle DBI::st=HASH(0x1c1bf64) (inner
> DBI::st=H
> ASH(0x1a75264))
> -> DESTROY for DBD::ODBC::st (DBI::st=HASH(0x1a75264)~INNER)
> Signal SEGV: No such file or directory
>
>
> I'm thinking that the "No such file or directory" is what got
> Windows involved.
> But I'm not sure what "SQLFetch rc 100" or "SQLGetFunctions -
> supported: 1"
> means.
It means that the Fetch indicates no more data and the SQLGetFunctions
returned success for testing for SQLMoreResults. SQLMoreResults is used for
seeing if there are multiple statements within the executed statement.
Jeff
