MORE INFORMATION
If you want to use JBuilder to create
applications that communicate with SQL Server 2005, we highly recommend that you use the
simple Web Services Description
Language (WSDL) document instead of the default (extended) WSDL document. You can retrieve the
simple WSDL document by including the "?wsdlsimple" query
string at the end of the URL. For example, the following URL retrieves the
simple WSDL document:
http://MySqlServer/endpoint?wsdlsimple
SQL
Server 2005 requires correct Microsoft Windows NT authentication before the WSDL document
can be retrieved. For JBuilder to import the WSDL document, you may have to retrieve the WSDL document and then save the WSDL document
as a file or as a Web page.
Most of
the following issues occur when the default WSDL setting is used together with HTTP SOAP endpoints. This default
(extended) WSDL information is returned when the query value of "wsdl" is used
in the URL query string to retrieve the WSDL for an HTTP SOAP endpoint. For
example, the following URL query string includes this query
value:
http://MySqlServer/endpointPath?wsdl
This default WSDL query frequently returns extended SQL type information that
the JBuilder client cannot fully translate.
SqlRowSet schema definition
For JBuilder to correctly parse the default (extended)
WSDL document that SQL Server 2005 generates, you may have to modify the
XSD schema definition for the complex type that is named
SqlRowSet. The XSD schema
definition that SQL Server 2005 generates appears as the following code.
<xsd:complexType name="SqlRowSet">
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="xsd:schema" />
<xsd:any />
</xsd:sequence>
</xsd:complexType>
You may have to modify the
XSD schema definition to the following code for
JBuilder to correctly interpret the default (extended) WSDL document.
<xsd:complexType name="SqlRowSet">
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
Serialization issues when binary data types are imported
The class that the JBuilder WSDL importer generates for binary
data types does not serialize the binary
instance value into Base64 encoding before the class sends the binary
instance value across a network. Instead,
the class sends the bytes in the binary instance value as a single
string.
Note The binary
data types are
varbinary,
binary,
image, and
timestamp.
For example, a binary instance has byte value of the following.
0x55, 0x35
This value is encoded during the request as the following.
<param>5535</param>
This issue only occurs when the client class codes were generated from
default (extended) WSDL for an HTTP SOAP endpoint. This issue does not affect client
class codes that were generated from simple WSDL.
JBuilder client support for boolean data type values
When the client code is generated based on the default
(extended) WSDL document, the SQL
Bit type is handled by using the built-in Java
boolean data type. This data type does not support mapping of numeric
equivalent values such as 1 and 0 for values that are true/false.
To
work around this issue, use simple WSDL. The SQL
Bit type is handled as the
java.lang.Boolean data type. This data type supports mapping of numeric equivalent values such as
1 and 0 for values that are true/false.
You can also work around this issue by
modifying the generated client code to change from the built-in Java
boolean data type to the
java.lang.Boolean data type.
JBuilder client support for datetime data type values
When the client code is generated based on the default
(extended) WSDL document, the SQL
datetime data type is handled by the
java.util.Calendar class. On the request, the
java.util.Calendar class serializes SQL
datetime values into string values that are
not compliant with the
xsd:datetime type.
To work around this issue, create client code that is based on the simple WSDL document.
The JBuilder client generates a data type class that does not have any variables to hold the XML value
When the client code is generated based on the default
(extended) WSDL document, the generated class to handle a schema bounded XML
parameter has the following code.
public class _RetTypedXml_a implements java.io.Serializable {
public _RetTypedXml_a() {
}
}Notice that no variable is defined to handle the actual XML value. The following code
is a sample generated class for a non-schema bounded XML parameter.
public class Xml implements java.io.Serializable {
private org.apache.axis.message.MessageElement [] _any;
public Xml() {
}
}Notice that the code contains the
_any variable. This variable is of the
MessageElement type. The
_any variable is created to handle the XML value.
To work around this issue, use
simple WSDL. You can also work around this issue by manually updating the generated client code to include the following variable.
private org.apache.axis.message.MessageElement [] _any;
The JBuilder client does not fully support the SqlResultStream response format
When the client code is generated based on the default
(extended) WSDL document, the JBuilder client generates a class to handle the
SqlResultStream data structure. The
SqlResultStream data structure is included in the response from a stored procedure.
However, the generated class only handles the first instance of the following different types of SQL responses that can make up the
SqlResultStream data structure.
public class SqlResultStream implements java.io.Serializable {
private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlRowSet sqlRowSet;
private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlXml sqlXml;
private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlMessage.SqlMessage sqlMessage;
private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlRowCount.SqlRowCount sqlRowCount;
private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlResultCode sqlResultCode;
private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlTransaction.SqlTransaction sqlTransaction;
Therefore, if a stored procedure returns more than one
rowset (
sqlRowSet), the client can retrieve only the first rowset. The client cannot retrieve any
additional rowsets that the stored procedure may return.
To work around this issue, use
simple WSDL where the response structure from a stored procedure is a sequence of
xsd:any element declarations.
The third-party products that this article discusses are manufactured by
companies that are independent of Microsoft. Microsoft makes no warranty,
implied or otherwise, regarding the performance or reliability of these
products.