[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sapdb-general
Subject:    RE: parameter against null evaluation fails with [-7016] Paramete
From:       Joost Verhagen <Joost.Verhagen () iwise ! nl>
Date:       2001-11-28 11:49:59
[Download RAW message or body]

Hi Elke,

Tanx for this idea. This works fine and is a reasonable workaround.

> but we are (positive!) astonished that someone grabs into the
That one suprised me too!! :-)

regards,

Joost

> -----Original Message-----
> From: Zabach, Elke [mailto:elke.zabach@sap.com]
> Sent: Tuesday, November 27, 2001 2:23 PM
> To: 'Joost Verhagen'; 'sapdb-general@sap.com'
> Subject: RE: parameter against null evaluation fails with [-7016]
> Paramete r sp ec not allowed in java program
> 
> 
> Joost Verhagen wrote:
> 
> >>>>
> I have a java program which calls a simple query. In this 
> query a parameter
> is evaluated against null and if it is not it is used for further
> evaluation:
> 
> select * 
> from project 
> where ((? is not null) and ....
> 
> Although this query is standard SQL it does not seem te run 
> on SAPDB. When
> running the application the parse of the prepared statement 
> fails with:
> [-7016] Parameter spec not allowed in this context.
> 
> This poses a mayor problem for us, since this kind of query 
> is commonly
> used.
> 
> We use SAPDB Kernel 3.0.0.8 with the JDBC driver 7.3.0.19a 
> (also tested with
> prior JDBC versions).
> 
> Any help would be appreciated.
> <<<<<
> 
> 
> As some other guys said: SAP DB checks the datatype during prepare,
> therefore ? alone will not help, unfortunately.
> It is no problem of SQLMODE, it is the working together of 
> kernel and tools.
> 
> But if you put a function around which will ONLY work for the 
> datatype your
> ? will be of
> then SAP DB 'knows' by the used function which datatype to take.
> 
> For a character-variable  ?  the function   INITCAP is fine, 
> for example:
> where ((INITCAP(?) is not null) and ...
> 
> Elke 
> SAP Labs Berlin
> 
> BTW: the if-clause mentioned by Wolfram Nücker is not the problem,
>          but we are (positive!) astonished that someone grabs into the
> kernel code
>          which is in many cases much harder to understand 
> than code of some
> tools.
> 

[prev in list] [next in list] [prev in thread] [next in thread]