Look at comments below.
-----Original Message-----
From: Tim Scott
To: Trevor Webster
Cc: DBI Users
Sent: 05/30/2001 2: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; };
->The below should not give you an error, and you should do undef $sth, not
undef $$sth, $sth points to the statement handle object and is not a scalar
reference, so why are you dereferencing?
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.
-> Make sure ODBC driver has update privelleges for that DSN.
->Also as was mentioned before this is not really a DBI problem, but rather
Access/ODBC. DBI just connects to ODBC and passes it DSN, username,
password, and then submits queries.
Ilya Sterin
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
> >
>
>
