cancel
Showing results for 
Search instead for 
Did you mean: 

7.7.07.09: DBIF_RSQL_SQL_ERROR - SQL Error -3007

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (3)

Answers (3)

markus_doehr2
Active Contributor
0 Kudos

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

Former Member
0 Kudos

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

lbreddemann
Active Contributor
0 Kudos

>

> 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