Archives of the TeradataForum

Message Posted: Mon, 26 Jun 2000 @ 12:15:09 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

We have experimented this problem at our site last year and the only way to resolve it was to bypass the accessrights system and dropped the records associated in the DBC tables.

DWGSC have a procedure to do that, the if you open an incident, they will work with you to resolv your problem.

To explain you a little bit the procedure, he steps to delete all the traces of this table is:

1) execute some "filer" command to obtain tableid (you have to work with tableid instead of tablename) and verify that all VAMP have no trace of the table:

Filer command: tableid "donne.tserv_rend_acte_gard"

     Response:
      The table id for DONNE.TSERV_REND_ACTE_GARD is
      0x0000 0x0D5A 0x0000  ( 0 3418 0 )

     Filer ==>
     table/c 0 0d5a * *

     Command has been sent to Slave tasks.

     vproc  0 (0000)  response

Didn't find any subtables on this VAMP to satisfy the search criteria and a reponse like that for all vproc in your system.

2) In BTEQ, the command to bypass rights:

Diagnostic "bypass rights" on for session;

3) and all the delete command on the DBC tables:

     delete  dbc.accessrights
     where  tvmid = '00005a0d0000'xb;
     delete  dbc.indexes
     where   tableid = '00005a0d0000'xb
         and databaseid = '0000f103'xb;
     delete  dbc.tvfields
     where   tableid = '00005a0d0000'xb;
     delete  dbc.tvm
     where   tvmname = 'tserv_rend_acte_gard'
         and databaseid = '0000f103'xb;
     delete  dbc.dbcassociation
     where   databaseid = '0000f103'xb and
         tvmid = '00005a0d0000'xb;

Pay attention with these commands. You could crash the system if you delete wrong rows.

Hope this information can help,

Claude Lachance
RAMQ system administrator

	<Prev	Next>		<<First	<Prev	Next>	Last>>