[-9404]: System error: AK System error: VAK15 3

Question

Hi,
the installation is a MaxDB 7.6.03.15 Linux 64bit
dbmcli version command outputs:
version,os,dbroot,logon,code,swap
"7.6.03","UNIX","/opt/sdb/7603",False,ASCII,2
if i drop the follow view declared as:
CREATE VIEW viewMovProduto2 AS
SELECT DECODE(nf.tipo,'E',nf.my_destinatario,'S',nf.my_emitente) my_empresa,
       DECODE(nf.tipo,'E',nf.my_emitente,'S',nf.my_destinatario) my_cliForn,
       nf.data_es data,
       nf.tipo tipo,
       nf.numero numero,
       tpmov.gera_estoque gera_estoque,
       itnf.*
       FROM NotaFiscal nf, ItemNotaFiscal itnf, TipoMovimento tpmov
       WHERE nf.my_tipo_movimento = tpmov.oid AND
             itnf.my_nota_fiscal = nf.oid
and after the drop i try to run:
ALTER TABLE ITEMNOTA ADD MY_EMPRESA VARCHAR(8)
i get the error message:
[-9404]: System error: AK System error: VAK15 3
this error occurs too if try for example:
ALTER TABLE ITEMNOTA ADD MY_TEST_COLUMN VARCHAR(8)
if i add the column MY_TEST_COLUMN before to drop the view viewMovProduto2, that add works, if i try to add the column MY_EMPRESA i get the message:
[-7057]: View definition contradicts new table definition:VIEWMOVPRODUTO2
then the problem just occurs if i remove the View, anyone know what happens?
thanks
Clóvis

Answer 1

Hi,
the vtrace was nice, but did not show the wanted commands. May I assume that you did your drop view ... and afterwards started the dbm to handle the trace? This is not the best idea. Start dbm (which does several things with the kernel which may cause overwriting the trace-area), then do those things you want to trace, then use dbm.
The other option is to increase the trace-area (increase TRACE_PAGES_US), restart the system and do things as you did before.
But in your case no further try of vtrace is needed for the moment. Internally we talked about your topic and think, that in online-mode the statement
check catalog with update
should be done. We have to assume that in your catalog a reference to a table is stored. But this table does not exist any more. In those cases where we had the chance to check in detail we had to find out, that some versions of MaxDB did not throw away all references they should have done (in some cases only, of course). With normal handling of MaxDB this does not hurt. But if you want to throw away that object where the wrong reference is stored in, then such error like yours occurs.
==> please execute that statement and re-try your sequence.
Another question:
You are able to reproduce the problem starting with a really new created database?
Would you mind changing to a newer version (>= 7.6.05) and try again?
If this problem remains (create new database, do some DDL causing this problem) we would be VERY interested in this sequence of commands. But only, if it can be found in 7.6.05 or higher version.
Regards,
  Elke