Sybase数据库技术，数据库恢复专家

RS16: RSE4015: Outbound enabler of backend server 'S0' in backend farm 'RSTEST02.F0' reports session error OEE_SESSION_ACCESS_FAILED(1051) with parameters 'RS_CLI_REQUEST_CONTINUE', 'disconnected at the middle of a request', '_unused_'

OE16: OEE1051: The Outbound Enabler was unable to access the session with ridx=0 sidx=0 snum=0000 sfp=01aa9daa on a RS_CLI_REQUEST_CONTINUE packet due to disconnected at the middle of a request

RS12: RSE4004: Outbound enabler of backend server 'S0' in backend farm 'MLVM-SARSX64.F0' reports session error OEE25100 with parameters '_unused_', '_unused_', '_unused_'

OE12: Session was disconnected at the middle of a packet sequence. Aborting sidx=0

The problematic sequence has been identified and a fix has been made so that the OE can handle the POST that falls into that sequence. If the traffic is RESTful, a user workaround is to turn off all affinity injection from the Relay Server using the active_cookie=no and active_header=no property in the backend_farm configuration section of the affected backend farm and clear HTTP cookies from the client after the Relay Server configuration has been updated.

A new backend_farm property called socket_level_affinity has been added for controlling the behavior in a per backend farm manner. The liberation described above is DISABLED by default (i.e. socket_level_affinity=yes is the default). Online configuration update of this property is supported.

External Requirements

Updating to this new Relay Server, with socket_level_affinity=no, doesn抰 require deploying a client to clear previous affinity cookie assigned by the Relay Server. Also, the Outbound Enabler doesn抰 need to be upgraded in order to enjoy the liberation. This is an internal behavior change which continues to require the backend servers to allow non-persistent HTTP traffic and/or broken up persistent HTTP traffic. This backend server requirement remains regardless of whether the liberation is used or not. If liberation is enabled, the backend server doesn抰 need to support or allow persistent HTTP connection.

Note that in order to apply this fix, existing version 16.0 database will need to be upgraded once the server containing the fix is deployed. New databases created with the fixed version of the server do not need to be upgraded.

-dt detect transactions only within the current database (for Microsoft SQL Server, Adaptive Server Enterprise and Oracle only)

When this option is used on the command line with Oracle, the MobiLink server will fetch the earliest starting time of the open transactions only that have modified any tables to the current database schema in the prepare_for_download phase, and then the MobiLink server will use this time that is named the next_last_download_timestamp to generate the download stream for the client in the next sync. With this option the MobiLink server may considerably reduce redundant download for any clients that use a timestamp-based download on a busy Oracle database server.

In order to use this new command line option, the user ID the MobiLink server uses to connect to the Oracle database must have a selection permission of the following global views on the Oracle database:

GV$TRANSACTION, GV$SESSION, GV$LOCKED_OBJECT

In order to repair the function in an existing database, run ALTER DATABASE UPGRADE PROCEDURE ON with an upgraded server.

For example, the following text could have been displayed:

SQLANYe_test12

As a workaround, the Details tab can be used to see the missing message for this event. This problem has now been fixed so that the Details tab will include the message, as in the following:

SQLANYe_test12: Starting service SQLANYe_test12

This has now been fixed.

As a workaround, the database files could be put in a directory containing only the database files for a single database.

IMPORTANT: These newer UltraLite clients may in rare cases cause older 16.0 MobiLink servers (prior to build 1584) to crash due to a previously undetected bug.

SQL Anywhere ADO.NET drivers without the 714707 fix may have requests fail with the error "Run time SQL error -- *** ERROR *** Assertion failed: 104909". The ADO.NET driver needs to be updated if this occurs.

- in rare, timing dependent cases, a mirror or copy node could have crashed, hung or failed assertion 102010

- when a mirror or copy node reconnected to the primary or parent, it was possible for it to not request, write or apply log pages.

- when a mirror was yielding to a preferred server, or the "ALTER DATABASE SET PARTNER FAILOVER" statement was executed on the primary, it was possible for the previous mirror to not take over as the primary (both partner servers could have had the mirror role)

These problems have been fixed.

A workaround is to re-open the profiling session after opening the Sample Range Properties window.

Note, this fix also applies to UltraLite and UltraLiteJ for Android.

The task which created this backup (BP-XXXX) could not be found.

This has been fixed.

This has been fixed so the dropped connections are less likely. Note that these errors can still correctly occur if there is a network issue or if either the client or server computers completely bog down (most likely due to limited resources).

Error in the search query "database:4" near "database:4".

Error code: -20090 (DBCLOUDERR_SEARCH_STRING)

This has been fixed.

Also, the software is now more tolerant of whitespace between keywords. For example, suppose the SQL Statements panel contained the following valid statement, spread across four lines:

CREATE

VARIABLE

retcode

INT

Clicking "Help on" in the context menu would have failed to open help because of the newlines that separate the tokens. Now, help for the CREATE VARIABLE statement will be opened.

Note, until SP4 becomes available, to enable current Clouds that have a proxy setting to take advantage of this fix, the new patch "dbcloud-fix-checkforupdates-proxy.patch" must be applied to the Cloud.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

The Content-Encoding header is used by clients to indicate the encoding of the request body. The Accept-Encoding header is used by clients to indicate the preferred encoding of the response body.

A work-around is to execute a ...

SET OPTION PUBLIC.timestamp_with_time_zone_format = 'YYYY-MM-DD HH:NN:SS.SSSSSS+HH:NN'

statement which sets the default required for all .NET connections.

This problem has been fixed.

1. When a column cannot be fetched in its entirety, set status to DBSTATUS_S_TRUNCATED instead of DBSTATUS_S_OK and length to actual length, not amount fetched.

2. IRowsetUpdate methods InsertRow/Update should insert rows in manual commit mode (i.e., commit in batches) rather than autocommit each row.

3. Improved support for DBTYPE_DBTIMESTAMPOFFSET data types.

4. In order to identify columns that are DEFAULT AUTOINCREMENT, IColumnsInfo::GetColumnInfo now sets the DBCOLUMNFLAGS_ISROWVER bit for those columns. Microsoft defines a column with this attribute as a non-writable versioning column (such as the SQL Server TIMESTAMP) which suits SQL Server. Note, however, that SQL Anywhere supports versioning columns that are writable.

5. Corrected failure to describe money/smallmoney as DBTYPE_CY (currency type). Also corrected OLE DB schema queries DBSCHEMA_COLUMNS, DBSCHEMA_PROCEDURE_COLUMNS, and DBSCHEMA_PROCEDURE_PARAMETERS results for DBTYPE_CY.

6. Corrections to schema rowset information (DBSCHEMA_COLUMNS, DBSCHEMA_PROCEDURE_COLUMNS, and DBSCHEMA_PROCEDURE_PARAMETERS) for datetime/time precision and scale.

7. Corrections to 搑un-time� information for datetime/time precision and scale.

8. Add "DATETIME" to list of DBPARAMBINDINFO.pwszDataSourceType types for SetParameterInfo (SQL Server uses this undocumented type name). Type names are usually of the form 揇BTYPE_xxx� (for example, 揇BTYPE_I4�, 揇BTYPE_STR�, 揇BTYPE_DBTIMESTAMP�).

9. Adjust GetConversionSize values for TIME, DATETIME, DATETIMEOFFSET data types (only 6 fractional digits are supported by SQL Anywhere).

10. Fixed memory leak caused by failure to free rows whose refcount is 0 in Update().

11. Fixed possible memory corruption in calls to IRowsetChange::SetData, IRowsetChange::InsertRow, ISequentialStream::Write, and IRowChange::SetColumns.

12. Fixed performance problem when DataConvert is used when no conversion is required.

13. The LoadCommand, DeleteCommand, and SaveCommand methods of the ICommandPersist interface did not qualify system tables references with an owner name. This has been corrected.

14. The OLE DB provider accepts two cbBookmark values, 1 which is the 搒hort� DBBMK_FIRST/LAST value, and 4 or 8 depending on the bitness of the provider. The 64-bit provider flags �4� was an illegal value for cbBookmark. The 32-bit provider flags �8� was an illegal value for cbBookmark. The OLE DB provider should accept both 4 and 8 as the length of a bookmark value and fetch the appropriate 32-bit/64-bit bookmark value from memory. This problem has been corrected. The fix affects IRowsetLocate::GetRowsAt, IRowsetLocate::Compare, RowsetLocate::GetRowsByBookmark, IRowsetLocate::Hash, and IRowsetScroll::GetApproximatePosition, and IRowsetExactScroll::GetExactPosition. Both 32-bit and 64-bit providers now support 4-byte and 8-byte bookmark values, in addition to 1-byte values.

Also, when the stated precision of a decimal value parameter was much less than the actual precision of a decimal value, it is possible to corrupt the heap.

parm.Precision = 5;

parm.Value = (decimal) 123456789;

These problems have now been fixed.

If, while processing ALTER DATABASE SET PARTNER FAILOVER, connections between the primary and mirror servers timed out, or were dropped, before the failover operation completed, the primary server could have stopped accepting connections.

The sa_mirror_server_status log_written offset could have been incorrect about the time a log rename occurred.

file_path long nvarchar the path of the server accessible file or directory

file_type nvarchar(1) either F for file or D for directory

file_size unsigned bigint the size of the file or NULL for directories

In order to provide more information about the various files and directories, dbo.sp_list_directory() has now been enhanced to return five additional columns. These five additional columns are:

owner nvarchar(128) the owner of the file or directory

create_date_time* timestamp with time zone the date and time the file or directory was created

modified_date_time* timestamp with time zone the date and time the file or directory was last modified

access_date_time* timestamp with time zone the date and time the file or directory was last accessed

permissions varchar(10) the set of access permissions for the file or directory

All other aspects of dbo.sp_list_directory() � including the set of system privileges and secure feature privileges � remain unchanged.

A database either has to be upgraded or initialized in order for applications to obtain this new information from dbo.sp_list_directory(). In addition, if an upgraded or newly initialized database is subsequently moved to an older version of the server, then the new columns will continue to be returned but the values of the new columns will be NULL.

- HAVING SUM( column ) <= constant

- HAVING SUM( column ) < constant

- HAVING SUM( column ) > constant

- HAVING SUM( column ) >= constant

so that incorrect selectivity could be returned in the following cases:

- the column was a number but the constant was not (e.g., it was a date).

- the comparison relation was <> or = (these can not be estimated).

- the comparison was of the form SUM(column) LIKE string_constant.

This has now been corrected.

This has been fixed. Note that this failure (database is not compatible) can still validly occur in certain cases.

ST_GEOMETRY::ST_BUFFER( distance double, unit_name long varchar )

- distance: The distance the buffer should be from the geometry value. Must be greater than or equal to 0.

- unit_name: The units in which the distance parameter should be interpreted. Defaults to the unit of the spatial reference system. The unit name must match the UNIT_NAME column of a row in the ST_UNITS_OF_MEASURE view where UNIT_TYPE is 'LINEAR'.

- Returns the ST_Geometry value representing all points within the specified distance of the original geometry.

The ST_Buffer method generates a geometry that expands a geometry by the specified distance. This method can be used, for example, to find all points in geometry A that are within a specified distance of geometry B. The distance parameter must be a positive value. This method will return an error if distance is negative. If the distance parameter is equal to 0, the original geometry is returned. The ST_Buffer method is best used only when the actual buffer geometry is required. Determining whether two geometries are within a specified distance of each other should be done using ST_WithinDistance instead.

Syntax:

READ_SERVER_FILE( filename ) [, start [ , length] ]

Parameters:

- filename LONG VARCHAR value indicating the path and name of the file on the

server.

- start The start position of the file to read, in bytes. The first byte in

the file is at position 1. A negative starting position specifies

the number of bytes from the end of the file rather than from the

beginning.

* If start is not specified, a value of 0 is used.

* If start is zero and length is non-negative, a start value of 1

is used.

* If start is zero and length is negative, a start value of -1 is

used.

- length The length of the file to read, in bytes.

* If length is not specified, the function reads from the starting

position to the end of the file.

* If length is positive, the function read ends length bytes to the

right of the starting position.

* If length is negative, the function returns at most length bytes

up to, and including, the starting position, from the left of the

starting position.

Returns:

LONG BINARY

Remarks:

This function returns the full or partial (if start and/or length are specified)

contents of the named file as a LONG BINARY value. If the file does not exist or

cannot be read, NULL is returned.

filename is relative to the starting directory of the database server.

The READ_SERVER_FILE function supports reading files larger than 2GB. However,

the returned content is limited to 2GB. If the returned content exceeds this

limit, a SQL error is returned.

If the data file is in a different character set, you can use the CSCONVERT

function to convert it. You can also use the CSCONVERT function to address the

character set conversion requirements you may have when using the

READ_SERVER_FILE server function.

If disk sandboxing is enabled, the file referenced in filename must in an

accessible location.

Privileges:

When reading from a file on a client computer:

* You must have the READ FILE system privilege.

* You must have read permissions on the directory being read from.

Standards: SQL/2008 Vendor extension.

Example:

The following statement reads 20 bytes in a file, starting from byte 100 of the

file.

SELECT READ_SERVER_FILE( 'c:\\data.txt', 100, 20 )

See also

* xp_read_file system procedure

* CSCONVERT function [String]

* Disk sandboxing

DELETE

FROM [owner.]table_1 [ [ AS ] correlation-name ]

FROM [owner.]table_1 [ [ AS ] correlation-name ] ...

WHERE ...

and

UPDATE [owner.]table_1 [ [ AS ] correlation-name ]

SET columns_1 = ...

FROM [owner.]table_1 [ [ AS ] correlation-name ] ...

WHERE ...

If the DELETE or UPDATE clause and the additional FROM clause have a table reference that contains the same table name, in the above example "table_1", then the server can only decide whether both are identical table references if one of the following conditions is true:

- both table references are not qualified by specifying a user ID

- both table references are qualified by specifying a user ID

- both table references are specified with a correlation name

In cases where the server cannot decide whether the above table references are identical or not it will now return an SQL error to prevent the user from unintended semantics like deleting and updating to many rows.

A work-around is to use addBatch/executeBatch for all executions of the prepared statement once addBatch/executeBatch has been used.

A workaround is to use setup -nogui to avoid the use of the graphical installer. Alternatively, install to a smaller disk drive.

A workaround is to avoid specifying -nogui when doing a silent install.

A workaround is to disable the Utilization Graph pane, or to resize the Chart pane so that it has a scroll bar.

- ansinull=On

- conversion_error=On

- divide_by_zero_error=On

- sort_collation=Internal

- string_rtruncation=On

, and the specified value was then set as a temporary option for the connection creating a materialized view, recovery of the CREATE MATERIALIZED VIEW statement would have failed. This has been fixed.

Note that the fix applies only to the CREATE statement executed with the fixed version of the server.

"unsupported function included: CURRENT_TIMESTAMP is not supported by generated always"

when trying to run the MobiLink server setup script file, synchana.sql against a database running on a HANA server, if the HANA server revision was 1.00.64 or later. This problem has now been fixed.

--------------------------------------------

Prior to this change, SQL Anywhere included a Certicom encryption module that provided strong encryption used throughout the software. Now, SQL Anywhere includes an OpenSSL encryption module for the strong encryption. The Certicom encryption module has been removed.

Read the following descriptions to determine how you may be impacted by this change.

FIPS encryption now requires the private key of an identity file to be encrypted using AES

- OpenSSL FIPS supports AES encryption for the private key of an identity file. New servers using the OpenSSL FIPS encryption module will not start when using an identity file that has its private key encrypted with 3DES. You must re-encrypt the identity file using AES. To do this, run a command similar to the following using an upgraded viewcert utility:

viewcert -p -o new-file-name -op new-password -ip old-password old-file-name

The new and old passwords can be the same.

- The sample server identity file (rsaserver.id) and client identity file (rsaclient.id) have been modified so that the private keys are encrypted using AES rather than 3DES.

- Versions of the server that use the Certicom encryption module will not start when using an identity file that has its private key encrypted using AES. Trusted root certificate files specified using trusted_certificates do not need to be modified.

Self-signed certificates must now have the Certificate Signing attribute set

Self-signed certificates must now have the Certificate Signing attribute set when using the identity encryption option (for example, the -x mlsrvXX and -xs dbsrvXX options). To determine if a certificate has the Certificate Signing attribute set, use the viewcert utility and look for the Certificate Signing attribute in the Key Usage portion of the output. If your self-signed certificates do not have the Certificate Signing attribute set, then you must regenerate the certificates.

Create Certificate utility (createcert) now uses AES encryption instead of 3DES

The Create Certificate utility (createcert) now uses AES rather than 3DES encryption for encrypting the private key in the server identity file.

A new option, -3des, has been added to the Create Certificate utility. Use this option when you want to create a 3DES-encrypted server identity file that can be used by both new and old servers. Note that new servers running in FIPS mode cannot start using 3DES-encrypted certificates; however, if you are not running in FIPS mode, then you can use 3DES-encrypted certificates.

View Certificate utility (viewcert) now uses AES encryption instead of 3DES

The View Certificate utility (viewcert) now uses AES rather than 3DES encryption when you specify the -p option to PEM-encode the output and when you specify the -ip and -op options to set the password.

A new option, -3des, has been added to the View Certificate utility to allow you encrypt output and passwords using 3DES instead of AES.

Database server now loads the FIPS driver file, dbfipsXX.dll, at startup

Previously, the 32-bit Windows database server loaded the FIPS driver file, dbfipsXX.dll, only when needed. Now, the 32-bit Windows database server always attempts to load dbfipsXX.dll at startup, and keeps it loaded for the life of the server. If loading dbfipsXX.dll fails, then an error is returned only when an attempt is made to use FIPS encryption.

Deploying FIPS

If you are deploying FIPS encryption, then there are new shared libraries to deploy; these files are included in your software. The former files, sbgse2.dll and libsbgse2.so, are no longer installed by the software. The new files to deploy are:

- Windows 64-bit: libeay32.dll, ssleay32.dll, and msvcr100.dll

- Windows 32-bit: libeay32.dll, ssleay32.dll, and msvcr90.dll

- Linux: libcrypto.so and libssl.so

Note: On Windows, although 32-bit and 64-bit FIPS-certified OpenSSL libraries for encryption are provided, you must use the 64-bit libraries on a 64-bit system.

MobiLink-related changes and information

Connecting to a MobiLink server using client-side certificates now requires the Digital Signature certificate attribute to be set

TLS/SSL connections to a MobiLink server using client-side certificates now require the client-side certificate to have the Digital Signature attribute set. If the attribute is not set, then the connection will fail.

To determine if a certificate has the Digital Signature attribute set, use the View Certificate utility (viewcert) and look for the Digital Signature attribute in the Key Usage portion of the output. If your client-side certificates do not have the Digital Signature attribute set, then you must regenerate the certificates.

FIPS-based end-to-end encryption now requires the private key to be encrypted using AES

If the private key file provided to a MobiLink server by the e2ee_private_key file option of the 杧 command-line option is encoded using 3DES and you are running in FIPS mode, then the private key file needs to be regenerated with the private key encrypted using AES.

How to update a MobiLink deployment that uses non-FIPS TLS/SSL (includes HTTPS) and client-side certificates

1. If your client-side identity certificates do not have the Digital Signature attribute set and the client connects directly to the MobiLink server, then you must regenerate and deploy client-side certificates with the Digital Signature attribute set.

2. Update the server-side binaries.

3. Update the client-side binaries.

How to update a MobiLink deployment that uses FIPS, TLS/SSL (includes HTTPS) and client-side certificates

These steps update the client identity certificates twice if the Digital Signature attribute is missing from client-side identity certificates. This procedure can make the update less disruptive because synchronizations can continue without having to coordinate the client-side and server-side updates to occur at the same time.

1. If your current client-side identity certificates do not have the Digital Signature attribute set and the client connects directly to the MobiLink server, then you must regenerate and deploy client-side certificates with the Digital Signature attribute set.

2. Update the server-side binaries (remembering to include the new FIPS driver files) and deploy server identity certificates with AES-encrypted private keys.

3. Update the client-side binaries (remembering to include the new FIPS driver files) and deploy client identity certificates with AES-encrypted private keys.

How to update a MobiLink deployment that uses FIPS and end-to-end encryption

1. Regenerate the primary key file referenced by the e2ee_private_key encryption option.

2. Shut down the MobiLink server.

3. Update the MobiLink server binaries, remembering to include the new required FIPS driver files.

4. Change the e2ee_private_key option to point to the new private key file (or replace the old file), updating the e2ee_private_key_password, if required.

5. Restart the MobiLink server.

Note, connecting to and creating a MobiLink server resource in the 32-bit Windows SA Monitor that will use FIPS encryption to connect to the MobiLink server, may fail with the error, 揊ailed to load library mlcrsafips12.dll�. To work around this, you can either not use FIPS encryption, or use 64-bit SA Monitor. Similarly, connecting to a database server from 32-bit DBISQL, DBConsole, or Sybase Central using FIPS encryption, may also fail with the error, 揊ailed to load library mlcrsafips12.dll�. To work around this problems, you can either not use FIPS encryption, or use 64-bit client software.

A work around to the issue is to restart the MobiLink Server.

Upgrading overwrites the JRE directory (%SQLANY16%\binXX\jre170) and its subdirectories. If you are using certificates, then your certificate store (%SQLANY16%\binXX\jre170\lib\security\cacerts) is overwritten, including your certificates. Similarly, fonts you added to the %SQLANY16%\binXX\jre170\lib\fonts\fallback directory to help display characters in the administration tools may be lost. To minimize upgrading steps with regards to the JRE change, create a backup copy of the JRE directory and all of its subdirectories before you upgrade so that you can refer to or restore files (such as cacerts) from the backup, as needed. To restore settings, use the java_vm_options option (SQL Anywhere), and/or the -sl java option (MobiLink) to optimize your Java VM startup settings.

- the mirror or copy node must have been fairly recently started and requesting log pages (in the case of the mirror, not yet synchronized)

- the mirror or copy node must have been writing pages from the primary's current log file

- the primary log file was renamed

- something (such as a virus scanner) must have accessed the renamed log on the primary (or parent), preventing the primary from opening the file when the mirror or copy node requested pages from it

This has been fixed so that the primary or parent will attempt to open the renamed log several times before failing. If the file open still fails after multiple attempts, the primary will display the message "Database "<database-name>" mirroring: failure when opening log file <file-name> for remote server <server-name>" and the mirror or copy node will display the message "Database "<database-name>" mirroring: database is not compatible with primary; files must be replaced" and shut down the database.

Note, the same sizing issue also occurred with the 揙ptions� window of the SQL Anywhere Console utility.

- The OData Version 2 specification is unclear in the case of the max constant for the MaxLength attribute of a property. Many clients will accept both 搈ax� and 揗ax� as valid cases, but the Microsoft clients only accept 揗ax�. In OData version 4+, the spec is clear that the correct case is 搈ax�. To avoid such issues two things have been done:

1. For SQLA and ASE, the MaxLength attribute will always specify the MaxLength attribute with a number in the range 1 to 2^31-1 (to avoid the use of 搈ax� altogether).

2. It is possible for an IQ column to have a value that is larger than 2^31-1 bytes/characters, in which case we must continue to use 搈ax�. The default case will continue to be 搈ax� but the OData server administrator can override the case using the __MaxLengthMaxString option in the config file.

- The DefaultValue attribute was being used incorrectly. The Microsoft OData clients expect the DefaultValue attribute of a given type to be a valid value (as would appear in a request URL) for that type. For example, the DefaultValue for an Edm.Int32 must be an 32-bit integer. This is somewhat unclear in the version 2 OData spec but is clearly the stated behaviour in OData version 4+.

The DefaultValue attribute was being used to represent the underlying default of the database (for example, an autoincrement column would have DefaultValue=攁utoincrement�). Since the DefaultValue attribute is not appropriate for all possible default values that an underlying column in the database can have, we will no longer expose default value information in the metadata document using the DefaultValue attribute.

- ASE Money data type columns were reporting a Precision and Scale of 0.

a) The setting for the ldap_failover_to_std property for a user authentication policy is extended to be 0, 1, or 2 [it originally accepts only 0 (FALSE) or 1 (TRUE)). The MobiLink server will authenticate users in the following ways, when ldap_failover_to_std is

0: The MobiLink server will authenticate the user against LDAP server only. If the user cannot be authenticated against a LDAP server, the MobiLink server will fail the sync request, regardless of the types of the errors;

1: The MobiLink server will authenticate the user using the standard script-based user authentication, if and only if the LDAP server(s) are not available. The authentication status, 6000 will be passed to the user authentication scripts, if the LDAP servers are not available;

2: The MobiLink server will authenticate the user against a LDAP server first and then authenticates the user with the standard script-based user authentication, no matter if the user is authenticated or not with the LDAP server. The MobiLink server will pass one of the following values as a user authentication status to the scripts:

1000: if the user is authenticated against the LDAP server;

4000: if the user is not authenticated against the LDAP server; or

6000: if the LDAP servers are not available.

b) User authentication using a default authentication policy:

The MobiLink server now supports user authentication against a LDAP server using a default user authentication policy. The default policy name can be specified from the new MobiLink server command option: -zup <name> "set default policy name for user authentication (implies -zu+, cannot be used with -zu-)"

When a policy name is specified on the MobiLink server command line with this new option, any new MobiLink users that aren抰 in the ml_user table will be first authenticated against the LDAP server using this default policy, and then optionally calls the user authentication scripts, if the ldap_failover_to_std property for the default policy is configured with a value of 1 or 2. If the user is fully authenticated, it will be added into the ml_user table and the same user authentication policy will then be used to authenticate this user later. This new command line option implies 杬u+ and it cannot be used with 杬u-. The MobiLink server will complain, if both 杬up and 杬u- are given on the command line.

Please note: the given default user authentication policy name must exist in the ml_user_auth_policy table , otherwise the MobiLink server will complain and refuses to start.

c) The MobiLink user password will be hashed and stored in the ml_user table in the consolidated database, if and only if the ldap_failover_to_std property is configured with a value of 1 or 2. The password will not be saved, if this property is set to 0.

- the -o option was not specified, AND

- if any of the environment variables $TMPDIR, $TMP, $TEMP was defined but the directory did not exist.

Depending on how rshost was started, it could have failed silently. This has been fixed.

In addition, transferring many log pages between mirror servers may have been slower than necessary. The default maximum packet size used for connections between mirror servers has been increased, which can improve performance in some cases. 16.0.0 mirror server connections now default to a maximum packet size of 64240 bytes, and 12.0.1 mirror server connections now default to a maximum packet size of 16000 bytes.

Note that UltraLite does not support the clause 揥ITH NULLS NOT DISTINCT� for the CREATE INDEX statement. Therefore, an index key should be considered unique if it contains NULL in at least one column.

Each bottom level directory in the following tree under the SQLA install root contains a WinRT-based component (UltraLite.winmd/UltraLite.dll) that implements the UltraLite API for the noted platform.

UltraLite

+-- WinRT

|-- WindowsPhone

| +-- 8.0

| +-- arm : Windows Phone 8 devices

| +-- x86 : Windows Phone 8 emulator

+-- Windows

+-- 8.0

+-- arm : Windows RT ARM-based devices

|-- x64 : Windows 8 store apps for x64 architecture

+-- x86 : Windows 8 store apps for x86 architecture

Developing UltraLite applications using this software requires SQL Anywhere 16 and Microsoft Visual Studio 2012 or later.

Developing Windows Phone applications requires the Windows Phone SDK 8.0, which is available from:

http://dev.windowsphone.com/en-us/downloadsdk

Windows Phone SDK 8.0 requires Windows 8. Microsoft lists the complete system requirements at:

http://www.microsoft.com/en-us/download/details.aspx?id=35471

Developing Windows store applications requires the Windows SDK for Windows 8, which is available from:

http://msdn.microsoft.com/en-us/library/windows/desktop/hh852363.aspx

The UltraLite.WinRT directory under the SQLA samples root contains a Visual Studio 2012 solution for the CustDb sample that appears in various forms for other UltraLite supported platforms.

[-10382] The MobiLink Server has failed to start

This problem has now been fixed.

- Interactive SQL 12 was being run and the "Help" button was clicked on the "Connect" window the first time it was opened, and the network used a proxy to connect to the internet.

- Sybase Central 12 or later, or Interactive SQL 12 or later, was being run and the fast launcher was turned on, and the network used a proxy to connect to the internet.

These problems have been fixed.

- The maximum size of the VARCHAR2, NVARCHAR2, and RAW data types has been increased from 4,000 to 32,767 bytes

- Implicit result sets can be returned from stored procedures. However the number of implicit result sets is limited to one per stored procedure. The implicit result set will be detected automatically by the ODBC driver regardless of the setting for the 揚rocedure returns results or uses VARRAY parameters� option in the DSN used by the ODBC application

When the database is running on an Oracle 12.1 server and the OCI library is from the Oracle 12.1 installation.

- If a database contained a dbspace with a relative pathname, and the server was not started in the same directory as that file, the CREATE ENCRYPTED/DECRYPTED DATABASE statements would not have been able to find the dbspace file

- In the above case, the error message would have said 揙utput file cannot be written� even though it was an input file causing the problem. The error message had no indication of which file caused the problem

- If the target filename for these statements was in a different directory, the encrypted or decrypted dbspace files would have remained in the original directory.

For example, if a database had a dbspace with the filename 揹bspace.dbs� and the following was executed:

create encrypted database 憂ew/sales.db� from 憇ales.db� key 憁yencryptionkey�

the server would have created the new dbspace.dbsE file in the same directory as dbspace.dbs, rather than in the 搉ew� subdirectory.

These problems have now been fixed.

The new MobiLink Server 杬up switch. This switch can be accessed from the Advanced tab of the property sheet for a MobiLink Server Command Line. An error is reported if 杬up is set and 杬u is set to false, as this is not allowed.

For user authentication policies we now support calling the standard MobiLink authentication scripts: Never, Always or only when an LDAP server could not be found. This change affects the LDAP Servers page of the New User Authentication Policy wizard. It also affects the property sheet for user authentication policies. The setting is also shown in the right hand pane when User Authentication Policies are shown.

- the database was backed up from the primary or root using dbbackup or the BACKUP statement

- while dbbackup was running, there must have been other connections to the primary or root that had modified the database

- between the backup and when the copy node was started on the backed up database, there was no commit done on the primary or root

If this problem was occurring, the sa_mirror_server_status row for the copy node would show the copy node was connected with a recent last_updated value, but the log_written and log_applied values would not change. If the copy node was restarted, it would start applying and writing changes. This has been fixed.

A workaround is to manually remove all but one row from ml_scripts_modified table before starting the MobiLink Server.

If an ALTER MIRROR SERVER statement was used to add an alternate parent to a running and connected copy node, the alternate parent would have been used until the copy node restarted. This has been fixed so the alternate parent can be used the next time the copy node loses its connection to its parent.

Also, when fetching a Date, Time, or Timestamp, or other types that are not native strings or numerics, from the database when the clients character set is different from the database character set, the data would have been returned in the database character set. This has been fixed so the data will returned to the client in the client's character set.

SQL statement failed: (-685) Resource governor for 'prepared statements' exceeded

when it was running in a continuous mode with the command line option 杧. This problem has now been fixed.

Also, if a server to server mirror connection failed due to a liveness timeout, no message was logged even if -z was enabled. In addition, other server to server connections contained little diagnostic information even if -z diagnostic logged was enabled. This has been fixed so that liveness timeout messages for mirror server connection are logged with or without -z. In addition, the messages "mirror server connection closed by other side" and "connection terminated abnormally; error code <number>" will be logged if -z is used and a mirror server connection is closed by the remote server or fails due to a network error.

set contains additional incorrect result rows.

For example, in the below query the predicate "v2.c = 0" can be pushed inside the derived table "v2" and derived table "v2" can be flatted. Predicate is not executed in this case.

select *

from ( select distinct *

from ( select a, sum(b) c from T1 group by a ) v1

) v2

where v2.c = 0

This has been fixed.

select (B.gencol1).id as gencol1 from (

select ROW(A.id) as gencol1

from Product A

group by A.id) B order by gencol1

B.gencol1 is a row with one column named id in it. (B.gencol1).id should have been able to reference to that column. In fact, it can reference it when 揼roup by A.id� is removed. However, when the GROUP BY was present, an error was returned: 揷olumn 慽d� not found in variable (B.gencol1)�. This has now been corrected.

Note, model files may still refer to Database names that are not valid OData identifiers, however they must be renamed using 揂S� clause.

The value for property "{columnname}" in a key predicate is formatted incorrectly.

If paging through descending order on a column with nulls, skiptoken may have missed results or restarted at top (thus creating an infinite dataset). This has been fixed.

"select replace( 'XAAAAAAAXBBBBXBBBB', 'XAAAAAAA', 'Z' )".

This has been fixed

new ST_Point( 2, 2.5 ).ST_Buffer( 1.1 )

Trying to use the resulting CurvePolygon in an operation may have caused unpredictable results. This has been fixed.

Note, this issue doesn抰 happen on the Apache Relay Server.

Note, older dbostop16 utilities will not be able to shutdown newer OData Server, and new dbostop16 utilities will not be able to shutdown older servers.

- The OData Producer now supports Optimistic Concurrency Control as defined by versions 2.0 of the OData Specification.

Using the OSDL model definition file (see Example 1), a developer may specify a set of properties on an Entity Type to define the concurrency token of the Entity.

- The OData Producer now supports Service Operations using HTTP GET and POST methods as specified by version 2.0 of the OData Specification.

Developers must declare explicitly what service operations to expose in an OSDL file.

- OData Producer uses less objects when caching metadata for users that have (from the OData Producer抯 perspective) identical access.

- OSDL files support added escape sequences in quoted strings

- Associations are now annotated as referential constraints in the metadata and association properties of referential constraints are now visible by default. Association may also have OnDelete attributes in the metadata which documents how the dependent entity instance is affected when the associated principal entity instances is delete.

- The log generated by OData Producers has been enhanced to identify the producer and request associated with each log event.

- OData server supports multiple producers

dbosrv16 can now host multiple producers, each connecting to a different database. All producers share the same options configuration file and are hosted on the same port. The producer configuration file syntax has been augmented for this feature.

- The OData producer now supports a greater subset of the OData Service Definition Language (OSDL).

The new supported syntax adds the ability to:

- Explicitly set the name of tables that are exposed through the producer

- Explicitly include/exclude columns

- Define entity sets with generated keys

- Define associations between entities, including complex associations that use an underlying association table

- Define navigation properties

SQLCODE -1325: Column subset for table '%1' in publication '%2' does not match that specified in publication '%3'

This has been fixed.

"Table '_^_^_22072007_^_^_759_^_^_22072007_^_^_' not found"

for an internal temporary table if an INSERT, UPDATE, or DELETE statement triggered the change of an immediate materialized view. The problem only happened when the very first INSERT, UPDATE, or DELETE of the table in a connection was executed in a nested block, for example a trigger or procedure. In this case subsequent DML operations on the

table may then have returned the above error. This has been fixed.

This issue was partially fixed by the changes for Engineering case 752610, but this change goes beyond it by fixing the following problems as well:

- On the Search panel, the "Search" button enabling logic and the button's clicking logic would stop working after the look-and-feel changed.

- Sybase Central could have crashed if any of the following panels/windows were open when the look and feel were closed:

1. "Results" on the "Search" pane

2. The list of plug-in in the "Sybase Central Plug-ins" window.

3. The connection profiles window

4. The About window

5. The Disconnect window

- The background color of items in details panels would have been painted gray (rather than white) after switching look-and-feel.

- Drop-down toolbar buttons (e.g. "Tools") did not draw their arrow, and did not open when clicked.

HTTP ERROR: 500

Problem accessing /odata/Filter03/T6. Reason: while trying to invoke the method

com.sybase.odata.producer.util.RequestWrapper.getParameterMap() of a null object

loaded from field com.sybase.odata.producer.handler.AbstractHandler.request of an

object loaded from local variable 'this'

This has been fixed. Clients will now get

HTTP ERROR: 400 Bad Request

<?xml version="1.0" encoding="utf-8"?>

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">

<code>30175</code>

<message xml:lang="en-US">An error occured while parsing the request URI at offset 59.</message>

</error>

- when failover occurs and the mirror server takes over as the primary "Now running as primary server" is now logged. Previously, "Database <name> (<file>) started at <date/time>" was logged, which was incorrect because the database was already started and was not restarted.

- if the mirror server was behind applying operations and caused the primary to block for more than 10 seconds, "primary blocked for <number> seconds waiting for the mirror to catch up" is logged.

- transaction log start and current offsets are now displayed when starting up a database and at other transitions (such as when the transaction log is restarted).

- if there was an unexpected error that caused applying the transaction log to fail, a message is displayed and the database is not automatically restarted

For example: If a table has a primary key on columns (col1, col2) and there is another index on columns (col2, col3, col1) then this other index is unique as well.

The optimizer relies very much on this unique property of an index for cardinality estimation. So the server may have used an non-optimal plan if above conditions were true. This has now been fixed.

application/xml

application/atom+xml

application/json

*/*

For example, this statement would not have handled the \� sequences and would have generated an error:

call sp_parse_json( 憁yvar�, 慬{s:攖his is \攓uoted text\�.攠]� );

This has been fixed.

In the existing databases, LineStrings that cross equator from South to North and are stored in a Round Earth SRS (for example, 4326) should be reloaded in order to be stored in the correct representation.

In rare, timing dependent cases, if multiple connections were running the same procedure concurrently and a DDL operation occurred, the server could have hung. In order for the hang to have occurred, the procedure needed to have had multiple statements that referenced the same view. This has also been fixed.

"File or directory /opt/saondemand100/data/staging/SD-z6b9/Bin64/libeay32.dll not found"

This has been fixed.

Note that this change is most significant when querying the mv_known_stale_at column from SYS.SYSVIEW since 0000-01-00 represents a materialized view that is either fresh or in an unknown state. The value will now be returned as 0001-01-01 instead.

This has been fixed.

References to the Usage Server have been removed. The following hyperlinks have been removed from the Cloud's "Overview" page: "Activate the cloud", "Refresh activation state", "Send usage information", "Log in to Usage Server".

On the Cloud overview page, the "Licensing" properties are now displayed all the time. Previously, they appeared only after the cloud was activated. The "Licensing" section now includes two new links: "Add Licenses" and "Remove Licenses" for managing cloud licenses.

--CONNECT-1025-0000952657-failure-2014-03-18 09:36

indicating a possible connection failure. This has been fixed. These lines do not indicate a connection failure. They can be safely ignored and will not show up in transaction logs created with fixed servers.

successfully authenticate. This has been corrected.

These unneeded evaluations are now skipped. A change in behaviour is that side effects and errors are no longer observed in some cases. There may still be more executions than client fetches due to factors such as prefetching.

The same incorrect behaviour would also have occurred with the SetString method of ResultSet and Table, and with the SetParameterBytes method of PreparedStatement. These cases have also been fixed.

-- The dialog appeared to give the option of creating both 32 and 64-bit versions of a user data source. This option applies only to creating system DSNs, and is now disabled.

-- When trying to create both a 32 and 64 bit system DSN, but the 32-bit could not be created, the error message was irrelevant. This has been fixed; the error message now says why the data source could not be created.

-- Data sources could be created with non-canonical forms of the connection parameter names. This would have prevented the Data Source utility (dbdsn) from listing the data source completely. This has been fixed.

-- Creating a system data source could have caused up to three elevation prompts if a 32-bit data source was also created. Now, there is at most one prompt.

-- The dialog allowed creation of a user data source, even if there was already a system data source of the same name. Similarly, it allowed creation of a system data source with the same name as an existing user data source. This was very poor practice and could have lead to unexpected results if a user didn't realize that user data sources take precedence, and so the practice is now simply disallowed.

When quoted_identifier was 'off':

1. For a Sybase IQ DBMS, the driver would have reported [SQL Anywhere] in messages rather than [Sybase IQ].

2. For a Sybase IQ DBMS, the driver would have reported "SQL Anywhere" instead of "Sybase IQ" for SQLGetInfo(SQL_DBMS_NAME).

3. For a Sybase IQ DBMS, the driver would not have used the "SYS.SYSIQVINDEX" table for SQLStatistics, but would have used "SYS.SYSINDEX" instead.

4. For a Sybase IQ DBMS, the ODBC driver will report the wrong server version number (e.g., 12.0.1 rather than 15.4) for SQLGetInfo(SQL_DBMS_VER).

In addition, when quoted_identifier was 'off' or the server was version 9.0.2 or earlier:

5. The ODBC driver would not have known the correct CHARSET setting.

6. The ODBC driver may have had the wrong setting for the case sensitivity of the database and may have affected SQLGetTypeInfo and other schema query functions.

7. The ODBC driver may have had the wrong setting for the odbc_distinguish_char_and_varchar option.

8. The ODBC driver may have had the wrong setting for the odbc_describe_binary_as_varbinary option.

Other than these issues, there are no other known side-effects.

This problem has been fixed.

For OData Producers deployed using the OData Server utility (dbosrv16), paths are relative to the current directory when the server was launched.

When a single file gets too big, the server will now detect this situation, version 11 and 12 servers will display a failed assertion message and shut down. Version 16 and later servers will display a failed assertion message and shut down only the affected database.

Content-Type: multipart/mixed; boundary=batch_e30b82d3-3d8a-430d-b66f-9fec1df8ae19; charset=utf-8

would have resulted in a 404 error. This has been fixed.

As a work around, database administrators should directly grant execute permission on given stored procedures or functions to the affected users.

- SQL Anywhere Server when using TLS (Transport Layer Security) communications and/or HTTPS web services, though only to the networks that can access the server. Calling external web services over HTTPS from the database server were also affected.

- MobiLink Server when using TLS and/or HTTPS communications, though only to the networks that can access the MobiLink server.

- Relay Server Outbound Enabler

Affected Versions (note that all platforms were impacted by the vulnerability):

- SQL Anywhere 12.0.1 builds 3994-4098

- SQL Anywhere 16.0 builds 1690-1880

This vulnerability has been resolved by replacing the OpenSSL libraries with corrected versions. Once this SP has been applied, regenerate any certificates that were being used, and then change any passwords/keys associated with SQLA web service calls or TLS authentication.

This prolem also affects the Interactive SQL utility. It has been present since version 9.0.2, possibly earlier.

For example:

OEE1048: The communication between the Outbound Enabler and the backend server failed with [MLC24: ???] while performing secured write. sidx=0 socket=01028188 sfp=58f2ed03

A workaround to diagnose the communication error in the case where the RSOE didn抰 crash is to look at the Relay Server log as the detail is sent there and reported as an OEE1048 embedded in RSE4015 with details.

The crash has been fixed and the details in RSOE log have been restored. An example after the fix:

OEE1048: The communication between the Outbound Enabler and the backend server failed with [MLC24: Server certificate not trusted. The system-specific error code is 336134278 (hex 14090086).] while performing secured write. sidx=0 socket=01028188 sfp=58f2ed03

The RSOE may also have suffered false OEE1048(MLC8) SSL read errors when -cs https=1 was used. This has also been fixed.

Note that CREATE PROCEDURE/FUNCTION and ALTER PROCEDURE/FUNCTION statements were not affected.

A workaround for this problem is to start the MobiLink server with the hidden option,

-hwg-

POLYGON((-1 -1, -1 1, 0 0, 1 1, 1 -1, -1 -1))

would have resulted in an invalid polygon error. This has been fixed. There is no known workaround.

This problem could have also impacted the values returned by SQLError, SQLDataSources, and SQLGetDescRec if the driver manager called their "wide" equivalents. This problem is also corrected.

In addition, SQLGetDescRec could return a random field name for a descriptor when there was no field name (for example, a bookmark column has no field name). There was also the extremely rare possibility of a segment violation fault. These problems have been corrected.

[-10410] The client failed to send a complete sequence of commands

Ping request failed

Other than the error message, the ping operation would have behaved correctly. This has been fixed so that the warning is now prevented from being issued.

SAConnection local_conn = new SAConnection( SAServerSideConnection.Connection.ConnectionString );

Local_conn.Open()

then both the SQL Anywhere Server and the corresponding CLR External Environment would crash. This problem has now been fixed.

- Remote Data Access

- External Stored Procedures (note these are native dlls and shared objects that are loaded in process)

- External Environments (including JAVA, CLR, PERL, PHP, C_ODBC and C_ESQL external environments)

- LDAP UA

- Kerberos Authentication

Example:

SELECT 'string' AS "alias...name" FROM dummy

Similarily, if a SQL column expression contained more than 128 characters, a .NET client application could have crashed.

Example:

SELECT 1+2+3+...+1000 FROM dummy

These problems have been fixed. Alias and expression names are now restricted to at most 128 characters by the SQL Anywhere .NET data provider.

As a work-around for the first case, restrict the length of alias names to at most 128 characters.

Example:

SELECT 'string' AS expr FROM dummy

As a work-around for the second case, use an alias name and restrict the length of its name to at most 128 characters.

Example:

SELECT 1+2+3+...+1000 AS expr FROM dummy

Example:

SELECT SPACE(1147483643) FROM dummy

The possible buffer overrun has been corrected.

The database must be created or rebuilt to access the larger publication article size. Older databases will continue to work with a max publication article size of 256 bytes. Databases created or rebuild with this change will run on older runtimes provided publication articles are <= 256 bytes.

Details of the kernel bug can be found here:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/nfs/direct.c?id=67fad106a219e083c91c79695bd1807dde1bf7b9

This has been fixed. Direct I/O will no longer be used for remote file systems on these Linux versions. Upgrading the Linux kernel to at least 3.8 is the only workaround.

- The Relay Server no longer creates new metrics until the rs_monitor.dll has been accessed. Most partners don抰 distribute rs_monitor.dll.

- If rs_monitor.dll has been accessed and the number of client types of a backend server has exceeded 1600, a new RSW107 warning is issued instead of the RSF13011 fatal error.

- In the RSW107 situation, the Relay Server will continue to relay the traffic, but no new metrics are created for the new client type.

Note, device I/O errors still require the database to be restarted. Corrupt databases can be detected with the Validate API or ulvalid utility.

EXEC SQL BEGIN DECLARE SECTION;

EXEC SQL END DECLARE SECTION;

would have resulted in the following error:

test.sqc(35): Error! E2636 near 'AREARE': Incorrect Embedded SQL syntax

This has been fixed. There is no known workaround for this.

The affected system procedures are:

- sa_server_option

- sa_db_option

- sp_create_secure_feature_key

- sp_alter_secure_feature_key

- sp_drop_secure_feature_key

Note, the original permission denied problem still exists if the database is initialized or upgraded with the legacy SQL SECURITY DEFINER model.

It should be noted that only one CLR External Environment can be launched per database. Hence applications need to decide prior to starting the CLR External Environment which version of .NET should be used. By default, the server will launch the CLR External Environment that will allow server side calls using either the .NET 2.0 or 3.5 Provider. If an application needs to make server side calls using .NET 4.0; then the following ALTER EXTERNAL ENVIRONMENT statement must be executed prior to starting the CLR External Environment:

ALTER EXTERNAL ENVIRONMENT CLR LOCATION 'dbextclr[VER_MAJOR]_v4.0 '

Similarly, if an application needs to make server side calls using .NET 4.5; then the following ALTER EXTERNAL ENVIRONMENT statement must be executed:

ALTER EXTERNAL ENVIRONMENT CLR LOCATION 'dbextclr[VER_MAJOR]_v4.5 '

If the application needs to go back to .NET 2.0 or 3.5; then the following ALTER EXTERNAL ENVIRONMENT statement must be executed:

ALTER EXTERNAL ENVIRONMENT CLR LOCATION 'dbextclr[VER_MAJOR] '

Note that in each of the above [VER_MAJOR] should NOT be replaced with one of 12 or 16. It is best to keep [VER_MAJOR] as is in order to ensure a smooth transition to a newer version of SQL Anywhere if needed.

Other side effects of this problem may also have been seen:

- If the sadiags.xml file was large then the merge-to-disk operation that automatically happens at midnight each day may have taken a long time and any other operation that caused a feature to be 慶ounted� would have blocked until the merge was complete. I.e. some operations at midnight may have been seen to 慼ang� or take longer than usual to complete.

- Mobilink servers could also suffer the slow shutdown (or midnight sync) problem if a database server was running on the same computer and that database server had generated a large sadiags.xml file.

This has been fixed. A work-around is to delete the sadiags.xml file prior to shutting down the server. This should only be expected to improve the shutdown time if the size of the file is large (e.g. over 100K bytes).

For example:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<configSections>

<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

</configSections>

<startup>

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />

</startup>

<connectionStrings>

<add name="Entities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=iAnywhere.Data.SQLAnywhere;provider connection string='datasourcename="SQL Anywhere 12 Demo"'" providerName="System.Data.EntityClient" />

</connectionStrings>

<system.data>

<DbProviderFactories>

<clear />

<add name="SQL Anywhere 12 Data Provider" invariant="iAnywhere.Data.SQLAnywhere" description=".Net Framework Data Provider for SQL Anywhere 12" type="iAnywhere.Data.SQLAnywhere.SAFactory, iAnywhere.Data.SQLAnywhere.EF6, Version=12.0.1.41474, Culture=neutral, PublicKeyToken=f222fc4333e0d400" />

</DbProviderFactories>

</system.data>

<entityFramework>

<providers>

<provider invariantName="iAnywhere.Data.SQLAnywhere" type="iAnywhere.Data.SQLAnywhere.SAProviderServices, iAnywhere.Data.SQLAnywhere.EF6, Version=12.0.1.41474, Culture=neutral, PublicKeyToken=f222fc4333e0d400" />

</providers>

</entityFramework>

</configuration>

create procedure sp_test( in @a integer, in @b integer )

begin

select @a + @b as c;

end

Binding two host variables and executing 揝ELECT * FROM sp_test(?, ?)" just after starting the database server, then the error "Not enough values for host variables" might have resulted. Subsequent execution attempts would have succeeded. A similar problem would have occurred when "SELECT * FROM sp_test(?, ?)" was executed immediately after (dropping and then) creating the stored procedure. This has now been fixed.

For UPDATE and DELETE statements the SQL reference correctly documents:

"You cannot use ordinal column numbers in the ORDER BY clause."

But for DELETE statements the syntax must be changed from

[ ORDER BY { expression | integer } [ ASC | DESC ], ... ]

to

[ ORDER BY expression [ ASC | DESC ] , ...]

This has been fixed

CREATE TABLE FarmEquipment.Products(...);

CREATE TABLE HighwayEquipment.Products(...);

the following statement would only have validated one of them at random:

SELECT * FROM sa_validate( 'Products' );

Even if the user execting the SELECT was the owner of a table called "Products", it may not have been the table that is validated. In other words, the statement above was not equivalent to:

VALIDATE TABLE Products;

The documentation states that all tables/materialized views matching the specified object name are validated. This problem has been fixed. The work-around is to specify the table/materialized view owner (the second argument).

Note, this change will apply to dbremote and dbmlsync logs as well.

The conditions for which this could happen must include:

(1) (subquery) was correlated with the main query block

(2) (subquery) has a very small size comparing to the table[s] referenced by the correlations

Note, this problem also affected Sybase Central and the Console utility, which are fixed as well.

The steps for generating Entity Framework 6 data models (Entity Framework 6 Tools for Visual Studio 2012 & 2013 should be installed):

- Run SetupVSPackage.exe with �/v 6� option to register the Entity Framework 6 Provider.

- Install Entity Framework NuGet Package for the Visual Studio project.

- Modify app.config file to add the Entity Framework 6 provider. Here抯 an example:

<providers>

<provider invariantName="iAnywhere.Data.SQLAnywhere" type="iAnywhere.Data.SQLAnywhere.SAProviderServices, iAnywhere.Data.SQLAnywhere.EF6, Version=16.0.0.20144, Culture=neutral, PublicKeyToken=f222fc4333e0d400" />

- Build the Visual Studio project.

- Run Entity Data Model Wizard.

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">

<code>30000</code>

<message xml:lang="en-US">An unexpected error occurred in the producer. Contact the server administrator for more details.</message>

</error>

This has been fixed. Check constraints will now return either 30144, 30145 or 30146 errors, similar to unique constraint violations, depending on the type of request (INSERT, UPDATE or DELETE).

On Windows systems: Sybase Central could have become unresponsive for about a minute when viewing the generated documentation, and the directory was specified from the root of the drive but did not include the drive letter.

On non-Windows systems: Generating the documentation to a directory with a space in its name, and then attempting to open the documentation would have failed.

Note, affected procedures will need to be recreated with the fixed version of the server.

If a post login procedure did not return a result set, the Interactive SQL utility would have crashed.

Also, a race condition could have caused the window containing the post login messages to appear on-screen at the same time as the "Connecting to database" status window. When this occurred, neither window could have been closed.

Note, the problem does not happen in DDL and DML statements.

When executing a parallel query plan with a COUNT_BIG() over a table larger than representable in an INTEGER (approximately 2 billion rows), an error such as 揤alue SUM() out of range for destination� was returned. This is now corrected.

The SUM(x) aggregate function now returns BIGINT if x is of type BIGINT.

When using COUNT_BIG() in sliding window queries, the window was re-scanned for each row of the window instead of decrementing the count when rows were removed. This has been corrected.

The graphical plan for window operators now displays the PARTITION BY, ORDER BY, and window functions computed by the operator. It also shows whether rows are removed from the functions by inverting the aggregate (e.g., SUM, COUNT, COUNT_BIG) or by rescanning the window (e.g., MIN,MAX). Rescanning the buffer is slower and proportional to the square of the maximum buffer size.

The COUNT_BIG aggregate is now supported for incremental maintenance materialized views.

When printing COUNT_BIG with no argument, it is now printed as COUNT_BIG(*).

If COUNT_BIG() was used in a subquery that was flattened by semantic transformations, it was possible for the function to improperly return NULL instead of 0 (the classic count bug). This has now been corrected.

Also, the install package now includes a compiled library in the usual place. The script build.sh is no longer used to produce the library after installing.

For example:

--batch_5f3ccbef-11fe-4dcc-a546-02ba2e746d72

Content-Type: multipart/mixed; boundary=cs_025fc4e4-fd30-4372-8fa4-5b941ee66915

--cs_025fc4e4-fd30-4372-8fa4-5b941ee66915

Content-Type: application/http

Content-Transfer-Encoding: binary

HTTP/1.1 400 Bad Request

RepeatabilityResult: accepted

Content-Type: application/json;charset=utf-8

{

"error" : {

"code" : "30063", "message" : {

"lang" : "en-US", "value" : "An entity instance with this key already exists."

}

}

}

--cs_025fc4e4-fd30-4372-8fa4-5b941ee66915--

--batch_5f3ccbef-11fe-4dcc-a546-02ba2e746d72--

should be:

--batch_5f3ccbef-11fe-4dcc-a546-02ba2e746d72

Content-Type: application/http

Content-Transfer-Encoding: binary

HTTP/1.1 400 Bad Request

RepeatabilityResult: accepted

Content-Type: application/json;charset=utf-8

{

"error" : {

"code" : "30063", "message" : {

"lang" : "en-US", "value" : "An entity instance with this key already exists."

}

}

}

--batch_5f3ccbef-11fe-4dcc-a546-02ba2e746d72--

This has now been fixed.

- A valid connection string and a statement must have been specified on the command line,

- The database server had to be unreachable when dbisql started

- The database server must then have become available as dbisql completeed its startup sequence

This has been fixed. If the database server is unavailable when dbisql initially attempts to connect, it will now simply shut down, rather than attempting to execute the given statement.

Also, if the server was shut down while a backup was in progress, the backup could have reported a protocol error. This has been fixed so that a "Database server not found" error is now returned.

Option

[producer-name].ServiceOperationsColumnNames = { generate | database }

Description

Specifies whether the names of the columns in the metadata should be generated (rtn1, rtn2, �) or whether the names from the database should be used. The default setting is generate.

There are some issues with this implementation:

- The encrypted password could have been used to authenticate to the database by anyone from any computer who also had the corresponding user ID.

- The ODBC Configuration for SQL Anywhere dialog of the ODBC Data Source Administrator (Windows-only) could have been used to return the encrypted password in clear text.

- The encrypted password could have been decrypted with some effort.

Encrypted password support has been enhanced with the following goals in mind:

- Ability to restrict use to a particular computer or a particular computer/user.

- Inability to reverse-engineer an encrypted password using the ODBC Configuration for SQL Anywhere dialog.

- Better encryption algorithms to ensure that the encrypted password cannot be decrypted.

- These enhancements to be available across all supported client platforms.

A password can be encrypted on a computer such that it can only be decrypted on that computer. Anyone who can log on to the computer can use the encrypted password and corresponding user ID to authenticate to a database. It cannot be used on any other computer.

A password can be encrypted on a computer by a user such that it can only be decrypted on that computer for that user. It cannot be used on any other computer by the same or other user.

The Data Source utility (dbdsn) supports a new option -pet a|c|u, a specifying how the encrypted password may be used. If -pet a is specified, the password is encrypted for use on any computer. If -pet c is specified, the password is encrypted for use on this computer only. If -pet u is specified, the password is encrypted for use on this computer by this user only. The -pe option which provides simple obfuscation continues to be supported; however, its use is deprecated.

Note that encryption for options -pet c and -pet u must be performed on the computer or computer/user for which it is intended to be used (decrypted).

Note also that -pet u is not appropriate for client applications that are implemented as Windows services. Although -pet u can be used for a Windows System DSN, it may be more appropriate to use -pet c (since this form of encrypted password can be used by any user of the computer).

The ODBC Data Source Administrator dialog is changed as follows:

- The Encrypt password option is no longer a checkbox but is now used to select from different encryption options including none, for use on any computer, for use on this computer only, and for use on this computer and this user only.

- The dialog can no longer be used to change the level of password encryption for an existing password, unless it was previously unencrypted. If the level of encryption is to be changed, then the password must be reentered.

The ODBC Configuration for SQL Anywhere driver for Oracle dialog is also modified accordingly.

These features allow a database administrator to restrict database access to a user on a particular computer without revealing the actual plain text password to the user. It also prevents the current password from being decrypted to memory and consequently subject to inspection.

When successful decryption is restricted to a particular computer or computer/user, it no longer matters that the encrypted password is presented in plain text. For example, the encrypted password in the following connection string cannot be used by anyone other than the computer/user for whom it was created.

dbping -d -c "Host=server-pc; Server=DemoServer; UID=DBA; ENP=05a17731bca92f97002100c39d906b70f3272fe76ad19c0e8bd452ad4f9ea9"

The new encrypted password features are not supported by client libraries prior to this change.

The File Hiding utility (dbfhide) options -wm (computer-only) and -w (computer/user-only) are now supported on all platforms for which dbfhide is available. The dbfhide tool can be used to encrypt an entire connection string to a file for use by most of the database tools that accept connection strings (e.g., dbping -d -c @credentials.hidden).

Note that the encrypted password support described here is a client feature (storage of passwords on the client) and should not be confused with encryption of passwords over the wire during authentication, a default feature of SAP SQL Anywhere and optional in products like SAP Adaptive Server Enterprise (ASE).

Other backend farm and server configuration can co-exist with auto_config=yes in the configuration file. Backend farms with farm-wide tokens can also be specified in the new token property of the [backend_farm] section in the Relay Server configuration file, so as to reserve the farm name before the Relay Server starts up.

This feature is suitable for demos, integration testing, training and other administration free environments.

Configurations created by this auto config feature can be further updated in on-line manner by using local rshost or remote AdminChannel. The auto_config property can also be changed in on-line manner using those tools

"A resource manager with the same identifier is already registered with the specified transaction coordinator. (Exception from HRESULT: 0x8004D102)"

This problem has now been fixed so that instead of a constant GUID, a new one is generated each time enlistment occurs.

- If no connection parameters were given, but a statement was given.

- If a READ statement or the name of a SQL file was given on the command line, and the file exists, but the file could not be read for any reason.

- If an error was encountered while reading the results of a statement.

This has now been corrected.

"RSF11020: Missing required section �<section-name>� in configuration file �<config-file-name>�"

This has been fixed.

- To identify a sargable predicate that could use an index scan.

- To improve the estimation of selectivity in order to make a better choice of access plan

For some types of queries that involved an OR or an IN list predicate, the first goal was satisfied reasonably well but the OR / IN list could have been retained, affecting selectivity estimation. In some cases, this could lead to underestimating the number of rows returned from a table scan, potentially leading to execution plans with higher costs.

This has been improved so that when multiple search conditions on a column contain an OR and/or an IN-list predicate, the predicate is simplified further.

CREATE PROCEDURE upload_insert_proc (

IN p_pk INT,

IN p_geo BLOB,

IN p_srid INT )

LANGUAGE SQLSCRIPT AS

BEGIN

IF :p_geo IS NULL THEN

INSERT INTO test (pk, c1) VALUES( :p_pk, NULL );

ELSE

INSERT INTO test (pk, c1) VALUES( :p_pk, ST_GeomFromWKB(:p_geo, :p_srid) );

END IF;

END;

for the upload_insert event, and

CREATE PROCEDURE upload_update_proc (

IN p_pk INT,

IN p_geo BLOB,

IN p_srid INT )

LANGUAGE SQLSCRIPT AS

BEGIN

IF :p_geo IS NULL THEN

UPDATE test SET c1 = NULL WHERE pk = :p_pk;

ELSE

UPDATE test SET c1 = ST_GeomFromWKB(:p_geo, :p_srid) WHERE pk = :p_pk;

END IF;

END;

for the upload_update event.

rc = SQLGetDiagField( htype, hndl, rec, SQL_DIAG_ROW_NUMBER,

(SQLPOINTER)&diagRow, SQL_IS_POINTER, NULL );

Also, diagnostic records for each row in error may have been returned in the wrong order by SQLGetDiagRec, since the wrong row number(s) were recorded.

rc = SQLGetDiagRec( htype, hndl, rec, sqlstate, &native_error,

errmsg, sizeof( errmsg ), &errmsglen );

These problems have now been corrected in the SQL Anywhere ODBC driver.

The ODBC specification says:

When SQLExecute returns either SQL_ERROR or SQL_SUCCESS_WITH_INFO, an associated SQLSTATE value can be obtained by calling SQLGetDiagRec with a HandleType of SQL_HANDLE_STMT and a Handle of StatementHandle.

The SQL Anywhere ODBC driver violates this rule since it does not create any diagnostic records. WITH_INFO generally means that some things succeeded and some things failed and diagnostic records (the 搃nfo�) let you determine what failed. When there was only one parameter set, a parameterized update or delete statement may have returned SQL_NO_DATA. If there was more than one parameter set, and some sets affected no records, then the SQL Anywhere ODBC driver returned SQL_SUCCESS_WITH_INFO (but did not create any diagnostic records). This was incorrect behavior. The driver should have returned SQL_SUCCESS.

Also, when all parameter sets fail to update or delete any rows, the ODBC driver should still have returned SQL_SUCCESS. The SQL Anywhere ODBC driver woud have set all non-updating parameter status array elements to SQL_PARAM_SUCCESS_WITH_INFO (except that the driver incorrectly cascaded the WITH_INFO status into all subsequent array elements). The ODBC driver did create diagnostic records for the WITH_INFO parameters. This was also incorrect behavior.

These problems have been corrected. The SQL Anywhere ODBC driver now follows the ODBC specification in this regard.

A workaround is to ensure that all rows touched by an ALTER have been fully updated inline. This can be done by issuing a pair of statements like the following:

alter table T add delete_me integer default autoincrement;

alter table T delete delete_me;

Snapshot queries over table T will now work correctly after these statements are executed.

For example, the query:

select geom from st_geometry_dump( new ST_LineString(new ST_Point(1,1,4326), new ST_Point(2,2,4326)))

incorrectly returned the rows:

LineString (1 1, 2 2)

Point (180 -.000000000000006)

Point (180 -33.690067525979835)

This has been fixed.

For example, the following query executed in 25.6s with the incorrect estimate 0.52% on L.row_num >= 0 (actual is 100%):

select *

from sa_rowgenerator(1,1.1727e6) L join sa_rowgenerator(1,34680) R on L.row_num = R.row_num

where (L.row_num >= 0, 0.52 )

options(User_estimates='On')

This has been improved so that performance is better even in the presence of underestimates:

Before change: 25.6

After change: 5.3

The graphical plan for hash-based query operators now includes lines to indicate how many key values the optimizer estimates will be found and the number of hash buckets selected for execution:

Key Values 6098.04

Hash table buckets 1031

Note, this issue also affects creating INSTEAD OF triggers with encrypted definitions on views as well.

Note, if a procedure returns a ROW or ARRAY typed column in its result set, the procedure needs to have a RESULT column. Changing the procedure to use Watcom SQL syntax may be required. Calling a procedure that returns a ROW or ARRAY typed column in its result set without a RESULT clause may now result in the error, "Procedure '<name>' needs a RESULT clause for returned ROW or ARRAY."

Note, the problem can avoided by disabling parallel query execution (i.e. set option PUBLIC.max_query_tasks=1), and can be made less likely by increasing the amount of memory available to the server.

If dbisql runs out of memory when copying results, there are a couple of things that can be done:

1. When running the 32-bit version of dbisql, run the 64-bit version instead. It allows for a larger heap, and is less likely to run out of memory.

2. Export the data using an OUTPUT statement, or the "Export Wizard", rather than copying results to the clipboard.

Note, this only affected results from some service operations when the output format was XML.

... dbcloudagent_poller_http_error message=[Error making HTTPS connection] code=4 reason=[Cannot resolve hostname or bad IP address]

This was a non-fatal error since the agent could continue working by polling the primary instead. This problem has been fixed.

1. Server crash

2. Server assertion failure

3. Incorrect error message (for example, -946 "Result set not permitted in '%1'")

This has been fixed.