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.
Alan
Ian Summers wrote:
> Hi
>
> Have you tried running this in Win NT. I've had similar problems and I
> don't think that there is a solution - but it works ok on Win 95 and Win NT
> but not Win 98 and 2000. I've got a machine with Win XP but haven't had a
> chance to try it.
>
> Good luck and I'd love to know what the problem is - no one so far on this
> list has responded to this problem.
>
> Ian
>
> Your original message:
>
> I've spent some time looking at the archives and couldn't find anything
> that really addresses this. Sorry if I missed something.
>
> I need to grab some data from a Visual Foxpro database sitting on a
> remote disk. Here's my set up:
>
> Windows 2000 5.00, SP2
> Perl 5.6.1
> DBI 1.20
> DBD-ODBC 0.28
> ODBC 3.52
> MS Visual Foxpro Driver 6.01
>
> When I run the code below, everything works fine until I try to fetch
> the third row. At that point, Windows gives an error saying that Perl
> has committed an access violation. I have verified everything else and
> even the first few iterations of the fetch work. I can't figure out what
> could cause this.
>
> When I tried putting a trace on it (right before the fetch), it doesn't
> include any more information, which makes me think that it's maybe a
> problem with one of the ODBC components rather than the script...? Or
> maybe I'm missing something?
>
> I should also note that I can use the same DSN to run the same queries
> from WinSQL without a problem.
>
> .....
