Archives of the TeradataForum

Message Posted: Sun, 24 Mar 2002 @ 07:35:20 GMT

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

I think that it's better to think of CREATEUID as containing the UserID that caused the row to be inserted.

In the case of table DBC.DBASE, the UserID who executed a CREATE DATABASE or CREATE USER would end-up in DBASE.CREATEUID. In the case of ACCESSRIGHTS, it's the person who either CREATEd an object or did a GRANT on an object. For example, if I created a table, I would get the rights on that table and ACCESSRIGHTS.CREATEUID would have my UserID for those rows.

If User DBC later GRANTed select on my table to another user, then a row would be INSERTed into table ACCESSRIGHTS for that GRANT and column ACCESSRIGHTS.CREATEUID would have the UserID for DBC.

Remember that a TVMID of '0'xb in table DBC.ACCESSRIGHTS signifies a database/user-level grant.

If a row was created before the CREATEUID column was implemented, then CREATEUID contains a NULL.

Although I really haven't been able to do any testing on it (so I'm guessing), I have a couple of theories why TVM.CREATEUID contains a '0'xb:

- It indicates a table that was created on another machine at an earlier release and then archived. Because it was created at an earlier release, TVM.CREATEUID would contain a NULL. The table was then copied to your machine from that archive. Instead of having a NULL in TVM.CREATEUID, it contains '0'xb as a result of the copy.

- The table was created on another machine and then archived. Column TVM.CREATEUID would contain the UserID of somebody on that machine. When you copied the table from the archive to your machine, the UserID in CREATEUID would be meaningless. Maybe somebody thought that '0'xb would be a good alternative.

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