on 11-12-2009 1:22 PM
After a system has been filled using TDMS and address tables are to be cleaned up I get a dump
DBIF_RSQL_SQL_ERROR
The workprocess trace shows
C Thu Nov 12 13:58:34 2009
C *** ERROR => fetch() of C_0198, #rec=130, rc=1, rcSQL=-3007 (POS(1) Invalid sequence of DML and DDL statements)
[dbsdbsql.cpp 1787]
C *** ERROR => FETCH on connection 0, rc=-3007 (POS(1) Invalid sequence of DML and DDL statements)
[dbslsdb.cpp 7568]
C sc_p=0x6949f90,no=198,idc_p=(nil),con=0,act=1,slen=21,smax=256,#vars=0,stmt=0x7632550,table=ADRV
C SELECT * FROM "ADRV" ;
B ***LOG BY4=> sql error -3007 performing FET on table ADRV [dbtran#4 @ 7588] [dbtran 7588 ]
B ***LOG BY0=> POS(1) Invalid sequence of DML and DDL statements [dbtran#4 @ 7588] [dbtran 7588 ]
B dbtran ERROR LOG (hdl_dbsl_error): DbSl 'FET'
B RSLT: {dbsl=99, tran=1}
B FHDR: {tab='ADRV', fcode=225, mode=2, bpb=0, dbcnt=350610, crsr=1,
B hold=1, keep=1, xfer=0, pkg=0, upto=0, init:b=0,
B init:p=(nil), init:#=336, wa:p=0x66dd620, wa:#=336}
B dbtran ERROR LOG (hdl_dbsl_error): DbSl 'FET'
B STMT: {stmt:#=996, bndfld:#=0, prop=0x2, distinct=1, select*=0,
B fld:#=0, alias:p=0x3e496c0, fupd:#=4, tab:#=49074, where:#=357,
B groupby:#=27612, having:#=50464, order:#=48317, primary=0, hint:#=38712}
B CRSR: {tab='ADRV', id=1, hold=1, prop=0x10000, max.in@0=0, fae:blk=9,
B con:id=0, con:vndr=1, val=0,
B key:#=3, xfer=0, xin:#=0, row:#=350610, upto=0, wa:p=0x66dd620}
A
Any idea what may cause that? I found old notes that point to update statistics estimation values but those were fixed in the latest versions.
Markus
Thank you for all the suggestion.
@Lars: I was able to solve
@Elke: The problem was indeed reproducible. The situation was as follows:
Table ADRV had an Index defined, that index was available in SE11 and also activated but the radio button for "No Index" was selected in SE11 so I couldn't activate.
After I have switched that to "Index on all databases" and used SE14 to create the index on the table the application was no more failing with that error.
The interesting thing is, that all consistency checks (both SE11 and SE14) showed everything as fine. Unfortunately I didn't check in DBStudio if the index was really there.
Markus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hallo,
do you know, if some DDL has been done in parallel to the table concerned?
Perhaps some create/drop index or alter table table for ADRV?
That could explain this behaviour.
I hope, this is not reproducable, neither in DBStudio/dbmcli, nor in the real application.
If it was reproduceable, we had to do some checks, what is going on in your system.
Therefore I hope, it is not...
Elke
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
>
> After a system has been filled using TDMS and address tables are to be cleaned up I get a dump
>
> DBIF_RSQL_SQL_ERROR
>
> The workprocess trace shows
>
> C Thu Nov 12 13:58:34 2009
> C *** ERROR => fetch() of C_0198, #rec=130, rc=1, rcSQL=-3007 (POS(1) Invalid sequence of DML and DDL statements)
> [dbsdbsql.cpp 1787]
> C *** ERROR => FETCH on connection 0, rc=-3007 (POS(1) Invalid sequence of DML and DDL statements)
> [dbslsdb.cpp 7568]
>
> Any idea what may cause that? I found old notes that point to update statistics estimation values but those were fixed in the latest versions.
>
Hi Markus,
I guess we'll need a vtrace and a support message for that.
regards,
Lars
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.