468,321 Members | 1,756 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,321 developers. It's quick & easy.

problem with POSSTR

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
3 3932
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
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
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.

Similar topics

117 posts views Thread by Peter Olcott | last post: by
1 post views Thread by Mats Mohlin | last post: by
28 posts views Thread by Jon Davis | last post: by
6 posts views Thread by Ammar | last post: by
2 posts views Thread by Mike Collins | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.