In Axional Studio, the user ResultSet cache is delegated to the JDBC pool. This means that the ResultSet cache does not belongs to user but to pool.

In old webstudio servers, the temporary table management was distributed accross the application and it was handled by many components.

In Axional Server, JDBCConnectionWrapper is responsible of temp table management using JDBCTemp class.

The connection will automatically handle the name of the temp table and will keep track of tables created and deleted during the borrow/free operation.

[... The create table instructions tracked are ...]
    
    SELECT ... INTO TEMP @tmp
    CREATE TEMP TABLE @tmp
    CREATE GLOBAL TEMPORARY TABLE @tmp
    DECLARE GLOBAL TEMPORARY TABLE @tmp
    
    [...The drop table isntructions tracked are ...]
    
    DROP TABLE @tmp

The temp tables are automatically dropped when the connection is returned to the pool, unless the pool keeps open statements (indirectly a ResultSets), as those statements may have open cursors over them.

In that cases, the JDBCTemp manager is transfered to the last open statement that will fire the drop tables when it's finally closed.

For this version the user manager is a registrered user in the wic_user table at the wic_conf database . Nevertheless there are only few fields that are retrieved from this table, while the rest of the configuration is automatic or it exists in the configuration file.

The fields retrieved from the wic_user configuration are:

• password
• language
• mail address
• timezone
• date format

Next table shows the fields that are not used by the new version but that still exist, to keep the compatibility.

The next list shows the tags that will be deprecated in the new version.

• error.message2
• error.sqlcode2
• error.sqlstate2
• system.server.getBuildDate
• system.server.getBuildInfo
• system.server.getBuildVersion
• system.server.getJDKVersio
• system.server.getReleaseChangeSets
• connection.releaseTemporayTables
• webapp.getSVG

In the new version some previous features have been disabled or else they are used in a different way.

The service to execute queries and XSQL-Scripts from javascript code has been disabled in the new version. This feature is modified due security reasons, as far as this service allowed to execute any query without restrictions. The new implementation is doing by catalogue the queries, that the user can do in the dictionary metadata (wic) database. Adopting this way, there is not option in the javascript to execute queries. Moreover the user can only execute catalogued sentences by a programmer.

However, in order to maintain the compatibility until all preexisting code will have been passed to the dictionary metadata database, it exists a Startup parameter allowing to enable this feature.

The javascript function ColumnInspector is also deprecated and it doesn't works in the new version. To implements this feature, columns must be configured in the "Related columns" on "Events" form.

Historically, when there was a function named check_{colname} this function was executed before an Insert or Update operation. In case this function returned false the operation was prevented. From now onwards, this logic could be implement through the [before_update] and [before_insert] form events, so the funcionallity check_{colname} is not supported anymore.

The transformation of query screen and output of SQL Objects by XSL is no longer used. The fields

• rep_2xsl_qry
• rep_2xsl_out

defined in the wic_jrep_object are deprecated and they are not used in the new version.

As the new object rendering arquitecture does not load the object code as source code, but gets it asynchronously via Ajax communication, the static references to fields, parent fields, etc. cannot be used within the object Javascript code. That is detailed in next tables:

• wic_jrep_form_data: Javascript of formulary.
• wic_jrep_form_cols: Javascript of columns.

So, there is a guide for changing static references by Javascriptscrip user functions:

• #colname, becomes getFieldValue(colname)
• #parent(colname), becomes getParentFieldValue(colname)
• $VARNAME, becomes getVariableValue(varname)
• $PARENT, becomes getParentCode()
• $USER, becomes getUser()
• $DBMS, becomes getDbms()
• #istrue(caninput), becomes canInput()
• #istrue(rowselected), becomes isRowSelected()
• #istrue(parentselected), becomes getParentCode() != null

function gcompedh_getmask() {
    ...
    var newser = getQueryValue(
        JSQL_MakeXSQLScriptCall(
            "gsermask_get_docser",
            "PC",
            #tipdoc,
            #empcode,
        ),
    	true
    );
    ...

function gcompedh_getmask() {
    ...
    var newser = getQueryValue(
        JSQL_MakeXSQLScriptCall(
            "gsermask_get_docser",
            "PC",
            getFieldValue("tipdoc"),
            getFieldValue("empcode"),
        ),
    	true
    );
    ...

function after_codart() {
    ...
    if (#parent(numdoc) == 0)
        setFieldValue("gcompedh.numefe", "EF-");
    ...

function after_codart() {
    ...
    if (getParentFieldValue("numdoc")) == 0)
        setFieldValue("gcompedh.numefe", "EF-");
    ...

function document_reset() {
    ...
    if (#istrue(rowselected))
        setFieldNoentry("gcompedh.tipdoc");
    ...

function document_reset() {
    ...
    if (isRowSelected())
        setFieldNoentry("gcompedh.tipdoc");
    ...

function after_docori() {
    ...
    if ($ORDERNUM > 0)
        setFieldValue("gcompedh.order", $ORDERNUM);
    ...

function after_docori() {
    ...
    if (getVariableValue("ORDERNUM") > 0)
        setFieldValue("gcompedh.order", getVariableValue("ORDERNUM"));
    ...

function after_docori() {
    ...
    if ('$DOCSER' != '')
        setFieldValue("gcompedh.order", $ORDERNUM);
    ...

function after_docori() {
    ...
    if (getVariableValue("DOCSER") != '')
        setFieldValue("gcompedh.order", getVariableValue("ORDERNUM"));
    ...

function after_docori() {
    ...
    if ('$PARENT' == 'gcompedh')
        setFieldValue("gcompedh.order", $ORDERNUM);
    ...

function after_docori() {
    ...
    if (getParentCode == 'gcompedh')
        setFieldValue("gcompedh.order", getVariableValue("ORDERNUM"));
    ...

Those columns retrieved in the object statement and defined as output columns, which table naming corresponded to the main table inthe statement, were traditionally all them sent to the server, when executing a transaction, even those which were not appended to the form.
This functionallity allowed the programmer to obtain certain column values on the client side because these columns and their values were propagated to the transaction, despite this is not a best practice. So, from now onwards, any value that can be calculated and cannot be modified by the user, must be calculated on the server side.

For this reason, this functionallity has been disabled. So, when executing a transaction only the fields used in the form are sent.
Some fields calculated in the before insert javascript form events which containted the mentioned funcionallity should be calculated in the before insert Transaction Manager instead of.

• setGlobalMapping

To allow asynchronous page rendering, JSP should be replaced by automatic rendering using the integrated template engine.

• Replace JSP javascript by static javascript in body form functions.
• Replace Taglib use of sqljsobj by a catalog globals SQL.
• Replace loop iterations to build data structures by XSQL functions.
• Switch JSP flag to template to allow asynchronous rendering.

The columns for storing password values used to have attributes defined with a "default value" calculation. For example, the password field in the users table (wic_user.user_pass) used to have a default value (on the attributes form) equals to "digest(pass_column)", so the calculation was MD5(pass_column), where the "pass_column" is the name of the form field with the password value.

The "digest" function is no longer available, for any attribute default value. The following alternatives can be used:

• obf(pass_column): reversible obfuscation
• md5(pass_column): non-reversible standard MD5 hash function
• md5ha1(pass_column|user_column): calculation of the HA1 part of the digest algorithm (RFC 2617). Computed as MD5(user_column:realm:pass_column).
• crypt(pass_column): own Axional reversible encryption.

The release delivers a new execution type Execute and refresh cursor within the form buttons; and consequently this changes the functionallity of the Execute and refresh type.

Previously to this evolution, the execution type Execute and refresh always refreshed the adapter cursor and it kept the previous position, after the button execution. This caused that, in case of the button execution modified the rows of the cursor, then after execution the user could be provided with a different row.

So, in order to fix the previous issues, the functionality of Execute and refresh is changed; now it only refreshes the data of the current row, rather than the whole cursor.
Furthemore, to avoid lossing funcionatlities, a new execution type (Execute and refresh cursor) is defined. This, refreshes the whole cursor but, unlike the old way, after the execution the cursor is positioned always on the first position.

The fact that the button results move to the first position, could be oddfull for the user, but it is better than lossing control about what row it would be shown, that happended before. In any case, the use of the new execution type Execute and refresh cursor must be seldomly used, there are a few examples of its use:

• The Copy button, which execution inserts a new row in the main table.
• Multirow forms, where the visible data is altered by the button execution.

Links on reports, forms and SQL-Tables will now be opened in the same window by default. The allowed values for the field "target" in the link definition forms are the following:

• Default (did not exist on previous versions)
• New window
• Modal window
• Modal and reload

To maintain compatibility between versions, you can set parameters at the startup to initiate or no some services.

The service srv_jqry is deprecated by security reasons. So the javascript function getQueryValue is no longer used. To maintain the compatibility and use this service is necessary starts the JVM with the flag

-Ddeister.webstudio.core.servlet.app_jrep_jqry.enable=true

Is possible to use this service throughout the variable JAVA_AXIONAL_FLAGS in the shell start.sh (or studio.sh).

JAVA_AXIONAL_FLAGS="-Ddeister.webstudio.core.servlet.app_jrep_jqry.enable=true"

The following flags are still handled (for compatibility) but they should be specified as Java flags (instead as being in the deprecated webstudio-config.xml file).

• -Ddeister.webstudio.core.jsql.jrep.print2list.JRepProducerToXLS_HTML.disableNumericDates=false
• -Ddeister.webstudio.core.xsql.script.XSQLScriptRunner.defaultStackSize=100
• -Ddeister.webstudio.core.xsql.script.XSQLScriptRunner.maxStatementsCache=500
• -Ddeister.webstudio.core.xsql.xml2sql.xsql2sql.forceOracleAnsi=false

JAVA_AXIONAL_FLAGS="-Ddeister.webstudio.core.servlet.app_jrep_jqry.enable=true"