Any equivalent to setSQLstate and setSQLmessage in DB2JAVA UDFs?

[Rhino]

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

[Sean McKeough]

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.

[Rhino]

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 IllegalArgumentException 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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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 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.

[Sean McKeough]

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 IllegalArgumentException 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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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
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]

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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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
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 IllegalArgumentException 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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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

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'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
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.

[Sean McKeough]

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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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
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 IllegalArgumentException 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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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
>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]

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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.net...

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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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
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 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 IllegalArgumentException 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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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
>>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.

[Sean McKeough]

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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.net...

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******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.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
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 IllegalArgumentException 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******@nospam.ibm.com> wrote in message
>news:42********@news3.prserv.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
>
>
>
>>>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.
>
>
>