I'm sorry but previously command

ALTER TABLE tbl ACTIVATE NOT LOGGED INITIALLY

on table created without NOT LOGGED INITIALLY option was impossible.
Or not?

IMHO, more better give error or warning on this statement for table
created wihtout NOT LOGGED INITIALLY.

Andy

bughunter@ru wrote:[color=blue]
> I'm sorry but previously command
>
> ALTER TABLE tbl ACTIVATE NOT LOGGED INITIALLY
>
> on table created without NOT LOGGED INITIALLY option was impossible.
> Or not?
>
> IMHO, more better give error or warning on this statement for table
> created wihtout NOT LOGGED INITIALLY.[/color]
You are correct that this used to be teh case.
However to perform such an alter you need at leats control over the
table and the amount of damage that can be done is no bigger (or
smaller) than using a LOAD REPLACE with empty table.
So there was really no point in an error.
Warnings in my experience get either ignored by customers or treated
like error....

Either way, it is what it is now. There is no going back.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

I'm customer too and don't ignore any warnings :-) But I was very
surprised when a some numbers of table was in inconsistence state after
restore from online backup. And it was very important tables. Yes, it
was a bug in my script - I made mistake in schema name. But no way to
detect this sutiation. For example, I can detect tables with not logged
property and can use this attribute to avoid sutiation with lost
table/data after restore from online backup. Currently this property is
not useful :-(.

Another question - how detect inconsistence tables after restore?

Andy

bughunter@ru wrote:[color=blue]
> I'm customer too and don't ignore any warnings :-) But I was very
> surprised when a some numbers of table was in inconsistence state after
> restore from online backup. And it was very important tables. Yes, it
> was a bug in my script - I made mistake in schema name. But no way to
> detect this sutiation. For example, I can detect tables with not logged
> property and can use this attribute to avoid sutiation with lost
> table/data after restore from online backup. Currently this property is
> not useful :-(.
>
> Another question - how detect inconsistence tables after restore?
>[/color]

Dont know whether restore is a special case, but status is normally
what I look for

select tabschema, tabname, status from syscat.tables where status <>
'N'


/Lennart

Status = 'N'. I have no idea how found a tables with

[IBM][CLI Driver][DB2/NT] SQL1477N Table "LOADING.ACCNTAB" cannot be
accessed. SQLSTATE=55019

Only one method - create script with select from all tables

select 'select 1 from ' || CREATOR ||'.'||name||' fetch first row
only;'
from SYSIBM.SYSTABLES
where creator not like 'SYS%' and type = 'T'
;

then run and check. But for db with more 1K tables it's a very long
process.

2ibm team - what's do you think? Why are you change a normal working
ability?
More better do storing a original text (format) for
view/trigger/function.

Andy