473,574 Members | 3,159 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Any equivalent to setSQLstate and setSQLmessage in DB2JAVA UDFs?

I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested in the
manuals for DB2 Version 8 but I'm having problems with setSQLstate() and
setSQLmessage() . If I'm reading the manuals correctly, they are only
supported in UDFs that use DB2GENERAL. Is that right?

If it is, is there any equivalent to these methods for DB2JAVA UDFs? I'd
really like to be able to return a message and SQLState of my own choosing.
(I know that I can't choose *any* SQLState that I want but I'm happy to
choose from the range of SQLStates that are permitted.)

---

Aside: I have to admit I'm a puzzled about why IBM is apparently pushing us
to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to have
scratchpads, get used for table UDFs, access DBINFO, etc. Can we expect
DB2JAVA UDFs to have the same capabilities as DB2GENERAL UDFs in the
relatively near future? I don't mind converting my UDFs to DB2JAVA but I'd
like to convert them _all_ and not lose any functionality in the process.

--
Rhino
---
rhino1 AT sympatico DOT ca
"There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies." - C.A.R.
Hoare
Nov 12 '05 #1
7 1573
Parm style java is a standard parm style across all versions of db2, as
well as anyone supporting sqlj part 1 programming styles. This means
that any java sp you write in this parm style is portable to any other
system. The downside is it also means you lose the nice add ons specific
to db2 such as the scratchpad, setting sqlstate, etc...

Rhino wrote:
I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested in the
manuals for DB2 Version 8 but I'm having problems with setSQLstate() and
setSQLmessage() . If I'm reading the manuals correctly, they are only
supported in UDFs that use DB2GENERAL. Is that right?

If it is, is there any equivalent to these methods for DB2JAVA UDFs? I'd
really like to be able to return a message and SQLState of my own choosing.
(I know that I can't choose *any* SQLState that I want but I'm happy to
choose from the range of SQLStates that are permitted.)

---

Aside: I have to admit I'm a puzzled about why IBM is apparently pushing us
to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to have
scratchpads, get used for table UDFs, access DBINFO, etc. Can we expect
DB2JAVA UDFs to have the same capabilities as DB2GENERAL UDFs in the
relatively near future? I don't mind converting my UDFs to DB2JAVA but I'd
like to convert them _all_ and not lose any functionality in the process.

Nov 12 '05 #2
Portability is certainly nice and I like any solution that gives it to me.
But I like functionality too. Is there any possibility of having *both*?
Obviously, DB2JAVA doesn't give us that today but is IBM working towards
giving us the functionality of DB2GENERAL stored procedures and UDFs in
future versions of DB2, such as Version 9? I'm not asking for a
carved-in-stone promise with availability dates and the ability to sue for
non-delivery, I'm just wondering if IBM is working in this direction and
there is a reasonable possibility that it might happen by Version 9 or maybe
Version 10. I'd really like to be able to see that a DB2JAVA stored
procedure or UDF can do everything that a DB2GENERAL one can do in another
year or two.

Moving from the "big picture" to the specific, what is the preferred way of
doing error handling in DB2JAVA UDFs? Of all the JDBC examples in the
manuals, only one is DB2JAVA and it does no error handling at all, aside
from stating that it throws Exception. I'm really not sure how to structure
my program well when I use a DB2JAVA parameter style. I'm inclined to throw
an IllegalArgument Exception when the user gives invalid input parameters but
I'm not sure how to handle any other problems that might occur during the
life of my stored proc or UDF.

Any guidance you could give me on this point would be greatly appreciated!

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
Parm style java is a standard parm style across all versions of db2, as
well as anyone supporting sqlj part 1 programming styles. This means
that any java sp you write in this parm style is portable to any other
system. The downside is it also means you lose the nice add ons specific
to db2 such as the scratchpad, setting sqlstate, etc...

Rhino wrote:
I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested in the manuals for DB2 Version 8 but I'm having problems with setSQLstate() and setSQLmessage() . If I'm reading the manuals correctly, they are only
supported in UDFs that use DB2GENERAL. Is that right?

If it is, is there any equivalent to these methods for DB2JAVA UDFs? I'd
really like to be able to return a message and SQLState of my own choosing. (I know that I can't choose *any* SQLState that I want but I'm happy to
choose from the range of SQLStates that are permitted.)

---

Aside: I have to admit I'm a puzzled about why IBM is apparently pushing us to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to have
scratchpads, get used for table UDFs, access DBINFO, etc. Can we expect
DB2JAVA UDFs to have the same capabilities as DB2GENERAL UDFs in the
relatively near future? I don't mind converting my UDFs to DB2JAVA but I'd like to convert them _all_ and not lose any functionality in the process.

Nov 12 '05 #3
The 'problem' with standards, is that they're well...standard . Unless
the sqlj standard changed to incorporate the elements you're talking
about, we wouldn't extend it in a non standard way (defeats the
purpose). I don't know if there's any work being done to extend the sqlj
standard stuff to incorporate the elements you're talking about (I
suspect there is not).

I'm not really a java sp developer (just know how the engine
infrastructure works), so I can't comment on best practices for error
handling (hopefully Knut or someone with more experience can give you
their opinion).

Rhino wrote:
Portability is certainly nice and I like any solution that gives it to me.
But I like functionality too. Is there any possibility of having *both*?
Obviously, DB2JAVA doesn't give us that today but is IBM working towards
giving us the functionality of DB2GENERAL stored procedures and UDFs in
future versions of DB2, such as Version 9? I'm not asking for a
carved-in-stone promise with availability dates and the ability to sue for
non-delivery, I'm just wondering if IBM is working in this direction and
there is a reasonable possibility that it might happen by Version 9 or maybe
Version 10. I'd really like to be able to see that a DB2JAVA stored
procedure or UDF can do everything that a DB2GENERAL one can do in another
year or two.

Moving from the "big picture" to the specific, what is the preferred way of
doing error handling in DB2JAVA UDFs? Of all the JDBC examples in the
manuals, only one is DB2JAVA and it does no error handling at all, aside
from stating that it throws Exception. I'm really not sure how to structure
my program well when I use a DB2JAVA parameter style. I'm inclined to throw
an IllegalArgument Exception when the user gives invalid input parameters but
I'm not sure how to handle any other problems that might occur during the
life of my stored proc or UDF.

Any guidance you could give me on this point would be greatly appreciated!

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
Parm style java is a standard parm style across all versions of db2, as
well as anyone supporting sqlj part 1 programming styles. This means
that any java sp you write in this parm style is portable to any other
system. The downside is it also means you lose the nice add ons specific
to db2 such as the scratchpad, setting sqlstate, etc...

Rhino wrote:
I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested in
the
manuals for DB2 Version 8 but I'm having problems with setSQLstate()
and
setSQLmessag e(). If I'm reading the manuals correctly, they are only
supported in UDFs that use DB2GENERAL. Is that right?

If it is, is there any equivalent to these methods for DB2JAVA UDFs? I'd
really like to be able to return a message and SQLState of my own
choosing.
(I know that I can't choose *any* SQLState that I want but I'm happy to
choose from the range of SQLStates that are permitted.)

---

Aside: I have to admit I'm a puzzled about why IBM is apparently pushing
us
to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to have
scratchpad s, get used for table UDFs, access DBINFO, etc. Can we expect
DB2JAVA UDFs to have the same capabilities as DB2GENERAL UDFs in the
relatively near future? I don't mind converting my UDFs to DB2JAVA but
I'd
like to convert them _all_ and not lose any functionality in the


process.

Nov 12 '05 #4
So we probably shouldn't hold our breaths that DB2JAVA UDFs will have the
full capabilities of DB2GENERAL UDFs any time soon? Ok, fair enough. That
helps me decide whether to convert my UDFs to the DB2JAVA style.

But the fact that DB2JAVA UDFs can't do many things that a DB2GENERAL UDF
can do and the distinct possibility (probability?) that IBM isn't going to
enhance DB2JAVA capabilities to match DB2GENERAL capabilities certainly
undermines the strong recommendation in the manuals that people move to the
DB2JAVA parameter style. So does the relative scarcity of DB2JAVA examples
in those manuals; I only found one very simple example of a DB2JAVA UDF in
all of the JDBC examples.

I'm surprised to see your remark that IBM is unlikely to extend the
capability of DB2JAVA UDFs beyond what's in the standard. It's always been
my impression that all vendors of computer-related products are willing and
maybe eager to give extensions to standards if their customers appear to
need or want those extensions.

Is there a recent trend in the industry as a whole to supply products that
support only the standards and nothing more? This approach would go a long
way to reducing the differences between products. For example, if DB2 and MS
SQL products complied to the exact same standards, nothing more and nothing
less, there would be less to differentiate between the two and it would be
harder to persuade a potential customer to go with one rather than the
other. While this might make life a bit easier for DBAs and designers, I
imagine it would give the marketing people conniptions; what arguments would
they use to persuade you that DB2 is a better choice than MS SQL or Oracle
or whatever?

I realize that you aren't in a position where you are influencing this sort
of 'big picture' issue; you're only passing on your sense the direction
things are taking. I'm just expressing my discomfort with a possible
insensitivity on the part of IBM to the desire for more functionality *as
well as* standards compliance whenever possible.

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
The 'problem' with standards, is that they're well...standard . Unless
the sqlj standard changed to incorporate the elements you're talking
about, we wouldn't extend it in a non standard way (defeats the
purpose). I don't know if there's any work being done to extend the sqlj
standard stuff to incorporate the elements you're talking about (I
suspect there is not).

I'm not really a java sp developer (just know how the engine
infrastructure works), so I can't comment on best practices for error
handling (hopefully Knut or someone with more experience can give you
their opinion).

Rhino wrote:
Portability is certainly nice and I like any solution that gives it to me. But I like functionality too. Is there any possibility of having *both*?
Obviously, DB2JAVA doesn't give us that today but is IBM working towards
giving us the functionality of DB2GENERAL stored procedures and UDFs in
future versions of DB2, such as Version 9? I'm not asking for a
carved-in-stone promise with availability dates and the ability to sue for non-delivery, I'm just wondering if IBM is working in this direction and
there is a reasonable possibility that it might happen by Version 9 or maybe Version 10. I'd really like to be able to see that a DB2JAVA stored
procedure or UDF can do everything that a DB2GENERAL one can do in another year or two.

Moving from the "big picture" to the specific, what is the preferred way of doing error handling in DB2JAVA UDFs? Of all the JDBC examples in the
manuals, only one is DB2JAVA and it does no error handling at all, aside
from stating that it throws Exception. I'm really not sure how to structure my program well when I use a DB2JAVA parameter style. I'm inclined to throw an IllegalArgument Exception when the user gives invalid input parameters but I'm not sure how to handle any other problems that might occur during the life of my stored proc or UDF.

Any guidance you could give me on this point would be greatly appreciated!
Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
Parm style java is a standard parm style across all versions of db2, as
well as anyone supporting sqlj part 1 programming styles. This means
that any java sp you write in this parm style is portable to any other
system. The downside is it also means you lose the nice add ons specific
to db2 such as the scratchpad, setting sqlstate, etc...

Rhino wrote:

I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested in


the
manuals for DB2 Version 8 but I'm having problems with setSQLstate()


and
setSQLmessag e(). If I'm reading the manuals correctly, they are only
supported in UDFs that use DB2GENERAL. Is that right?

If it is, is there any equivalent to these methods for DB2JAVA UDFs? I'dreally like to be able to return a message and SQLState of my own


choosing.
(I know that I can't choose *any* SQLState that I want but I'm happy to
choose from the range of SQLStates that are permitted.)

---

Aside: I have to admit I'm a puzzled about why IBM is apparently
pushing
us
to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to have
scratchpad s, get used for table UDFs, access DBINFO, etc. Can we expect
DB2JAVA UDFs to have the same capabilities as DB2GENERAL UDFs in the
relatively near future? I don't mind converting my UDFs to DB2JAVA but


I'd
like to convert them _all_ and not lose any functionality in the


process.

Nov 12 '05 #5
I hear you...I've passed along your concerns. We'll see what happens.

Rhino wrote:
So we probably shouldn't hold our breaths that DB2JAVA UDFs will have the
full capabilities of DB2GENERAL UDFs any time soon? Ok, fair enough. That
helps me decide whether to convert my UDFs to the DB2JAVA style.

But the fact that DB2JAVA UDFs can't do many things that a DB2GENERAL UDF
can do and the distinct possibility (probability?) that IBM isn't going to
enhance DB2JAVA capabilities to match DB2GENERAL capabilities certainly
undermines the strong recommendation in the manuals that people move to the
DB2JAVA parameter style. So does the relative scarcity of DB2JAVA examples
in those manuals; I only found one very simple example of a DB2JAVA UDF in
all of the JDBC examples.

I'm surprised to see your remark that IBM is unlikely to extend the
capability of DB2JAVA UDFs beyond what's in the standard. It's always been
my impression that all vendors of computer-related products are willing and
maybe eager to give extensions to standards if their customers appear to
need or want those extensions.

Is there a recent trend in the industry as a whole to supply products that
support only the standards and nothing more? This approach would go a long
way to reducing the differences between products. For example, if DB2 and MS
SQL products complied to the exact same standards, nothing more and nothing
less, there would be less to differentiate between the two and it would be
harder to persuade a potential customer to go with one rather than the
other. While this might make life a bit easier for DBAs and designers, I
imagine it would give the marketing people conniptions; what arguments would
they use to persuade you that DB2 is a better choice than MS SQL or Oracle
or whatever?

I realize that you aren't in a position where you are influencing this sort
of 'big picture' issue; you're only passing on your sense the direction
things are taking. I'm just expressing my discomfort with a possible
insensitivity on the part of IBM to the desire for more functionality *as
well as* standards compliance whenever possible.

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
The 'problem' with standards, is that they're well...standard . Unless
the sqlj standard changed to incorporate the elements you're talking
about, we wouldn't extend it in a non standard way (defeats the
purpose). I don't know if there's any work being done to extend the sqlj
standard stuff to incorporate the elements you're talking about (I
suspect there is not).

I'm not really a java sp developer (just know how the engine
infrastructur e works), so I can't comment on best practices for error
handling (hopefully Knut or someone with more experience can give you
their opinion).

Rhino wrote:
Portabilit y is certainly nice and I like any solution that gives it to
me.
But I like functionality too. Is there any possibility of having *both*?
Obviously, DB2JAVA doesn't give us that today but is IBM working towards
giving us the functionality of DB2GENERAL stored procedures and UDFs in
future versions of DB2, such as Version 9? I'm not asking for a
carved-in-stone promise with availability dates and the ability to sue
for
non-delivery, I'm just wondering if IBM is working in this direction and
there is a reasonable possibility that it might happen by Version 9 or
maybe
Version 10. I'd really like to be able to see that a DB2JAVA stored
procedure or UDF can do everything that a DB2GENERAL one can do in
another
year or two.

Moving from the "big picture" to the specific, what is the preferred way
of
doing error handling in DB2JAVA UDFs? Of all the JDBC examples in the
manuals, only one is DB2JAVA and it does no error handling at all, aside
from stating that it throws Exception. I'm really not sure how to
structure
my program well when I use a DB2JAVA parameter style. I'm inclined to
throw
an IllegalArgument Exception when the user gives invalid input parameters
but
I'm not sure how to handle any other problems that might occur during
the
life of my stored proc or UDF.

Any guidance you could give me on this point would be greatly
appreciated!
Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42***** ***@news3.prser v.net...
Parm style java is a standard parm style across all versions of db2, as
well as anyone supporting sqlj part 1 programming styles. This means
that any java sp you write in this parm style is portable to any other
system. The downside is it also means you lose the nice add ons specific
to db2 such as the scratchpad, setting sqlstate, etc...

Rhino wrote:
>I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested in

the
>manuals for DB2 Version 8 but I'm having problems with setSQLstate()

and
>setSQLmess age(). If I'm reading the manuals correctly, they are only
>supporte d in UDFs that use DB2GENERAL. Is that right?
>
>If it is, is there any equivalent to these methods for DB2JAVA UDFs?
I'd
really like to be able to return a message and SQLState of my own

choosing.
>(I know that I can't choose *any* SQLState that I want but I'm happy to
>choose from the range of SQLStates that are permitted.)
>
>---
>
>Aside: I have to admit I'm a puzzled about why IBM is apparently
pushing
us
>to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to have
>scratchpad s, get used for table UDFs, access DBINFO, etc. Can we expect
>DB2JAVA UDFs to have the same capabilities as DB2GENERAL UDFs in the
>relative ly near future? I don't mind converting my UDFs to DB2JAVA but

I'd
>like to convert them _all_ and not lose any functionality in the

process.


Nov 12 '05 #6
Thanks Sean, much appreciated!

Maybe I'm the only one who thinks that DB2JAVA UDFs and stored procs should
be capable of everything that their DB2GENERAL brothers can do but I'd be
surprised.

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
I hear you...I've passed along your concerns. We'll see what happens.

Rhino wrote:
So we probably shouldn't hold our breaths that DB2JAVA UDFs will have the full capabilities of DB2GENERAL UDFs any time soon? Ok, fair enough. That helps me decide whether to convert my UDFs to the DB2JAVA style.

But the fact that DB2JAVA UDFs can't do many things that a DB2GENERAL UDF can do and the distinct possibility (probability?) that IBM isn't going to enhance DB2JAVA capabilities to match DB2GENERAL capabilities certainly
undermines the strong recommendation in the manuals that people move to the DB2JAVA parameter style. So does the relative scarcity of DB2JAVA examples in those manuals; I only found one very simple example of a DB2JAVA UDF in all of the JDBC examples.

I'm surprised to see your remark that IBM is unlikely to extend the
capability of DB2JAVA UDFs beyond what's in the standard. It's always been my impression that all vendors of computer-related products are willing and maybe eager to give extensions to standards if their customers appear to
need or want those extensions.

Is there a recent trend in the industry as a whole to supply products that support only the standards and nothing more? This approach would go a long way to reducing the differences between products. For example, if DB2 and MS SQL products complied to the exact same standards, nothing more and nothing less, there would be less to differentiate between the two and it would be harder to persuade a potential customer to go with one rather than the
other. While this might make life a bit easier for DBAs and designers, I
imagine it would give the marketing people conniptions; what arguments would they use to persuade you that DB2 is a better choice than MS SQL or Oracle or whatever?

I realize that you aren't in a position where you are influencing this sort of 'big picture' issue; you're only passing on your sense the direction
things are taking. I'm just expressing my discomfort with a possible
insensitivity on the part of IBM to the desire for more functionality *as well as* standards compliance whenever possible.

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
The 'problem' with standards, is that they're well...standard . Unless
the sqlj standard changed to incorporate the elements you're talking
about, we wouldn't extend it in a non standard way (defeats the
purpose). I don't know if there's any work being done to extend the sqlj
standard stuff to incorporate the elements you're talking about (I
suspect there is not).

I'm not really a java sp developer (just know how the engine
infrastructur e works), so I can't comment on best practices for error
handling (hopefully Knut or someone with more experience can give you
their opinion).

Rhino wrote:

Portabilit y is certainly nice and I like any solution that gives it to


me.
But I like functionality too. Is there any possibility of having *both*?Obviously, DB2JAVA doesn't give us that today but is IBM working towardsgiving us the functionality of DB2GENERAL stored procedures and UDFs in
future versions of DB2, such as Version 9? I'm not asking for a
carved-in-stone promise with availability dates and the ability to sue


for
non-delivery, I'm just wondering if IBM is working in this direction andthere is a reasonable possibility that it might happen by Version 9 or


maybe
Version 10. I'd really like to be able to see that a DB2JAVA stored
procedure or UDF can do everything that a DB2GENERAL one can do in


another
year or two.

Moving from the "big picture" to the specific, what is the preferred way

of
doing error handling in DB2JAVA UDFs? Of all the JDBC examples in the
manuals, only one is DB2JAVA and it does no error handling at all,
asidefrom stating that it throws Exception. I'm really not sure how to


structure
my program well when I use a DB2JAVA parameter style. I'm inclined to


throw
an IllegalArgument Exception when the user gives invalid input parameters
but
I'm not sure how to handle any other problems that might occur during


the
life of my stored proc or UDF.

Any guidance you could give me on this point would be greatly


appreciated!
Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42***** ***@news3.prser v.net...
>Parm style java is a standard parm style across all versions of db2,

as>well as anyone supporting sqlj part 1 programming styles. This means
>that any java sp you write in this parm style is portable to any other
>system. The downside is it also means you lose the nice add ons specific>to db2 such as the scratchpad, setting sqlstate, etc...
>
>Rhino wrote:
>
>
>>I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested in
the
>>manuals for DB2 Version 8 but I'm having problems with setSQLstate()

and
>>setSQLmess age(). If I'm reading the manuals correctly, they are only
>>supporte d in UDFs that use DB2GENERAL. Is that right?
>>
>>If it is, is there any equivalent to these methods for DB2JAVA UDFs?


I'd
>>really like to be able to return a message and SQLState of my own

choosing.
>>(I know that I can't choose *any* SQLState that I want but I'm happy to>>choose from the range of SQLStates that are permitted.)
>>
>>---
>>
>>Aside: I have to admit I'm a puzzled about why IBM is apparently


pushing
us
>>to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to have>>scratchpad s, get used for table UDFs, access DBINFO, etc. Can we expect>>DB2JAVA UDFs to have the same capabilities as DB2GENERAL UDFs in the
>>relative ly near future? I don't mind converting my UDFs to DB2JAVA but
I'd
>>like to convert them _all_ and not lose any functionality in the

process.


Nov 12 '05 #7
We're looking at adding another parameter style (variation of parm style
java) but in the meantime you'll be stuck with general...no promises
about when the new parm style might be done since this isn't in any plan
at this point.

Rhino wrote:
Thanks Sean, much appreciated!

Maybe I'm the only one who thinks that DB2JAVA UDFs and stored procs should
be capable of everything that their DB2GENERAL brothers can do but I'd be
surprised.

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42******** @news3.prserv.n et...
I hear you...I've passed along your concerns. We'll see what happens.

Rhino wrote:
So we probably shouldn't hold our breaths that DB2JAVA UDFs will have
the
full capabilities of DB2GENERAL UDFs any time soon? Ok, fair enough.
That
helps me decide whether to convert my UDFs to the DB2JAVA style.

But the fact that DB2JAVA UDFs can't do many things that a DB2GENERAL
UDF
can do and the distinct possibility (probability?) that IBM isn't going
to
enhance DB2JAVA capabilities to match DB2GENERAL capabilities certainly
undermines the strong recommendation in the manuals that people move to
the
DB2JAVA parameter style. So does the relative scarcity of DB2JAVA
examples
in those manuals; I only found one very simple example of a DB2JAVA UDF
in
all of the JDBC examples.

I'm surprised to see your remark that IBM is unlikely to extend the
capability of DB2JAVA UDFs beyond what's in the standard. It's always
been
my impression that all vendors of computer-related products are willing
and
maybe eager to give extensions to standards if their customers appear to
need or want those extensions.

Is there a recent trend in the industry as a whole to supply products
that
support only the standards and nothing more? This approach would go a
long
way to reducing the differences between products. For example, if DB2
and MS
SQL products complied to the exact same standards, nothing more and
nothing
less, there would be less to differentiate between the two and it would
be
harder to persuade a potential customer to go with one rather than the
other. While this might make life a bit easier for DBAs and designers, I
imagine it would give the marketing people conniptions; what arguments
would
they use to persuade you that DB2 is a better choice than MS SQL or
Oracle
or whatever?

I realize that you aren't in a position where you are influencing this
sort
of 'big picture' issue; you're only passing on your sense the direction
things are taking. I'm just expressing my discomfort with a possible
insensitivit y on the part of IBM to the desire for more functionality
*as
well as* standards compliance whenever possible.

Rhino

"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
news:42***** ***@news3.prser v.net...
The 'problem' with standards, is that they're well...standard . Unless
the sqlj standard changed to incorporate the elements you're talking
about, we wouldn't extend it in a non standard way (defeats the
purpose). I don't know if there's any work being done to extend the sqlj
standard stuff to incorporate the elements you're talking about (I
suspect there is not).

I'm not really a java sp developer (just know how the engine
infrastruct ure works), so I can't comment on best practices for error
handling (hopefully Knut or someone with more experience can give you
their opinion).

Rhino wrote:
>Portabilit y is certainly nice and I like any solution that gives it to

me.
>But I like functionality too. Is there any possibility of having
*both*?
Obviousl y, DB2JAVA doesn't give us that today but is IBM working
towards
giving us the functionality of DB2GENERAL stored procedures and UDFs in
>future versions of DB2, such as Version 9? I'm not asking for a
>carved-in-stone promise with availability dates and the ability to sue

for
>non-delivery, I'm just wondering if IBM is working in this direction
and
there is a reasonable possibility that it might happen by Version 9 or

maybe
>Version 10. I'd really like to be able to see that a DB2JAVA stored
>procedur e or UDF can do everything that a DB2GENERAL one can do in

another
>year or two.
>
>Moving from the "big picture" to the specific, what is the preferred
way
of
>doing error handling in DB2JAVA UDFs? Of all the JDBC examples in the
>manuals, only one is DB2JAVA and it does no error handling at all,
aside
from stating that it throws Exception. I'm really not sure how to

structure
>my program well when I use a DB2JAVA parameter style. I'm inclined to

throw
>an IllegalArgument Exception when the user gives invalid input
parameters
but
>I'm not sure how to handle any other problems that might occur during

the
>life of my stored proc or UDF.
>
>Any guidance you could give me on this point would be greatly

appreciate d!
>Rhino
>
>"Sean McKeough" <mc******@nospa m.ibm.com> wrote in message
>news:42*** *****@news3.prs erv.net...
>
>
>
>>Parm style java is a standard parm style across all versions of db2,
as
well as anyone supporting sqlj part 1 programming styles. This means
>>that any java sp you write in this parm style is portable to any other
>>system. The downside is it also means you lose the nice add ons
specific
to db2 such as the scratchpad, setting sqlstate, etc...
>>
>>Rhino wrote:
>>
>>
>>
>>>I am updating some Java UDFs from DB2GENERAL to DB2JAVA as suggested
in
the
>
>
>
>>>manual s for DB2 Version 8 but I'm having problems with setSQLstate()
>
>and
>
>
>
>>>setSQLme ssage(). If I'm reading the manuals correctly, they are only
>>>supporte d in UDFs that use DB2GENERAL. Is that right?
>>>
>>>If it is, is there any equivalent to these methods for DB2JAVA UDFs?

I'd
>>>really like to be able to return a message and SQLState of my own
>
>choosing .
>
>
>
>>>(I know that I can't choose *any* SQLState that I want but I'm happy
to
>choose from the range of SQLStates that are permitted.)
>>>
>>>---
>>>
>>>Aside: I have to admit I'm a puzzled about why IBM is apparently

pushing
>us
>
>
>
>>>to use DB2JAVA whenever possible yet doesn't allow DB2JAVA UDFs to
have
>scratchp ads, get used for table UDFs, access DBINFO, etc. Can we
expect
>DB2JAV A UDFs to have the same capabilities as DB2GENERAL UDFs in the
>>>relative ly near future? I don't mind converting my UDFs to DB2JAVA
but
I'd
>
>
>
>>>like to convert them _all_ and not lose any functionality in the
>
>process.
>
>
>


Nov 12 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
2346
by: Andrew Mayo | last post by:
There is something very strange going on here. Tested with ADO 2.7 and MSDE/2000. At first, things look quite sensible. You have a simple SQL query, let's say select * from mytab where col1 = 1234 Now, let's write a simple VB program to do this query back to an MSDE/2000 database on our local machine. Effectively, we'll
1
2428
by: Eugene | last post by:
In a DB2 V8.1 FP4 database I am trying to create a table SQL UDF that is to return a contents of a temporary table with in this UDF: create function getitemdata(pint int) returns table ( hostid smallint, owid bigint )
3
6020
by: David Carver | last post by:
We are running into a problem with a Communication Link failure when calling an External Stored procedure written in ILE Cobol from an SQL UDF. When calling the stored procedure by itself and not within the UDF it runs fine, it's only when we excute the UDF that we get the communication link failure. I have setup EXTERNAL ACTION on the the...
0
4817
by: Paolo | last post by:
hello.. does anyone know where is it possible to find java docs about classes in db2java.zip? Thanks Paolo
0
1134
by: Fan Ruo Xin | last post by:
The developer rewrote one C program. So I need to replace the current library, drop and recreate the UDFs. I don't want to restart the db server, I just terminate all the sessions which might call this UDF. The strange thing is my query: select udf(column) from mytbl still gave me the result from the old library. But, values(udf(column) show...
4
1924
by: Pete H | last post by:
Hi All; I'm trying to get some of the samples that are amply illustrated in multiple docs to work. When I try to create a Warehouse Center view "...for MQ Series messages" or use the UDF wizard in Development Center, I get the following error/warning: ------------------------------------------------------------------------- MQSeries...
5
3091
by: Gustavo Randich | last post by:
Hello, (Using DB2/LINUX 8.2.0) HOW-TO: recreate a big set of interdependent UDFs... without having to do it manually because of the imposed drop order due to the RESTRICT keyword of the DROP statement. There are also triggers and views mixed in the spaghetti. Background: I've a huge set of .sql files which acts as the master
0
1389
by: Helmut Tessarek | last post by:
Hi everybody, I've written some UDFs to generate passwords within DB2. They are compatible to the functions that are used in Apache's htpasswd utility. Maybe someone can use them. http://sourceforge.net/project/showfiles.php?group_id=103064&package_id=110695 The UDFS are
6
4843
by: Carsten | last post by:
Hello Folks, I encountered a problem with SQL server 2000 and UDFs. I have a scalar UDF and a table UDF where I would like the scalar UDF to provide the argument for the table UDF like in: SELECT * FROM
0
7841
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7760
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8101
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
1
7858
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
8137
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6511
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
0
3793
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2273
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
1099
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.