Exception JZ0P8 RSMDA Column Type Name you requested is unknown
Luc Van der Veurst
After upgrading our ASE to 12.5 ESD7 (from 12.5 ESD5) and upgrading
jconnect to EBF 13252, our weblogic application gets the following
error :
java.sql.SQLException: JZ0P8: The RSMDA Column Type Name you requested
is unknow
n. This is a Sybase internal error; please report it to technical
support.
at
com.sybase.jdbc2.jdbc.ErrorMessage.raiseError(ErrorMessage.java:569)
at com.sybase.jdbc2.tds.Tds.getColumnTypeName(Tds.java:3802)
at
com.sybase.jdbc2.tds.RowFormatToken.getColumnTypeName(RowFormatToken.
java:695)
at
weblogic.jdbc.wrapper.ResultSetMetaData_com_sybase_jdbc2_tds_RowForma
tToken.getColumnTypeName(Unknown Source)
at
com.sun.rowset.CachedRowSetImpl.initMetaData(CachedRowSetImpl.java:55
6)
at
com.sun.rowset.CachedRowSetImpl.populate(CachedRowSetImpl.java:465)
at
...
The solved buglist of the jconnect ebf contains :
13252 417539 jConnect: For User-defined datatypes, the
DatabaseMetadata.getColumns(TYPE_NAME) returns the
underlying native datatype name and not the User-
defined datatype name.
So I suppose the problem is related to this 'bug'.
Did anyone encountered the same problem and/or what is the solution
to solve this ?
Thanks,
Luc.
Jonathan Baker [Sybase]
Jonathan
Luc Van der Veurst wrote:
> Hello,
>
> After upgrading our ASE to 12.5 ESD7 (from 12.5 ESD5) and upgrading
> jconnect to EBF 13252, our weblogic application gets the following
> error :
>
> java.sql.SQLException: JZ0P8: The RSMDA Column Type Name you requested
> is unknow
> n. This is a Sybase internal error; please report it to technical
> support.
> at
> com.sybase.jdbc2.jdbc.ErrorMessage.raiseError(ErrorMessage.java:569)
> at com.sybase.jdbc2.tds.Tds.getColumnTypeName(Tds.java:3802)
> at
> com.sybase.jdbc2.tds.RowFormatToken.getColumnTypeName(RowFormatToken.
> java:695)
> at
> weblogic.jdbc.wrapper.ResultSetMetaData_com_sybase_jdbc2_tds_RowForma
> tToken.getColumnTypeName(Unknown Source)
> at
> com.sun.rowset.CachedRowSetImpl.initMetaData(CachedRowSetImpl.java:55
> 6)
> at
> com.sun.rowset.CachedRowSetImpl.populate(CachedRowSetImpl.java:465)
> at
> ....
Luc Van der Veurst
> Call technical support.
I will.
Further investigation shows that the problem occurs when you select
a column in a database different than the current one and the
type of the column does not exist in the current database.
Luc.
J
<dba_...@hotmail.com> wrote:
I logged a bug on this a while ago, CR 386560. You might want to
queue up a support case for its resolution as the problem is still
open. This was the workaround:
"Define the UDTs in the model database before creating the user
database. Essentially, the UDT is then in every database"
Jay
Luc Van der Veurst
upgrade our test and production servers because of this
problem).
I opened a case with sybase (number 11298347).
I find Sybase's workaround rather symplistic. As if
you start with an empty server.
And I don't believe it will work correctly if you don't
create the types in the same order in all databases so
that they get the same usertype number. And if you
already have completely different types with the same
usertype value in different databases, jconnect just
receives eroneous information from ASE.
It seems that Sybase and the usergroup community
don't see this problem as a big issue. Are there not
many weblogic servers running on ASE ?
Or is there a way to change weblogic's behaviour so
that it doesn't ask ASE for this information ?
Thanks,
Luc.
"J" <jtotall...@sbcglobal.net> wrote in message
news:449985d3...@forums.sybase.com...
Luc Van der Veurst
Sybase isn't planning on fixing this bug in a reasonable timeframe. Before
fixing it, another CR has to be implemented and this one is scheduled for
ASE 16.x. CR 386560 isn't scheduled for a release right now.
The cause of the problem is a change in the TDS information about columns
that ASE sends back to the client. It now sends back the internal number of
the user defined type (where it used to send back the internal number of the
base type), but it doesn't tell the client in which database this type can
be found, so when jconnect asks the name of the type, ASE can't answer that
question and tries to return the name of the UDT of the type with the same
type number in the current database.
That's why the workaround is : "Define the UDTs in the model database before
creating the user database. Essentially, the UDT is then in every database"
That workaround is a laugh of course, it would work on an empty system and
if you create new types in all existing databases at the same time and in
the same order. We already have 207 databases (not in one server :-)), and
357 UDTs accross those databases.
If you use sp_addtype to add types to a database, the same type number will
be in use by different types in different databases. So making the type
numbers identifical for all types in all databases can be quite some work
with dropping tables, dropping types, adding types, create the tables again
when types have the 'universal' type number, etc....
I tried to find other customers affected by this bug in the weblogic
newsgroups, but didn't get a response. I'm wondering if the number of
customers using Weblogic/JConnect/ASE is low, or if we are using a WL
feature not used by others.
Sybase asks for a business case giving an estimate of the costs we have
because of this bug. So if others are also affected by this bug, perhaps we
can bundle our efforts.
What bothers me the most is that it's difficult to get the bug fixed while
Sybase can't provide any information about the reeason why they made the
change that introduced the bug. If they don't know anymore why they changed
it, then why not return to the old behaviour ?
I have now another workaround running in our test system which made it
possible to upgrade to ASE 12.5.4 ESD#4. It's running for a week now,
without giving more jconnect errors. I'll post the solution we use in the
ASE general newsgroup.
Luc.
"J" <jtotall...@sbcglobal.net> wrote in message
news:449985d3...@forums.sybase.com...
Luc Van der Veurst
Sybase isn't planning on fixing this bug in a reasonable timeframe. Before
fixing it, another CR has to be implemented and this one is scheduled for
ASE 16.x. CR 386560 isn't scheduled for a release right now.
The cause of the problem is a change in the TDS information about columns
that ASE sends back to the client. It now sends back the internal number of
the user defined type (where it used to send back the internal number of the
base type), but it doesn't tell the client in which database this type can
be found, so when jconnect asks the name of the type, ASE can't answer that
question and tries to return the name of the UDT of the type with the same
type number in the current database.
That's why the workaround is : "Define the UDTs in the model database before
creating the user database. Essentially, the UDT is then in every database"
That workaround is a laugh of course, it would work on an empty system and
Luc.
Luc Van der Veurst
Sybase isn't planning on fixing this bug in a reasonable timeframe. Before
fixing it, another CR has to be implemented and this one is scheduled for
ASE 16.x. CR 386560 isn't scheduled for a release right now.
The cause of the problem is a change in the TDS information about columns
that ASE sends back to the client. It now sends back the internal number of
the user defined type (where it used to send back the internal number of the
base type), but it doesn't tell the client in which database this type can
be found, so when jconnect asks the name of the type, ASE can't answer that
question and tries to return the name of the UDT of the type with the same
type number in the current database.
That's why the workaround is : "Define the UDTs in the model database before
creating the user database. Essentially, the UDT is then in every database"
That workaround is a laugh of course, it would work on an empty system and
Luc.