Archives of the TeradataForum
Message Posted: Mon, 26 Jun 2000 @ 12:15:09 GMT
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,
|Copyright 2016 - All Rights Reserved|
|Last Modified: 28 Jun 2020|