Re: Foxpro, Oracle cascading update triggers

A copy of this was sent to Ray Auger <rauger_at_centurysystems.net> (if that email address didn't require changing) On Thu, 02 Dec 1999 12:09:41 -0500, you wrote:

>I am having some problems with Foxpro accessing
>ORACLE 8 properly. Here are the versions of
>software I am running:
>
>- Foxpro version 6 (installed from Visual Studio 6 CD)
>- Oracle 8.0.04 on NT
>- Development PC operating system 95 and NT workstation
> (2 seperate PC's both with same results)
>
>I have a reasonably simple Oracle database (20 or so tables)
>some with cascading update triggers. So through Oracle
>(SQL Plus) I am able to update a primary key value in a
>parent table, and the correct rows in the children table
>get updated properly.
>
>I have also built a quick screen in Powerbuilder via ODBC
>and updated the primary key value in the parent table, and
>again the correct rows in the children tables get updated
>properly.
>
>I then define a 'connection' in Foxpro that points to the
>same ODBC profile I am using above. I create several remote
>views (via the connection I defined) to the parent and child
>tables. I attempt to update a primary key value in the parent
>table (remote view) using both browse screens and Froms.
>This should force the Oracle cascading update trigger to
>be executed' IT DOES NOT !
>
>Instead I get a Foxpro error 'UPDATE ERROR' every time.
>
>I have "UPDATE" SQL checked in the view painter, NOT
>delete/insert.
>
>Has anyone had similiar problems access Oracle, I believe that
>Foxpro is either ignoring the Oracle triggers or somehow ignoring
>them.
>

foxpro (or anything else) cannot 'ignore' a trigger. that would defeat the purpose of triggers. foxpro is not ignoring them, there is some other error.

If you cannot get the oracle error message from foxpro, I suggest you issue:

alter session set sql_trace=true;

in the session from the foxpro app before you do the update. this will turn on server side tracing of SQL. the trace files will go into the directory specified by the init.ora parameter user_dump_destination. Do the update and then look at the bottom of that trace file for the update statement -- you'll see the real true statement that foxpro is sending to the database -- that statement will be wrong in some way. at least from there you'll know where to go.

>Any help would be greatly appreciated.
>
>Dave Pylatuk
>davep_at_centurysystems.net

--
See http://osi.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'... Current article is "Part I of V, Autonomous Transactions" updated June 21'st  

Thomas Kyte                   tkyte_at_us.oracle.com
Oracle Service Industries     Reston, VA   USA

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Thu Dec 02 1999 - 11:35:39 CST