It turns out that my problem was different versions of the Oracle client. The server runs Oracle 8.1.5 and the working applications runs the 8.1.5 client, but the machine on which it fails has the 8.1.7 client.
All the same, I would have expected it to work with the newer client. I noticed that the trace from the newer client doesn't appear to show OCI-level debugging, so maybe there's something else funny with the client installation. The attached logfiles were generated executing the same codebase on the two win2k machines with trace level 9. I'm going to continue investigating my client installation for potential causes, but I already know that calling the same stored proc thru other means works fine. --Rob Meyer > -----Original Message----- > From: Tim Bunce [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 11, 2002 6:13 AM > To: Meyer, Rob > Cc: '[EMAIL PROTECTED]' > Subject: Re: error: DBD: odescr failed > > > Send the relevant part of trace() output (from prepare thru to error). > > Tim. > > On Wed, Jul 10, 2002 at 02:57:10PM -0700, Meyer, Rob wrote: > > I am experiencing an error when executing a stored proc on > an Oracle8i > > database. The details are extensive, so please, bear with me. > > > > I am using the latest versions of DBI (1.23) and > DBD-Oracle8 (1.06), Oracle > > 8.1.5, and three different machines, as follows: > > > > a) Win2000 Server, running ActivePerl build 631 (5.6.1) > > b) WinNT Server, running ActivePerl build 623 (5.6.0) > > c) Win2000 Server, running ActivePerl build 623 > > > > An application that has been working just fine on WinNT for > several months > > needs to be tested on Win2000, because the business has > decided to phase out > > WinNT. Computer a is my own desktop; b is an unchanged > server running the > > application; and c is a fresh install of Win2000, with the > application > > installed on it exactly like on b. > > > > The application logs into the database as a user with > limited privileges. > > It calls a stored procedure that has a ref cursor for an > output parameter. > > All the database objects involved are not part of the > application's user's > > schema, and should remain hidden from that user. > > > > On computers b and c, the application runs fine. On a, > which uses a newer > > version of Perl, the application produces this error when > calling the stored > > procedure: > > > > ORA-00942: table or view does not exist (DBD: odescr failed) > > > > If I extend the application's db user account's privileges, > the error > > disappears. However, I don't want to give this db user > those privileges, > > particularly when they weren't necessary before. Moreover, > the same account > > can successfully execute the procedure in SQLPlus. The > only difference that > > I can see is the newer version of Perl, which I need to > upgrade along with > > the operating system. > > > > What's going on? What can I do to fix it? Does this question more > > appropriately belong on the perl-win32 mailing list? What > does 'DBD: odescr > > failed' mean? > > > > TIA, > > > > ________________________________ > > Rob Meyer > > >
trace_win2k_fail.log
Description: Binary data
trace_win2k_success.log
Description: Binary data
