Re: Truncate not working

From: Bill Beaton <beatonb_at_stat239.cadvision.com>
Date: 1996/06/08
Message-ID: <4pag30$q3a_at_elmo.cadvision.com>#1/1


In article <4p5c56$s4s_at_charnel.ecst.csuchico.edu>,

        kelfink_at_ecst.csuchico.edu (Kevin Fries) writes:
>In article <31B5A8E9.3A51_at_cam.ac.uk>, Charles Jardine <cj10_at_cam.ac.uk> wrote:
>>bwskiles_at_adpc.purdue.edu wrote:
>>>
>>> There's a table, COMPLETE.PAYROLL, and a user, OPERATIONS, that needs to truncate
>>> the table. OPERATIONS has been granted the DELETE ANY TABLE system privilege
>>> by SYS, and also has insert, select, update, delete rights to the table.
>
>It's a bug in both. A "truncate" is effectively a "drop", with a re-create
>after it. You'll notice a similar problem if you have ANY foreign keys

Be careful in how you phrase this. It is sort of like you stated, EXCEPT:

  1. all grants remain in the system.
  2. all indices remain valid, and are also unpopulated.
  3. all views remain valid, and don't need to be compiled.
  4. all references in procedures, functions, packages and triggers remain valid.

>depending on the primary key of your COMPLETE.PAYROLL table. You can only
>truncate a table which could otherwise be dropped. Oracle returns an
>erroneous message in such cases, saying that no "ENABLED" foreign keys can be
>present, if you want to truncate. In fact, no FK constraints at all can
>exist.

Actually, some constraints can simply be disabled. The key issue is that the normal CASCADE capability doesn't exist with truncate, and it is for this reason that constraints must normally be disabled (altho FK absolutely must be dropped) Received on Sat Jun 08 1996 - 00:00:00 CEST

Original text of this message