releasenotes.html

SAP ERP的二次开发

       The method <tt>JCO.Structure.toXML()</tt> threw an <tt>ArrayIndexOutOfBoundsException</tt>
       if the <tt>JCO.Structure</tt> object was previously filled by using its <tt>copyFrom()</tt>
       method with a source record based on the same metadata. The data transmission to the backend
       was not affected by this bug.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix in JCO.Table.toString()</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        The method <tt>JCO.Table.toString()</tt> threw an <tt>IndexOutOfBoundsException</tt> if
        the table contained only one unnamed column (vector).
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix in JCO.Client.connect()</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        The method <tt>JCO.Client.connect()</tt> ignored the <tt>jco.client.codepage</tt>
        property for doing correct codepage conversions of the various logon parameters. This
        led to an <tt>RFC_ERROR_LOGON_FAILURE</tt> if some codepage specific national characters
        were used within any logon parameter.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>New codepages supported</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        The SAP codepages 1180 (Latin-1 with transliteration from Latin-2), 1900 (Baltic)
        and 8700 (Arabic) are additionally supported now.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix in internal codepage converter</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        The internal codepage converter truncated the last character of a string when JCo
        received data from a multi byte character codepage backend system and the last character
        of a field was a non-ASCII single byte character (e.g. Japanese halfwidth Katakana letters).
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Release Notes 2.1.1</SPAN></td></tr>
<tr><td valign="top" align="left"><HR class="separator" noshade></td></tr>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>New API JCO.Table.ensureBufferCapacity(int)</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        With the new API <tt>JCO.Table.ensureBufferCapacity(int)</tt> it is now possible to
        increase the internal table buffer size for future row appends and so avoid unneccessary
        memory reallocations in the table buffer. This API has no effect on the filled rows and
        the row cursor.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Improvement in JCO.Repository</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        <tt>JCO.Repository</tt> now tries to reestablish its client connection if an
        <tt>RFC_ERROR_COMMUNICATION</tt> or <tt>RFC_ERROR_APPLICATION_EXCEPTION</tt> occurred
        within a repository query. If succesful, it will then repeat the desired query once
        leading to more reliability in case the connection problems are only temporary.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Modified SAP codepage converter tables</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        All internal codepage converter tables have been adapted to convert the slightly modified
        SAP system codepages correctly <em>(please see SAP note
        <a href="http://service.sap.com/~form/sapnet?_FRAME=CONTAINER&_OBJECT=012006153200000553352003">634911</a>
        for more information).</em>
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix in JCo XML writer</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        <tt>JCO.Record.writeXML(Writer, ...)</tt> failed with an <tt>ArrayIndexOutOfBoundsException</tt>,
        if the size of an element was larger than 1024 bytes.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix in JCO.Record.copyFrom()</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        After calling the <tt>copyFrom()</tt> method on a <tt>JCO.Structure</tt> instance,
        future calls of other methods of this instance may result in an
        <tt>ArrayIndexOutOfBoundsException</tt>.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix in JCO.Record.equals()</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        The method <tt>JCO.Record.equals()</tt> could have returned <tt>false</tt> by mistake
        if the compared records contained complex parameters.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix for treatment of states in JCO.Server</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        The treatment of states in the class <tt>JCO.Server</tt> was fixed.<br>
        A new state being assigned while the server was processing its <tt>handleRequest()</tt>
        method may have been overwritten and therefore had no effect.<br>
        A <tt>JCO.Server</tt> that has been suspended could not be resumed/restarted again.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix for logon procedure</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        Depending on the used Java Runtime Environment the logon to a SAP system
        could have failed with an <tt>RFC_ERROR_LOGON_FAILURE</tt> if the user ID
        or the password contained some special national characters like
        '&szlig;' (german sharp s).
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfix in internal codepage converter</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        The internal codepage converter truncated the last character of a string when JCo was used
        to transfer IDocs with the SAP Java Connector IDoc Class Library to a multi byte character
        codepage backend system.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Bugfixes avoiding crashes in native part</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        A crash in the JCo native part occurred if a customer implementation of a <tt>JCO.Server</tt>
        threw an exception without a message text from the methods <tt>onCheckTID()</tt>,
        <tt>onConfirmTID()</tt>, <tt>onCommit()</tt> or <tt>onRollback()</tt>.<p>
        With enabled tracing a crash in the JCo native part occurred, if an application threw
        a Java exception with a message text larger than 6KB from <tt>JCO.Server.handleRequest()</tt>.<p>
        A crash in the JCo native part could occur, if a customer implementation of a <tt>JCO.Server</tt>
        used a static repository containing non unicode metadata and the backend system was unicode
        enabled or vice versa.<p>
        <em>This bugfix <b>only avoids</b> the crash. It is still neccessary
        to correct the repository's metadata, otherwise the transferred parameter data will be garbled.</em>
    </td></tr>
</table></div>


<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Release Notes 2.1.0</SPAN></td></tr>
<tr><td valign="top" align="left"><HR class="separator" noshade></td></tr>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Enhanced codepage conversion</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0 width="100%">
    <tr><td class="faqw">
        JCo now uses codepage definitions based on standard SAP codepages.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>Improved method JCO.ParameterList.setActive()</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        JCo now allows to set every table parameter as inactive if it is irrelevant for a specific
        RFC call. In older JCo versions this was only possible if the table parameter was defined as
        optional. The content of inactive table parameters won't be marshalled to JCo's native layer
        and their content won't be sent to the backend system thus increasing the performance of
        the appropriate RFC request.
    </td></tr>
</table></div>

<tr><td valign="top" align="left">&nbsp;</td></tr>
<tr><td valign="top" align="left"><SPAN class=head>DSR Support</SPAN></td></tr>
<tr><td valign="top" align="left">
<div class="textblack"><table cellSpacing=0 cellPadding=2 border=0>
    <tr><td class="faqw">
        DSR (Distributed Statistic Records) is a new feature allowing the creation and storage of
        all-embracing statistical and trace data in a centralized, synchronized and standardized manner
        in an SAP monitoring system.<br>
        Prerequisites for using this feature: The Java archive <tt>jdsr.jar</tt> must be
        installed on the system and included in the <tt>CLASSPATH</tt>.<br>
        The methods <tt>JCO.Client.setDsrPassport(...)</tt> and <tt>JCO.Client.getDsrPassport()</tt>
        have been added for accessing the DSR passport.<br>
        DSR records will be written, if the additional JCo property <tt>jco.jdsr</tt> is set to 1.<p>
    </td></tr>
</table></div>

<!-- ################################################################################ -->
</table></td> <!-- ### WORK AREA END                                              ### -->
<!-- ################################################################################ -->

</td></tr></table>
</tr></table>
</td></tr></table>
</body>
</html>