Some further fiddling found a problem with 'workdate'. I've sorted that, but
it still makes no difference. :((
The values it's passing to '$sth->execute' are:
1531499623, -1516480662, 2001-5-29 00:00:00, 3, May-2001
Help!
Tim
----- Original Message -----
From: "Tim Scott" <[EMAIL PROTECTED]>
To: "Trevor Webster" <[EMAIL PROTECTED]>
Cc: "DBI Users" <[EMAIL PROTECTED]>
Sent: Wednesday, May 30, 2001 9:09 AM
Subject: Re: DBI -> Access
>
> Thanks for your input on this guys. Here's some more information which
might
> help, but I think it precludes these problems...
>
> The access database file is a file on my local hard drive to which I have
> full and complete access. I can indeed add to this very table through
Access
> itself.
>
> The PERL script is running through the Apache web server as a CGI script
and
> is connecting to the Access database as 'Admin'.
>
> The operation I am doing is an insert into one table. I have enclosed ALL
of
> the DBI calls from my script (it's not a complex one !)
>
> ---------------------
> $dbh_eng = DBI->connect("dbi:ODBC:EngTest", "Admin", "admin");
> # Also tried with "" password. No change.
>
> $sth = $dbh_eng->prepare(q(
> insert into WorkDone (person_id, job_id, Workdate, hours, month)
> values (?,?,?,?,?);
> )) ||
> splat "Failed to prepare insert";
>
> {{ snip - lines not referencing $dbh_eng or $sth }}
>
> $sth->execute($bod, $jobs[$i], $workdate, $hours[$i], $month)
> || splat "Failed to insert\n";
>
> {{ snip - lines not referencing $dbh_eng or $sth }}
>
> eval { $sth->finish; };
> eval { undef $$sth; }; # otherwise I get an error in the webserver log
file
>
> $dbh_eng->disconnect();
> ---------------------
>
> The WorkDone table has two referntial constraints enforced which are
valid.
> I have tried disabling them (and they still are) but it had no effect.
>
> The table is owned by Admin who has select, insert, update and delete
> privileges.
>
> Please let me know if any more information would help.
>
> Thanks,
> Tim
>
> >From: [EMAIL PROTECTED]
> >Date: Tue, 29 May 2001 12:51:25 -0400
> >
> >This is an MS Access problem, and has nothing to do with DBI. Read the
> Access
> >documentation about updatable queries.
> >
> >In general, when a query results from certain types of joins, Access
> doesn't
> >know how to allow updates to the resultset; I think it has something to
do
> with
> >how they do record locking. I'm sure Oracle supports row-level record
> locks and
> >generally handles the situation better, so it was able to support what
> you're
> >doing. DBI can't solve the problem. You can probably accomplish what
you
> need
> >to while still using Access, if you break up your operation into smaller
> >queries, or only update one table at a time.
> >
> >HTH.
> >
> >Wes
>
> ----- Original Message -----
> From: "Trevor Webster" <[EMAIL PROTECTED]>
> To: "Tim Scott" <[EMAIL PROTECTED]>
> Sent: Wednesday, May 30, 2001 7:46 AM
> Subject: Re: DBI -> Access
>
>
> > Tim
> >
> > I had a similar problem when I first started using DBI-ODBC. After
> > consulting with the DBI-users I found that the problem was associated
not
> > with DBI nor Access but with permissions on the sub-directory in which
the
> > database was located. Make sure that the directory structure has
> read/write
> > permissions throughout and this should, touch wood, solve your problem.
> >
> > Cheers Trevor
> >
> > ----- Original Message -----
> > From: "Tim Scott" <[EMAIL PROTECTED]>
> > To: "DBI Users" <[EMAIL PROTECTED]>
> > Sent: Tuesday, May 29, 2001 5:16 PM
> > Subject: DBI -> Access
> >
> >
> > > All,
> > >
> > > New to Access I'm finding:-
> > > [Microsoft][ODBC Microsoft Access Driver] Operation must use an
> updateable
> > > query. (SQL-S1000)(DBD: st_execute/SQLExecute err=-1)
> > >
> > > And thinking "how do I tell it that it's an updateable query?"
> > >
> > > The same sort of thing worked fine with Oracle...
> > >
> > > Any help appreciated.
> > >
> > > Thanks,
> > > Tim
> > >
> > > The information transmitted in this electronic mail message may
contain
> > > confidential and or privileged materials. For full details and
> > restrictions
> > > see http://www.fdgroup.com/emaildisclaimer.html
> > >
> >
> >
>
>
