By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,756 Members | 1,749 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,756 IT Pros & Developers. It's quick & easy.

problem with POSSTR

P: n/a
Hello,
I use db2 8.2.7 - and can't get the following SQL up to work:

$>db2 "select se.tag from ext.sesdr_server_ids se join adm.node no on se.tag
= no.tag where posstr (se.serial_number, no.name) 0"
SQL0132N A LIKE predicate or POSSTR scalar function is not valid because
the first operand is not a string expression or the second operand is not a
string. SQLSTATE=42824

Here are the appropriate table definitions:

$>db2 describe table ext.sesdr_server_ids

Column Type Type
name schema name Length Scale Nulls
-------------------------- --------- ------------------ -------- ----- ------
SERIAL_NUMBER SYSIBM CHARACTER 40 0 Yes
....

$>db2 describe table adm.node

Column Type Type
name schema name Length Scale Nulls
-------------------------- --------- ------------------ -------- ----- ------
NAME SYSIBM VARCHAR 192 0 Yes
....

Aug 13 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Tonkuma wrote:
It is described clearly that search-string of POSSTR have many
ristrictions in Manual for DB2 Version 8 and 9 "SQL Reference Vol.1"
or Info. Center
http://publib.boulder.ibm.com/infoce...w/v9/index.jsp
Reference ---SQL ---Functions ---Scalar functions ---POSSTR.

search-string
An expression that specifies the string that is to be searched for.
The expression can be specified by any one of:

- A constant
- A special register
- A host variable
- A scalar function whose operands are any of the above
- An expression concatenating any of the above
- An SQL procedure parameter
All those essentially mean that the exact value must be known during compile
time of the SQL statement and cannot be dynamic, i.e. derived from another
column.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Aug 15 '07 #2

P: n/a
Knut Stolze wrote:
>
All those essentially mean that the exact value must be known during compile
time of the SQL statement and cannot be dynamic, i.e. derived from another
column.
This is the explanation, I needed to realize the problem.

Thanks Knut:-)
--
Toralf
Aug 15 '07 #3

P: n/a
Toralf Förster wrote:
Knut Stolze wrote:
>>
All those essentially mean that the exact value must be known during
compile time of the SQL statement and cannot be dynamic, i.e. derived
from another column.
This is the explanation, I needed to realize the problem.
Yeah, if you know that basic rule, it's obvious why exactly those
limitations were listed. Coming from the limitations is a bit more
difficult to understand the "why". ;-)

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Aug 16 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.