Date: 02-15-2010 Subject: PATCH RELEASE 9.4 Runtime Files These release notes pertain to the following programs or files: EMBEDINI.EXE 9.4 15 Feb 2010 9,4,0,500 HEXDUMP.EXE 9.4 15 Feb 2010 9,4,0,500 MAKECLI.EXE 9.4 15 Feb 2010 9,4,0,500 MAKECON.EXE 9.4 15 Feb 2010 9,4,0,500 MAKECONET.EXE 9.4 15 Feb 2010 9,4,0,500 MAKEDEF.EXE 9.4 15 Feb 2010 9,4,0,500 MAKEMFD.EXE 9.4 15 Feb 2010 9,4,0,500 OBJMATCH.EXE 9.4 15 Feb 2010 9,4,0,500 PLBCGI.EXE 9.4 15 Feb 2010 9,4,0,600 PLBCLICON.EXE 9.4 15 Feb 2010 9,4,0,500 PLBCLIENT.EXE 9.4 15 Feb 2010 9,4,0,500 PLBCLINET.EXE 9.4 15 Feb 2010 9,4,0,500 PLBCMD.EXE 9.4 15 Feb 2010 9,4,0,500 PLBCON.EXE 9.4 15 Feb 2010 9,4,0,500 PLBCONET.EXE 9.4 15 Feb 2010 9,4,0,500 PLBDSIGN.EXE 9.4 15 Feb 2010 9,4,0,500 PLBNET.EXE 9.4 15 Feb 2010 9,4,0,500 PLBRUN.ZIP 9.4 15 Feb 2010 9,4,0,600 PLBSERVE.EXE 9.4 15 Feb 2010 9,4,0,500 PLBSERVET.EXE 9.4 15 Feb 2010 9,4,0,500 (Threaded Server) PLBWIN.EXE 9.4 15 Feb 2010 9,4,0,500 SETGUID.EXE 9.4 15 Feb 2010 9,4,0,500 SUNAAMDX.EXE 9.4 15 Feb 2010 9,4,0,500 SUNINDEX.EXE 9.4 15 Feb 2010 9,4,0,500 SUNLS.EXE 9.4 15 Feb 2010 9,4,0,500 SUNMOD.EXE 9.4 15 Feb 2010 9,4,0,500 SUNSORT.EXE 9.4 15 Feb 2010 9,4,0,500 ODSBAC32.DLL 9.4 15 Feb 2010 PLBNETSUP.DLL 9.4 15 Feb 2010 9,4,0,500 Required for PLBNET PLBWSEC.DLL 9.4 15 Feb 2010 9,4,0,500 Req'd PLBWIN/PLBNET SA_DLL32.DLL 9.4 15 Feb 2010 9,4,0,500 SUNWADO.DLL 9.4 15 Feb 2010 9,4,0,500 SUNWMSQL.DLL 9.4 15 Feb 2010 9,4,0,500 SUNWODBC.DLL 9.4 15 Feb 2010 9,4,0,500 SUNWSRV.DLL 9.4 15 Feb 2010 9,4,0,500 DBEXPLORER.PLC 9.4 15 Feb 2010 DBGIFACE.PLC 9.4 15 Feb 2010 DESIGNER.PLC 9.4 15 Feb 2010 EDITOR.PLC 9.4 15 Feb 2010 PLBCMP.PLC 9.4 15 Feb 2010 PLBDBUG.PLC 9.4 15 Feb 2010 PROFILER.PLC 9.4 15 Feb 2010 SUNIDE.PLC 9.4 15 Feb 2010 WATCH.PLC 9.4 15 Feb 2010 ADMEQU.INC 9.4 15 Feb 2010 PLBEQU.INC 9.4 15 Feb 2010 PLBMETH.INC 9.4 15 Feb 2010 SIDEMETH.CFG 9.4 15 Feb 2010 SIDESYN.CFG 9.4 15 Feb 2010 SIDEVRBS.CFG 9.4 15 Feb 2010 SQLVRBS.CFG 9.4 15 Feb 2010 SODBC2SCHDB.PLS *============================================================================== Notes of DEFINITIONS: SQLite Database A SQLite Database is a data file with a '.db' extension that has been created using the SQLite database engine. The SQLite database engine has been embedded into the Sunbelt products to allow dynamic creation and access to various tables created in a SQLite database file. Schema Database A Schema Database as implemented into the Sunbelt runtimes is a SQLite database file that contains the SQL table names 'sun_views', 'sun_columns', and 'sun_databases'. A Schema Database can be referenced by a Schema Name. Default Schema Database The Default Schema Database is opened/created for a Sunbelt runtime or Data Manager during the initial startup phase. The PLB_SCHEMA or DM_SCHEMA keywords can be used to specify a specific SQLite Database file that contains the SQL table names 'sun_views', 'sun_columns', and 'sun_databases'. If the PLB_SCHEMA or DM_SCHEMA keywords do not exist, a default Schema Database is opened/created as 'sunschema.db' for the runtime or Data Manager. SchemaName A SchemaName is a name that has been inserted into the 'sun_databases' SQL table in the Default Schema Database. The SchemaName can be used to reference a specific Schema Database assigned to the SchemaName that is to used for enhanced file IO and filtering. ViewName A ViewName is a name that has been inserted into the 'sun_views' SQL table found in a Schema Database. The ViewName is associated with a set of data found in the 'sun_columns' SQL table that also exists in the same Schema Database. The data in the 'sun_columns' SQL table is used dynamically by the Sunbelt runtimes to implement enhanced file IO and filtering for PLB user data files. *============================================================================== Notes for DOCUMENTATION: - The PAUSE instruction Note 5 description should be changed as follows: "5. Under PLBWIN, if an event is pending, the PAUSE instruction is ignored." - Modify the D202 error description to read as follows: D202 Error occurred while executing DBSEND. One possible cause of this error is buffer overflow. - Add a note number (4.) to the GetLine method as follows: 4. The GETLINE method of a RICHEDITTEXT object returns a line with a trailing CR (0x0D) character. The data for the line is retrieved directly from the Windows OS and returned without being modified in this case. - Change the DBSEND note number (4.) to read as follows: 4. In Windows, the maximum size of one query string is 1,048,576 characters. If the query list contains more characters than the maximum size of a query string, a D202 error is given. - Modify the LISTCNT documentation to indicate that a ZERO flag is affected by the execution of the instruction. Change as follows: Flags Affected: OVER and ZERO Add Note 4. 4. The ZERO flag is set TRUE if the value stored into the {dest} variable is a zero value. - When using the DBxxx instructions with the SQLite database engine, the following extended error codes can be reported. Error Codes 1 - SQL error or missing database. 2 - Internal logic error in SQLite. 3 - Access permission denied. 4 - Callback routine requested an abort. 5 - The database file is locked. 6 - A table in the database is locked. 7 - A malloc failed. 8 - Attempt to write a readonly database. 9 - Operation terminated by sqlite3_interrupt. 10 - Some kind of disk I/O error occurred. 11 - The database disk image is malformed. 12 - NOT USED. Table or record not found. 13 - Insertion failed because database is full. 14 - Unable to open the database file. 15 - NOT USED. Database lock protocol error. 16 - Database is empty. 17 - The database schema changed. 18 - String or BLOB exceeds size limit. 19 - Abort due to constraint violation. 20 - Data type mismatch. 21 - Library used incorrectly. 22 - Uses OS features not supported on host. 23 - Authorization denied. 24 - Auxiliary database format error. 25 - 2nd parameter to sqlite3_bind out of range. 26 - File opened that is not a database file. - A new error I85 has been added to the PLB Language. The I85 error can occur for any instructions that are using a PLB Schema. I85 - An error has occurred for an instruction that is using or requires a PLB Schema. The following subcodes can occur: Subcodes 100 - Column/field name not found 101 - Partial IO is not allowed 102 - Out of memory 103 - Filter expression is too large. A filter expression size must be less than 4097 characters. 104 - The filter expression is invalid. 105 - The Data Manager being accessed does not support PLB Schemas required for filtering or enhanced column/field name IO syntax. 106 - Column name is missing. 107 - Field size value is invalid. 108 - Field offset value is invalid. 109 - Field id value is invalid. 110 - Field type value is invalid. The value must be one of the following: 0 - DIM 1 - FORM 2 - INTEGER 111 - Field scale value is invalid. 112 - Field array count value is invalid. 113 - Field SQL Type value is invalid. 114 - Field Primary value is invalid. 115 - Field Nullable value is invalid. 116 - Field ZeroFill value is invalid. 117 - Field EmptyNull value is invalid. 118 - Field Selectivity value is invalid. 119 - Invalid schema name. The schema name string size is larger than 255. 120 - Default value string is too large. The default value string size must be less than 1024. 121 - Invalid or missing view name. 122 - Unable to load/access a VIEW name in a schema database. 123 - No VIEW is associated with a file variable. 124 - Column was NULL on WRITE. A column defined in the current view has the Nullable state set to be zero. In this case, the column must be specified in the WRITE instruction or there must a Default value specified for the column in the schema column specifications. 125 - Invalid view stream data has been encountered transferring view data to/from a Data Manager. 126 - Unable to find a schema database. 127 - It is invalid to overlap field offsets for columns defined in a view. 128 - A duplicate view name as been encountered while adding a new view. The previous view must be removed before a new view can be added with the same view name. 129 - Unable to insert view into the 'sun_views' table in a schema database. 130 - Schema support is not available. The following subcodes can occur when processing XML data for operations involving a schema database. 201 - A write operation has already been started. 202 - Unable to create specified XML file. 203 - Unable to open specified XML file. 204 - Unable to create XML parser. 205 - Out of memory. 206 - Attempt to write an attribute on an closed element. 207 - Tag name too long. 208 - Invalid tag name. 209 - XML data too large. 210 - XML file too large for memory area. 211 - File write error. 212 - Internal state error. 213 - No element open. 214 - Internal state error. 215 - Attribute not open. 216 - Error detected parsing XML data file. - SQLite Overview The SQLite embedded database engine is one of the most widely deployed database engines in the world. It is a self-contained engine that requires minimal external interfaces to be used. By being self-contained it does not have to rely on specific OS behaviors or specialize infrastructures to work. There is zero configuration requirements to get it started and it does not require a server to be used. The SQLite database file format allows for cross-platform support. An SQLite database file can be copied between big-endian and little- endian architectures. The SQLite database engine is very popular and has a very rich history with a strong user base that has many third party tools that can be use. Here are some of the strong features that has made it a viable enhancement to the Sunbelt products. - Public domain source 'www.sqlite.org' - No intermediary server process - Databases are in a single file - Databases can be memory based - There is zero configuration - Implements SQL-92 standard - Very fast performance - Embedded in many third party products - Very popular world wide with a strong user base - Third party tools available - Feature rich API set that can minimize development for PLB. - Schema Overview The SQLite database engine has been embedded in the Sunbelt products to enhance the overall operations for the PLB Language. By developing a schema database, end-user record layouts can be defined in SQL tables. A schema database must contain internal tables named 'sun_views', 'sun_columns', and 'sun_databases'. The data inserted into these tables is used by the Sunbelt products to provide enhanced functionality that includes PLB IO using column names and record filtering. A basic description of these tables is as follows: Schema Table 'sun_views' The 'sun_views' is a SQL table that is created/opened in a SQLite database that a runtime has access to. The intent of this table is to contain data that gives an identification and name for record layout views. The view names specified in this table are not case sensitive. A PLB program can specify a Viewname in an OPEN or PREPARE instruction. The file variable is then associated with the view data layout to perform file IO operations. The following column names are defined in the 'sun_views' table. id This column is a unique number that identifies a view record layout. This 'id' column value is used to uniquely identify column data found in the 'sun_columns' table. The id column is a pseudo column whose value is a unique number assigned by the SQLite database engine when a row is inserted into a table. The id column can not be changed by an end-user. The SQL data type for this column is 'integer primary key'. name This column contains a name for a view record layout. The view name can be specified in a OPEN or PREPARE instruction when a PLB program executes. This name is not case sensitive. The SQL data type for this column is 'text not null unique'. description This column contains text that describes the schema record layout view that has been specified. The SQL data type for this column is 'text'. Schema Table 'sun_columns' The 'sun_columns' is a SQL table that is created/opened in a SQLite database that a runtime has access to. The intent of this table is to contain data that defines the column information to access/use a field in a PLB data file record. The view 'id' from the 'sun_views' table uniquely ties each column data row to a view name that a user program is using. The following column names are defined in the 'sun_columns' table. id This column is a unique number that identifies this column that defines the parameters to access/use a field in a view record layout. This 'id' value is used by a PLB runtime to process the data for this view record field. The id column is a pseudo column whose value is a unique number assigned by the SQLite database engine when a row is inserted into a table. The id column can not be changed by an end-user. The SQL data type for this column is 'integer primary key'. view_id This column is the same as the 'id' found in the 'sun_views' table. This column is used to associate a specific view name to this column definition that has been inserted into the 'sun_columns' table. The SQL data type for this column is 'integer'. name This column contains a name for this view record layout field that is defined. The column name can be specified in PLB IO instructions (READ, WRITE, and UPDATE). In addition, this column name can be specified in a filter expression that is assigned using the FILTER instruction. This column name is not case sensitive. The runtime uses this column name to process column field parameters as defined in 'sun_columns' table. The SQL data type for this column is 'text not null'. description This column contains text that describes the schema database column that has been specified. The SQL data type type for this column is 'text'. type This column is a number that gives the basic PLB data type that is used for this column field definition. The SQL data type for this column is 'integer'. The acceptable values for this column are as follows: 0 - DIM variable 1 - FORM variable 2 - INTEGER variable offset This column is a number that gives the one relative offset in a record where the field is located. The SQL data type for this column is 'integer'. length This column is a number that gives the length for the field in a record. This value is the total length of the field. In the case of a FORM variable, the total length includes the whole digits, a decimal point if used, and the decimal digits to the right a decimal point if used. The SQL data type for this column is 'integer'. scale This column is a number that gives the number of decimal digits to the right of a decimal in a FORM variable. If this value is '-1', the FORM is to have a decimal point with any fractional digits. Otherwise, this value can be from 0 to the maximum number of fractional digits allowed for a PLB FORM variable. The SQL data type forthis column is 'integer'. element_count This column is a number that gives the number sequential fields assigned to this PLB field definition. The default number is 1. This number corresponds to the number of variables declared for a PLB array. The SQL data type for this column is 'integer'. sql_type Required for ODBC driver to be implemented at a later time. The SQL data type for this column is 'integer'. key_value Required for ODBC driver to be implemented at a later time. The SQL data type for this column is 'integer'. nullable This column is a number that defines whether the PLB field can be null or not. If the nullable value is zero, the PLB field must be included in a WRITE instruction or the schema Default specification for the PLB field must be defined. If the nullable value is non-zero, the PLB field does not have to be included in a WRITE instruction. The SQL data type for this column is 'integer'. zero_fill Required for ODBC driver to be implemented at a later time. The SQL data type for this column is 'integer'. empty_null Required for ODBC driver to be implemented at a later time. The SQL data type for this column is 'integer'. selectivity Required for ODBC driver to be implemented at a later time. The SQL data type for this column is 'integer'. format_mask Required for ODBC driver to be implemented at a later time. The SQL data type for this column is 'integer'. default_value This column is intended to contain a default value that is to be written when column names are being used in a WRITE instruction and the PLB column name for this field is not included in the PLB variable list. If the 'default_value' is empty, blanks or zeros are written as a default depending on the PLB variable type. Otherwise, the 'default_value' data is written. The SQL data type for this column is 'text'. Schema Table 'sun_databases' The 'sun_databases' is a SQL table that is created/opened in a SQLite database that a runtime has access to. The intent of this table is to contain data that associates a unique schema database name to a physical SQLite database file which includes the 'sun_views' and 'sun_columns' detail tables used for schemas by the runtime. The PLB program can specify the schema name when using the SCHEMA instruction as well as when a VIEW name is being specified in an OPEN or PREPARE instruction. The runtimes use a schema name to access the 'sun_databases' table to determine the physical SQLite database file and its location to be accessed. Please note that if the PLB program does not specify a database name, then the default database for the runtime is used. id This column is a unique number that identifies the schema database name. The id column is a pseudo column whose value is a unique number assigned by the SQLite database engine when a row is inserted into a table. The id column can not be changed by an end-user. The SQL data type for this column is 'integer primary key'. name This column contains a name for the schema database that can be specified in a SCHEMA, OPEN, or PREPARE instruction. This name is not case sensitive and allows a program to uniquely access/use specific SQLite databases for program operations. The SQL data type for this column is 'text not null unique'. description This column contains text that describes the schema database that has been specified. The SQL data type for this column is 'text'. databasefile This column contains a path and filename for a SQLite database that is to be access/used. The runtime uses this physical SQLite database file when a PLB program specifies the schema name. The SQL data type for this column is 'text'. - PLB Schema Getting Started Before the PLB file IO using the column name and filtering enhancements can be used in an end-user application, the record layout for fields that includes field names for referencing, field types, and the field locations in the records must be specified in a PLB schema. The schema information is to be placed into the 'sun_views', 'sun_columns', and the 'sun_databases' tables in a SQLite database. All of the schema information defined in these tables is grouped and referenced in the PLB programs as PLB view names. The data definitions for a PLB view are used by the PLB runtimes to map field name references to the new column name format support in READ, WRITE, and UPDATE instructions in addition to the field name references used in the new FILTER instruction. There are basic areas to be considered when getting started as follows: I. Record/Field Layout II. Methods for loading PLB Schemas III. PLB Schema Creation IV. PLB Schema Usage I. Record/Field Layout 1. Determine all of the PLB data files that are to be included in a PLB schema database. 2. For each file that is to be included in a schema, retrieve the following information for each field in the file records: - Field Name to be referenced. ( Limited to 63 characters ) - Offset of field in the record. ( 1st field is 0 offset ) - Total length of field in the record. ( Must be > 0 ) - Type of field. ( 0 - DIM, 1 - FORM, 2 - INTEGER ) - Element Count. ( 1 - Single element, >1 - Array count ) 3. Using the collected data, the information is arranged into PLB data views that are to be put into the 'sun_views' and 'sun_columns' SQL tables that are created in a schema database. II. Methods for Loading PLB Schemas There are three basic methods that can be used to initialize or load the data into a PLB Schema as follows: 1. Use the PLB DBxxx instructions to access the PLB schema database using the 'SQLITE' database host name. The DBxxx instructions can be used to create the PLB schema tables and insert the PLB schema data as needed. The DB instructions can execute SQL statements to initialize and/or load the PLB schema data. Example SQL Statements: SQL statement to create 'sun_views' "Create table sun_views ( id integer primary key, name text not null unique, description text );" In this case, the 'sun_views' table is created in the schema database with three columns named 'id', 'name', and 'description'. SQL statement to insert a view name into 'sun_views' table "Insert into sun_views ( name, description ) Values ( 'product', '' );" In this case, the PLB view name 'product' is inserted into the 'sun_views' schema table. SQL statement to retrieve the 'id' number for a view name "Select id from sun_views where upper(name) = upper('product');" In this case, the 'id' value is retrieved for the 'product' view name from the 'sun_views' table. SQL statement to create 'sun_columns' "Create table sun_columns ( id integer primary key, view_id integer, name text not null, description text, type integer, offset integer, length integer, scale integer, element_count integer, sql_type integer, key_value integer, nullable integer, zero_fill integer, empty_null integer, selectivity integer, format_mask text, default_value text );" In this case, the 'sun_columns' table is created in the schema database with seventeen columns that are used to contain the PLB schema field data. SQL statement to insert column data into 'sun_columns' "Insert into sun_columns ( view_id, name, description, type, offset, length, scale, element_count, sql_type, key_value, nullable, zero_fill, empty_null, selectivity, format_mask, default_value, description ) Values ( 1, 'SHIPWT', '', 0, 102, 5, 0, 1, 0, 0, 1, 0, 0, 0, '', '' );" In this case, the column field named 'SHIPWT' is inserted into the 'sun_columns' schema table. The schema data is inserted as follows: view_id = 1 (value same as view 'id') name = 'SHIPWT' (column/field name) description = '' ( Empty ) type = 0 (DIM type) offset = 102 (Offset in record) length = 5 (Length of field) scale = 0 (Not used for DIM) element_count = 1 (Single element) sql_type = 0 (Used only for ODBC) key_value = 0 (Used only for ODBC) nullable = 1 (Field data can be null) zero_fill = 0 (Used only for ODBC) empty_null = 0 (Used only for ODBC) selectivity = 0 format_mask = '' ( Empty ) default_value = '' ( Empty ) 2. The PLB Language support using the instructions for XFILE variables can be used to create an XML data file or data stream data stream that can then be loaded into a PLB Schema database using the SCHEMA IMPORT instruction. The following is a sample of the XML data format used for a PLB Schema: Example PLB Schema XML format: Customer FieldName1 0 5 0 0 1 0 0 0 1 1 100 FieldName2 5 6 0 0 1 0 0 0 1 1 100 Note: 1. More than one view can be defined in the same xml schema data stream. 2. When creating all of the column/field schema data, all of of the data schema tag items are required and must be declared. 3. The PLB DBExplorer utility can be used to examine and modify a PLB Schema. This utility can be used to create the required SQL tables and insert the PLB schema data into these tables that defines the PLB schema views and field definitions. The DBExplorer can be use to execute SQL statements directly for the PLB Schema database. III. PLB Schema Creation A PLB Schema is a SQLite database that includes the 'sun_views', 'sun_columns', and 'sun_database' tables. The information collected in the record/field layout needs to be put into the PLB Schema as follows: 1. Select method of loading PLB Schema data. 2. Select a SQLite database to be used for a PLB Schema 3. Create PLB Schema tables in the SQLite database. 4. Insert a data row into the 'sun_views' table for each PLB data view to be defined. 5. Insert multiple column/field rows into the 'sun_columns' table for each PLB data view that has been defined. 6. If the end-user has application specific schema databases to be used in a PLB program, then insert the PLB Schema database names into the 'sun_databases'. IV. PLB Schema Usage After the PLB Schema database has been created with the required SQL tables named 'sun_views', 'sun_columns', and 'sun_databases' and the collected column/field schema data has been inserted, the end-user application can start using the new column name syntax for the READ, WRITE, and UPDATE instructions and start using the new FILTER instruction. A general overview to start using a PLB Schema in a PLB program is as follows: 1. Before PLB data views can be used, they must exist in the in a PLB Schema database. The PLB data views can exist in the default schema for a runtime or in some other database that is specific to a PLB application. 2. Assuming that the default PLB Schema database for a runtime has been loaded with the Schema data, the end-user application must first OPEN/PREPARE a FILE, AFILE, or IFILE with a 'VIEW={viewname}' specified. Example of OPEN/PREPARE with VIEW IFILE IFILE CID DIM 5 ADR DIM 21 . OPEN IFILE, "myifile", VIEW="Customer" In this case, the data file 'myifile' is a normal ISI file that is being accessed. The 'Customer' is a PLB data view name that can be found in the 'sun_views' table in the default Schema database for the runtime that is executing the OPEN instruction. The 'Customer' data view column/field information can be found in the 'sun_columns' table in the default Schema database. 3. After a FILE, AFILE, or IFILE has been OPENed or PREPAREd with a 'VIEW={viewname}' specified, the program can use the new column/field name syntax for the READ, WRITE, and UPDATE instructions. The column/field name reference that is put into the instruction variable list must be defined in the 'sun_columns' schema table being used for the {viewname} that was specified on the OPEN or PREPARE instruction. Example of READ using column/field names from VIEW IFILE IFILE CID DIM 5 ADR DIM 21 KEY DIM 5 . OPEN IFILE, "myifile", VIEW="Customer" ... MOVE "mykey", KEY ... READ IFILE,KEY; ADDRESS=ADR,CUSTID=CID In this case, the READ instruction is to retrieve data for two columns/fields that are named 'ADDRESS' and 'CUSTID'. The runtime determines the location of these columns / fields in the file record and the corresponding field data is returned in the program variables. Also notice, that an I85 error occurs if the column/field name syntax is used and the file variable being used does not have a VIEW specified. 4. Again assuming that a file variable has been OPENed or PREPAREd with a 'VIEW={viewname}', a PLB program can use the column/field names defined in the 'sun_columns' table for the {viewname} in the FILTER instruction. The FILTER instruction specifies a filter expression that can consists of column/field names, operators, and values. When a filter expression is assigned to a file variable, the runtime applies it to the data before a record is returned to READ instruction. If the record data does not pass the filter expression, then the READ operation continues until a record is found that satisfies the filter expression. If there are no records that satisfies the filter expression, then the OVER flag is set for the READ. Filter expressions can be set on a file variable any number of times after the file variable has been opened or prepared with a VIEW. If a column/field name is used in a filter expression that is not defined in the file variable PLB VIEW, an I85 error occurs. Filter expressions only affect READ instructions. They do not affect the operation of any other file IO instructions. Example of READ using filter expression IFILE IFILE CID DIM 5 ADR DIM 21 KEY DIM 5 . OPEN IFILE, "myifile", VIEW="Customer" FILTER IFILE, "POSTALCODE = '75076'" ... MOVE "mykey", KEY ... READ IFILE,KEY; ADDRESS=ADR,CUSTID=CID In this case, the isam READ instruction executes to find records that have the specific key 'mykey' and the 'POSTALCODE' value is equal to '75076'. The READ only returns record data when both of these conditions are satisfied. Otherwise, the READ give an OVER condition. Also, the filter expression can be used on READ instructions that do not use the column/field name syntax for the READ instructions. - Update the Sunaccess function descriptions for functions with 64 bit data types for parameters as follows: int SA_TxtRead ( SA_FH TxtFH, u8 *Buffer, u32 BufLen, s64 Method ); int SA_TxtWrite ( SA_FH TxtFH, u8 *Buffer, u32 BufLen, s64 Method ); int SA_TxtDelete ( SA_FH TxtFH, u64 Record ); s64 SA_GetFilePosit ( SA_FH TxtFH, u32 posMode ); s64 SA_PositEndOfFile ( SA_FH TxtFH ); int SA_RepositFile ( SA_FH TxtFH, s64 position, u32 posMode ); int SA_WriteEndOfFile ( SA_FH TxtFH, s64 record ); Note: 1. The general descriptions of these functions are the same as currently provided in the sunaccess documentation. The only difference is that some function parameters have 64 bit data types. - Add Sunaccess function descriptions for the new 32 bit functions used to support applications that do not have 64 bit data types. int SA_TxtRead32 ( SA_FH TxtFH, u8 *Buffer, u32 BufLen, u32 Method ); int SA_TxtWrite32 ( SA_FH TxtFH, u8 *Buffer, u32 BufLen, u32 Method ); int SA_TxtDelete32 ( SA_FH TxtFH, u32 Record ); s32 SA_GetFilePosit32 ( SA_FH TxtFH, u32 posMode ); s32 SA_PositEndOfFile32 ( SA_FH TxtFH ); int SA_RepositFile32 ( SA_FH TxtFH, u32 position, u32 posMode ); int SA_WriteEndOfFile32 ( SA_FH TxtFH, u32 record ); Note: 1. The general descriptions of these functions are the same as currently provided in the sunaccess documentation. The only difference is that that function names have been changed. - The sunaccess documentation for the Visual Basic example should be changed to use the SA_TxtWrite32, SA_TxtRead32, and SA_RepositFile32 functions. This change is needed because VB6 does not support 64 bit data types. - Add a note to the READ AFILE section to describe that a schema filter expression with OR selection conditions can be applied to the AFILE. Before an AAM record is returned in the READ AFILE instruction, the AAM key(s) must be satisfied along with any of the schema filter OR conditions as specified in the filter expression. *============================================================================== The following files have been changed as noted: ------------------------------------------------------------------------------- PLBWIN, PLBNET - Added a new event named 'Suspend' for the WINDOW object. This event is generated from the Windows OS WM_POWERBROADCAST event. When the WM_POWERBROADCAST event with a suspend or resume state is detected, a PLB 'Suspend' user event is generated if it has been registered for a WINDOW object. Note: 1. The Event Result value for the 'Suspend' event is set to one of the following values: 0x00000004 - System is suspending operation. 0x00000007 - Operation resuming after suspension. These events are not available from the OS until the Windows OS resumes operations. 2. The Suspend event is referenced using an event value of thirty-one (32). The equated label in PLBEQU.INC for this event is $SUSPEND. 3. This event helps in situations where a user program wants to detect when a program is restarting from a suspended state. A program may need to re-initialize connects in such situations. - Changes for the GETFNAME instruction that was made in release 9.3C caused a problem where an UNC path/name would always returned an OVER flag set to be TRUE with an overflow message. The GETFNAME instruction has been modified to detect a UNC path/name that is being returned to the user program. ------------------------------------------------------------------------------- PLBWIN, PLBNET, PLBSERVE, PLB(UNIX) - Support for the SQLite database engine has been implemented into the runtimes to enhance the PLB Language functionality. This embedded database can be used directly using the DB statements from a PLB program. Also, it is used to support PLB Schemas used to enhance file IO. Over time, the embedded database engine use will be expanded to provide dynamic configurations and operations for the Sunbelt products. DB Statements An end-user PLB program can access the embedded SQLite database engine directly using the standard DBxxx instructions. To use the DBCONNECT instruction to logon to the embedded SQLite database engine, the {host} parameter can be specified with the set to be 'SQLITE'. An example {host} parameter string would be 'SQLITE;;mydata.db'. After a connection as been established to the embedded SQLite database engine, then normal DBxxx instructions can be used to execute SQL statements to create and access tables as expected for database engine. From a user perspective, there is no tedious configurations or setup actions required to use the embedded SQLite database engine. It is simply available to be used by any PLB program on any workstation as needed. Schema Database The embedded SQLite database engine has been embedded/implemented into the PLB runtimes to enhance the PLB file IO. To support the file IO enhancements, schema database tables have been developed where the PLB file IO statements in the runtimes can access schema information that defines the record layouts in PLB data files. A Sunbelt runtime has a default schema database that is named 'sunschema.db'. This default schema database is located in the same directory where the runtime is located. The PLB_SCHEMA keyword can be used to set the default schema database when a runtime is initially loaded. A schema database must include special internal SQL tables named 'sun_views', 'sun_columns', and 'sun_databases' required to contain various record layouts that are referred to as 'views'. A new instruction named 'SCHEMA' has been added to support schema database information that is required to support the PLB Language. Also, note that the PLB_SCHEMA keyword using the PLB(Unix) runtime can be put into the UET. Enhanced File IO By using a VIEW that is defined in a schema database, the PLB file IO instructions have been expanded to allow COLUMN names to be used in the variable list to identify the data fields that are accessed in records. In addition, the READ instructions have been expanded to support record filtering. A new instruction named 'FILTER' has been added to enable or disable filtering for individual file variables. When a filtering expression has been assigned to a file variable, a READ instruction evaluates the filter expression before the data from the record is returned to an end-user READ operation. In order to used either the COLUMN name syntax or READ record filtering, a record layout VIEW must be assigned to a file variable when the file variable is opened or prepared. - Added a new instruction named COUNTKEYS. This instruction counts keys in an ISI file from a starting key to an ending key that have been specified. The key count is returned. This instruction uses the following format: [label] COUNTKEYS {ifile}{sep}{startkey}{sep}{endkey}{sep1}{keycount} Where: label Optional. A Program Execution Label ifile Required. A previously defined IFILE variable that has been successfully opened. sep Required. A comma or one of the following prepositions: BY, TO, OF, FROM, USING, WITH, IN, or INTO. sep1 Required. A comma or one of the following prepositions: BY, TO, OF, FROM, USING, WITH, IN, INTO, or GIVING. startkey Required. A previously defined Character String Variable that contains the key to start counting from inclusively. endkey Required. A previously defined Character String Variable that contains the key to stop counting at inclusively. keycount Required. A previously defined Numeric Variable where the number of keys that have been counted is stored. Flags Affected: OVER, ZERO Note the following: 1. If the {keycount} is equal to zero, the ZERO (or EQUAL) Condition Flag is set (TRUE). 2. If {keycount} is too small to contain the count, the OVER Condition Flag is set (TRUE). 3. The {startkey} and {endkey} should contain the 'key data' that would be expected when performing a normal READ IFILE keyed read operation. 4. The COUNTKEYS instruction applies normal file locking techniques the same as if a normal READ IFILE were being executed. This unsures the integrity of the ISI file while isam keys are being counted. Examples: IFILE IFILE StartKey INIT "00000" EndKey INIT "99999" KeyCount FORM 8 . OPEN IFILE, ... ... COUNTKEYS IFILE FROM StartKey To EndKey GIVING KeyCount ... COUNTKEYS IFILE, StartKey, EndKey, KeyCount - Added a new instruction named FILTER. This instruction sets up a filtering string that contains an expression of conditions that are to be used when any read operation is executed for a FILE, AFILE, or IFILE variable. The read operation only retrieves records that satisfy the conditions of the filtering string. This instruction uses the following format: [label] FILTER {file}{sep}{filter}[, FLAGS={flagvalue}] Where: label Optional. A Program Execution Label file Required. A previously defined FILE, AFILE, or IFILE variable that has been successfully opened. sep Required. A comma or one of the following prepositions: BY, TO, OF, FROM, USING, WITH, IN, or INTO. filter Required. A previously defined Character String Variable or Literal that contains the expression of access conditions to be applied when the {file} variable is being read. flagvalue Optional. A previously defined Numerical variable or decimal number whose value is used as a bit mask to allow specialized behavior for the FILTER instruction. The {flagvalue} requires a the keyword named 'FLAGS'. Flags Affected: None Note the following: 1. The record filter query string consists of one or more expressions separated by logical operators. 2. An expression consists of a field name, an operator, and a value. The operators supported are =, <>, <, <=, >, >= and LIKE (as in SQL syntax). The values can be either a quoted string for a string match, or a numeric value for a numeric comparison. 3. The logical operators are OR, AND, and NOT 4. The record filter expressions can include the unary operators named NOCASE and OVER. These operators are defined as follows: NOCASE This unary operator causes all string comparisons to be case insensitive. Example for usage: FILTER IFILE, "NOCASE( CompanyName = 'bill' )" In this case, the string comparison for the CompanyName field is not case sensitive. OVER This unary operator causes the PLB OVER flag to be set TRUE when the affected expression evaluates to be FALSE. The intended use of the OVER unary operator is to prevent unnecessary file io actions while filtering records. Example for usage: FILTER IFILE, "OVER( CustID = 'PICAF' )" In this case, the PLB program OVER flag is set to be TRUE when the CustID field does not equal the 'PICAF' string value. 5. Expressions can be grouped by using the ( and ) characters. 6. The LIKE operator performs a pattern matching string comparison where an underscore (_) matches any one character, a % matches zero or more characters, and the backslash (\) is the forcing character. 7. At this time, the {flagvalue} bit mask value does not have any bit mask values for specialized FILTER instruction behavior. Examples: IFILE IFILE KEY INIT "mykey" . OPEN IFILE, ... ... FILTER IFILE, "CompanyName = 'Bill' AND ID = 10" ... FILTER IFILE, "CompanyName LIKE '%Bill%'" - Added a new option keyword named '*OPENSSL' for the MAILSEND instruction. The OPENSSL keyword enables the SSL ( Secure Sockets Layer ) support if the OpenSSL libraries have been installed on the Workstation where the PLB runtime is executing. Note: 1. Private certificates are not supported. 2. It is the user's responsibility to keep the latest OpenSSL libraries up to date for any enhancements and bug fixes in the libraries. 3. A MAILSEND error 99 with a subcode 64 or 65 occurs if the *OPENSSL keyword is used and an error occurs accessing/using the OpenSSL libraries. MAILSEND Error New Error 99 - Unable to open connection using OpenSSL. New SubCode 64 - Unable to load the OpenSSL libraries. 65 - Unable to create a SSL connection using the OpenSSL libraries. 4. SSL is a public key encryption algorithm. An SSL server process has a key pair, a private key and a public key. The public part of the key is freely distributable to encrypt data. The data cannot be decrypted with the public key. The private key that is kept secret on the server is what is required to decrypt the data. When an SSL client connects to an SSL server, the server gives the public key to the client as part of the normal SSL connection process. Because of the way this works, no default encryption key exists on the client because the public key cannot be used to decrypt data. - Added a new instruction named SCHEMA. This instruction is used to execute operations specialized to the runtime schema support. This instruction uses the following format: [label] SCHEMA {name[|ipaddr]},{keyword}={value}[,{keyword=value}...] Where: label Optional. A Program Execution Label. name Required. A previously defined Character String Variable or a literal that specifies the database/schema to be accessed. The 'ipaddr' is optional and if specified redirects the execution of the SCHEMA instruction to the Data Manager. The 'ipaddr' can be a URL or a TCPIP:PORT address. keyword Optional. One of the valid keywords defined below. value Required. A previously defined Character String Variable or Numeric Variable used by the keyword. Flags Affected: None Note the following: 1. The following keywords are supported for the SCHEMA instruction. EXPORT={svar} This keyword extracts the schema information from the schema identified by the {name} parameter. If the {svar} is NULL on input, the schema information is stored into the {svar} variable. If the {svar} is not NULL on input, the {svar} data specifies a path/filename where the schema data is stored. The export action only outputs the internal runtime schema information as described in the 'Schema Overview' section. IMPORT={svar} This keyword imports schema information from the {svar} variable or from a path/filename that the {svar} string identifies. All of the {svar} schema information is replaced in this case. The import action only inputs the internal runtime schema information as described in the 'Schema Overview' section. FLAGS={dnumnvarlit} This keyword value is a bit mask that changes the execution behavior for the SCHEMA instruction. The bit mask values are defined as follows: Bit Mask Value Behavior 0x00000001 - This bit causes the IMPORT action to append the schema information without initializing previously defined view data. An I85 error with a 128 subcode occurs when a view in the import file already exists in the database. 0x00000002 - This bit causes the IMPORT action to replace the view data in a schema database. This action is performed by deleting a previously defined view and re-inserting the view data from the import data file. 2. If the schema {name} has the 'ipaddr' address specified, any data files used for an EXPORT or IMPORT are accessed at the server where the Data Manager is executing. COPYFILE can be use to store/retrieve schema data files to/from the Data Manager. - Added a new keyword named 'SCHEMAINFO={svar}' to the GETFILE instruction. The schema information associated with the GETFILE {file} variable is retrieved and stored into the {svar} variable. The schema data is stored XML format. - Added a new keyword named 'QUERYCOLCOUNT={nvar}' to the GETFILE instruction. This keyword returns the number of columns included in the last query result set when using a SQLite database. When there is no last query result set, a zero value is returned. The file variable for the GETFILE instruction can be a DBFILE or DBSTATEMENT reference. - Added a new keyword named 'QUERYCOLNAMES={svar}' to the GETFILE instruction. This keyword returns the column names that are included in the last query result set when using a SQLite database. When there is no last query result set, a null {svar} variable is returned. The file variable for the GETFILE instruction can be a DBFILE or DBSTATEMENT reference. The column names are returned in the {svar} variable as comma delimited names. - Added a new keyword named 'VIEW={svar}' to the GETFILE instruction. This keyword returns the current view name that has been assigned to an AFILE, IFILE, or FILE variable. If there is no view name assigned to the file variable, the {svar} variable is set to be NULL. Otherwise, the {svar} contains the current view name assigned to the file variable. - Added a new keyword named 'VIEW={svarslit}' to the SETFILE instruction. This keyword can be used to assign a view name that exist in a schema database to an AFILE, IFILE, or FILE variable. If the {svarslit} is NULL, the SETFILE removes the current assigned view name from the file variable. Otherwise, the {svarslit} view name is assigned to the file variable as the current view after a previously assigned view has been removed. If the {svarslit} view name does not exist in the schema database, an appropriate I85 error is generated. - Added a new runtime keyword named 'PLB_DMKEEPACTIVE={ON|OFF}'. This keyword must be put into the 'Environment' section of the runtime INI file to take affect. If this keyword is set to the 'ON' state, the default action for keeping Data Manager connections active is the same as when a 'SETMODE *DMKEEPACIVE=1' instruction is executed. Otherwise, the default action is the same as when a 'SETMODE *DMKEEPACTIVE=0' instruction is execute. - Added a new keyword named 'PLB_SCHEMA={defaultdatabase}' that can be can be added to the [environment] section of the runtime INI file. This keyword can be used to declare the default database file to used by the runtime. The {defaultdatabase} can include the full path and database name to be used as the default database for a runtime. If this keyword is not used, the default database filename is 'sunschema.db'. The 'sunschema.db' default data file is created or opened in the same directory at the runtime executable. - Increased the DBSEND buffer from 65,535 to 1,048,576 characters. - Modified an Isam WRITE instruction to update the isam tree stack when 'Greater Than' Sector is allocated and linked to the root sector. This change is being made to prevent an I63 error on a READKS instruction after an WRITE IFILE operation. Note: 1. As a general comment, there is no specification/documentation that a READKS can be executed after a WRITE IFILE with expected results. The fact that it does work to the level that it does is because the isam WRITE operation has to do an internal operation to position to the key location where the WRITE IFILE key is to be inserted. A change has been made for an Isam WRTIE to work around the I63 error as reported. However, executing a READKS instruction after a WRITE IFILE is not good programming practice. - Corrected a GPF error that would occur when the DBSEND buffer overflowed. The DBSEND buffer size is now limited to 1,048,576 bytes. If a buffer overflow is detected a D202 error now occurs. - Corrected a problem where an INDEX instruction using the '-R' option was causing a S13 error with a subcode 100. - Corrected a problem where the INDEX instruction could cause an invalid handle to be used from an 'open' operation. This could cause indeterminate execution when using the '-r' or '-i' options. - Corrected a problem where a second copyfile without encryption would encrypt it's data when it was executed after a previous copyfile that used encryption. ------------------------------------------------------------------------------- PLBWIN, PLBNET, PLBSERVE - Modified the KEYIN/DISPLAY *W control so it is ignored when the SETMODE *SCREEN=OFF mode is being used. This behavior change is being made to execute as described in the PLB Language Reference Manual. ------------------------------------------------------------------------------- PLBWIN, PLBNET, ALL GUI CLIENTS - There is a Windows OS short key sequence ( CTL+'numeric pad plus' ) that causes an auto-resize behavior for a LISTVIEW control. This auto-resize behavior was causing all columns in a LISTVIEW control to be resized to show all of the data in a column. A change has been made to detect the LISTVIEW behavior so a CTL+'numeric pad plus' does not affect any of the attribute columns as well as any column that has been locked using the 'ColResizeFlag' method. - Modified the MULTISELECT property for a SETPROP to eliminate the a LISTVIEW window refresh/update action. This change prevents unnecessary flashing of a LISTVIEW window when the MULTISELECT property is changed. - Corrected a problem drawing a STATTEXT where the text position was incorrect when the ALIGNMENT right/center being used and the text contained '&' characters. - Corrected a problem where a scale operation for an EDITTEXT with a STYLE of 3D OUT was causing the position, height, and width of the object window to be changed unexpectedly. ------------------------------------------------------------------------------- PLBWIN - Corrected a problem where a U19 error would occur when executing programs using the Automation Server with the runtime product authorization set to PLBWNT or SUNDEV. ------------------------------------------------------------------------------- PLBNET - The PLBNET runtime is compiled as a C++ application with the Microsoft Common Language Runtime support. To provide the SQLite database engine functionality for the PLBNET runtime required the SQLite database engine to be implemented as a DLL. The PLBNET runtime can then used the SQLite functions available in the PLBNETSUP DLL. The PLBNETSUP DLL must be located in the same directory where the PLBNET runtime is located. ------------------------------------------------------------------------------- PLBCMP - Modified the compiler 's' option to optionally allow a parameter to cause the source in the SDB debug file to be encrypted. This change allows the 's#0' format to enable the SDB encryption. A 9.4 debugger is required to decrypt an encrypted SDB file. Otherwise, the SDB source does not appear in a readable format. Note: 1. The 's' option creates an unencrypted SDB file. 2. The 's#0' option creates an encrypted SDB file using a Sunbelt private encryption key. - Added the COUNTKEYS instruction. See the description in the runtime section named 'PLBWIN, PLBNET, PLBSERVE'. - Added the FILTER instruction. See the description in the runtime section named 'PLBWIN, PLBNET, PLBSERVE'. - Added the SCHEMA instruction. See the description in the runtime section named 'PLBWIN, PLBNET, PLBSERVE'. - Added a new keyword named 'SCHEMAINFO' to the GETFILE instruction. See the description in the runtime section named 'PLBWIN, PLBNET, PLBSERVE'. - Added a two new keywords named 'QUERYCOLCOUNT' and 'QUERYCOLNAMES' to the GETFILE instruction. See the description in the runtime section named 'PLBWIN, PLBNET, PLBSERVE'. - Modified the FILE, AFILE, and IFILE variables to support a new optional parameter named 'VIEW={viewname}'. VIEW={viewname} This parameter specifies a default view to be used for the file variable. The {viewname} can be a literal or a character string variable that specifies a database and view name. Example: MasterView INIT "mydatabase.master" . iFile1 IFILE VIEW="somedatabase.userview" . iFile2 IFILE VIEW=MasterView - Modified the OPEN/PREP instructions to support an optional keyword named 'VIEW={viewname}'. The {viewname} can be a literal or a character string variable that specifies a database and view name. The {viewname} identifies a view schema definition found in a database where column names, types, and sizes are defined for fields that exist in the records for a data file. The view schema definitions can be used to execute enhanced file IO (READ, WRITE, and UPDATE) instructions where the COLUMN names are used for specific defined fields. Also, the view schema definitions are used to evaluate a filter expression that can be specified for a file variable using the FILTER instruction. FORMAT OPEN/PREPARE FILE with VIEW: (1) [label] OPEN {file},{name}[,{mode},{lock},{unlock},{wait}[: VIEW={viewstring}]] (2) [label] OPEN {file},{name|tcpip id:port}[,{mode},{lock},{unlock}: {wait}[,VIEW={viewstring}]] (1) [label] PREPARE {file},{txtname}[,{mode}[,VIEW={viewstring}]] (2) [label] PREPARE {file},{txtname|tcpip id:port}[,{mode}[: VIEW={viewstring}]] FORMAT OPEN/PREPARE AFILE with VIEW: (1) [label] OPEN {afile},{name}[,{wildcards},{mode},{lock},{unlock}: {wait}[,VIEW={viewstring}]] (2) [label] OPEN {afile},{name|tcpip id:port}[,{wildcards},{mode}: {lock},{unlock},{wait}[,VIEW={viewstring}]] (1) [label] PREPARE {afile},{txtname},{aamname},{keyspecs}: {maxreclen}[,{mode}[,VIEW={viewstring}]] (2) [label] PREPARE {afile},{txtname},{aamname|tcpip id:port}: {keyspecs},{maxreclen}[,{mode}[: VIEW={viewstring}]] FORMAT OPEN/PREPARE IFILE with VIEW: (1) [label] OPEN {ifile},{name}[,{mode},{lock},{unlock},{wait}[: VIEW={viewstring}]] (2) [label] OPEN {ifile},{name|tcpip id:port},{mode},{lock}: {unlock},{wait}],VIEW={viewstring}]] (1) [label] PREPARE {ifile},{txtname},{isiname},{keyspecs}: {maxreclen}[,{mode}[:VIEW={viewstring}]] (2) [label] PREPARE {ifile},{txtname},{isiname|tcpip id:port}[: keyspecs},{maxreclen}[,{mode}[: VIEW={viewstring}]] Note: 1. The {viewstring} is a previously defined Character String Variable or Literal containing the view schema name that is found in the database. The {viewstring} data can be formatted to access various view schema information from a specific database. The following defines supported data formats for the {viewstring} data: VIEW="viewname" In this case, the 'viewname' is a name that has been inserted into the 'sun_views' table that exists in the default schema database currently being used for a runtime. The default schema database for the runtime is established when the runtime initially loads. The PLB_SCHEMA keyword for the runtime can be used to initially establish a schema database that is used as the default schema database. If the PLB_SCHEMA runtime keyword is not used, a default schema database named 'sunschema.db' is used in the same directory where the runtime executable is located. VIEW="schemaname.viewname" In this case, the 'schemaname' is a name that must exist in the 'sun_databases' table found in the default schema database currently being used for a runtime. When the 'schemaname' is found in the 'sun_databases' table, the final schema database file can be loaded and used to find the specified viewname definitions to be used for the file being opened. VIEW="viewname|ipaddr" In this case, the 'viewname' is a name that has been inserted into the 'sun_views' table that exists in the default schema database currently being used for a Data Manager that has a TCPIP/URL address specified as the 'ipaddr'. The 'ipaddr' can be a URL or a TCPIP:PORT address. VIEW="schemaname.viewname|ipaddr" In this case, the 'schemaname' is a name that must exist in the 'sun_databases' table found in the default schema database currently being used for a Data Manager. The 'ipaddr' can be a URL or a TCPIP:PORT address where the Data Manager can be accessed. The schema database accessed using the 'schemaname' at the Data Manager must exist at the server where the Data Manager is executing. 2. Before a view can be used in an OPEN instruction, the view schema data must already exist in a Schema Database that is being used. The SCHEMA instruction using the IMPORT keyword can be used to load the view data into a schema database. Examples: FILE FILE . Case1 OPEN FILE, "myfile.txt", VIEW="customer" In this case, the data file 'myfile.txt' is being opened and a view named 'customer' is to be used. The 'customer' view name must exist in the 'sun_views' table found in the default schema used by the runtime. Case2 OPEN FILE, "myfile.txt", VIEW="xyzcompany.customer" In this case, the data file 'myfile.txt' is being opened and a view named 'customer' is to be used from the schema database referenced by the name 'xyzcompany'. The 'xyzcompany' name must exist in the default schema database being used by the runtime. The 'xyzcompany' reference is used to identify a specific schema database that contains the 'customer' view to be used. Case3 OPEN FILE, "myfile.txt|192.168.0.101", VIEW="customer" In this case, the behavior is the same as 'Case1' except the data file is located at a Data Manager. The schema database information is local to the client workstation. Case4 OPEN FILE, "myfile.txt", VIEW="customer|192.168.0.101" In this case, the schema database information is retrieved from a Data Manager and used to access a data file opened local to a client workstation where the runtime is executing. Case5 OPEN FILE, "myfile.txt|192.168.0.101": VIEW="customer|192.168.0.101" In this case, both the schema database information and the data file is accessed at the Data Manager. - Modified the READ, WRITE, and UPDATE instructions to support column names as defined by the view schema data assigned when a file variable was opened or prepared. When view schema is assigned to a file variable, the READ, WRITE, and UPDATE instructions can optionally use the COLUMN name syntax or not. When the COLUMN name syntax is being used, then all variables used in the instruction variable list must have COLUMN names specified. When the COLUMN name syntax is not being sued, then no variables in the instruction variable list can have COLUMN names. WRITE Instruction: Format using COLUMN names from a VIEW specified in OPEN: [label] WRITE {file},{record};[COLUMNAME={variable}[,...]] [label] WRITE {afile};[COLUMNAME={variable}[,...]] [label] WRITE {ifile}[,{key}];[COLUMNAME={variable}[,...]] Where: COLUMNNAME This is the column name as specified in the VIEW that was assigned to the file variable by the OPEN or PREPARE instruction. The column named is not case sensitive. variable This is a normal PLB variable that has been previously declared and loaded with data to be written. Notes: 1. When a WRITE instruction uses column names, then all variables in this instruction must use column names. 2. If the column name syntax format is being used for a WRITE instruction, then the partial IO using the ';' character is not allowed. The runtime gives an appropriate error in this case. 3. If the column name syntax format is being used for a WRITE instruction and all of the view column names are not included in the WRITE variable list, any unspecified fields are either blank filled or filled with a default value specified in the view schema. For a file opened/created with fixed length records, the WRITE instruction writes the full record with appropriate default data for unspecified fields. For a file opened/created with variable length records, the WRITE instruction writes all of the fields up to and including the last column that has been specified with unspecified fields being appropriately filled with default data. READ Instruction: Format using COLUMN names from a VIEW specified in OPEN: (1) [label] READ {file},{record};[COLUMNNAME={var}][;] (2) [label] READTAB {file},{record};[COLUMNAME={var}][;] (3) [label] READLK {file},{record};[COLUMNAME={var}][;] (1) [label] READ {afile},{{key},[...]};[COLUMNAME={var}][;] (2) [label] READTAB {afile},{{key},[...]};[COLUMNAME={var}][;] (3) [label] READLK {afile},{{key},[...]};[COLUMNNAME={var}][;] (1) [label] READ {ifile},{key};[COLUMNNAME={var}][;] (2) [label] READTAB {ifile},{key};[COLUMNNAME={var}][;] (3) [label] READLK {ifile},{key};[COLUMNNAME={var}][;] Where: COLUMNNAME This is the column name as specified in the VIEW that was assigned to the file variable by the OPEN or PREPARE instruction. The column named is not case sensitive. var This is a normal PLB variable that has been previously declared. Note: 1. When a READ instruction uses column names, then all variables in this instruction must use column names. 2. If the column name syntax format is being used for a READ instruction, then the partial IO using the ';' character is allowed. 3. If the column name syntax format is being used for a READ instruction, the data is retrieved from the data record using the VIEW data type, location, and field size that has been defined for a column. After the column data field is retrieved, the data is moved into the final destination variable specified by the {var}. UPDATE Instruction: Format using COLUMN names from a VIEW specified in OPEN: [label] UPDATE {file};COLUMNNAME={var}[;] [label] UPDATE {afile};COLUMNNAME={var}[;] [label] UPDATE {ifile};COLUMNNAME={var}[;] Where: COLUMNNAME This is the column name as specified in the VIEW that was assigned to the file variable by the OPEN or PREPARE instruction. The column named is not case sensitive. variable This is a normal PLB variable that has been previously declared and loaded with data to be written for the update. Note: 1. When a UPDATE instruction uses column names, then all variables in this instruction must use column names. 2. If the column name syntax format is being used for an UPDATE instruction, the partial IO is supported as appropriate for the instruction. 3. If the column name syntax format is being used for an UPDATE instruction and all of the view column names are not included in the UPDATE variable list, then only the column fields that are specified are written into the record at the VIEW schema information being used. Any unspecified column data fields are not changed. - Modified the compiler to give a compilation error when the WORDWRAP property for an EDITTEXT or RICHEDITTEXT is used in a SETPROP instruction. - Corrected a problem where a FOR instruction would fail to execute as expected when the start and end parameters were both given as expressions. Example of problem: a form 3 b form 3 c form 3 . z form 3 . calc a=11 calc b=90 calc c=1 . // Problem was causing this FOR loop to terminate abruptly. . for z from ((a-1)+(b*(c-1))) to ((a-1)+((b*(c-1))+(b-1))) display a,b,c,z repeat ------------------------------------------------------------------------------- PLBDSIGN - Updated event tables to show all of the required events for GUI objects. ------------------------------------------------------------------------------- SUNINDEX - Corrected a problem where the SUNINDEX instruction could cause an invalid handle to be used from an 'open' operation. This could cause indeterminate execution when using the '-r' or '-i' options. ------------------------------------------------------------------------------- PLBEQU.INC - Added definition for $SUSPEND. ------------------------------------------------------------------------------- SA_DLL32.DLL - Corrected a problem where the same type library has embedded in the sunaccess DLL since release 8.6. In release 9.0, the sunaccess entry points for the following functions were changed to support 64 bit parameters. However, the embedded type library did not identify the 64 bit parameters. Therefore, any applications that rely on the type library like VB6 would access these functions incorrectly. This would cause indeterminate execution of the VB6 programs using the following sunaccess DLL functions: SA_TxtDelete SA_TxtRead SA_TxtWrite SA_GetFilePosit SA_PositEndOfFile SA_RepositFile SA_WriteEndOfFile Note: 1. VB6 does not support 64 bit data types. When the correct type library is embedded in the sunaccess DLL, a VB6 gives an appropriate error message when any function with a 64 bit parameter is attempted to be used. 2. The 64 bit functions have parameters defined as follows: int SA_TxtRead( SA_FH TxtFH, u8 *Buffer, u32 BufLen, s64 Method ); int SA_TxtWrite( SA_FH TxtFH, u8 *Buffer, u32 BufLen, s64 Method ); int SA_TxtDelete( SA_FH TxtFH, u64 Record ); s64 SA_GetFilePosit( SA_FH TxtFH, u32 posMode ); s64 SA_PositEndOfFile( SA_FH TxtFH ); int SA_RepositFile( SA_FH TxtFH, s64 position, u32 posMode ); int SA_WriteEndOfFile( SA_FH TxtFH, s64 record ); - New sunaccess DLL functions have been implemented that can be used by applications that do not support 64 bit data types. The following functions have been implemented to allow 32 bit parameters. SA_TxtDelete32 SA_TxtRead32 SA_TxtWrite32 SA_GetFilePosit32 SA_PositEndOfFile32 SA_RepositFile32 SA_WriteEndOfFile32 Note: 1. The execution of these 32 bit functions are the same as the corresponding 64 bit functions. 2. The 32 bit functions have parameters defined as follows: int SA_TxtRead32( SA_FH TxtFH, u8 *Buffer, u32 BufLen, u32 Method ); int SA_TxtWrite32( SA_FH TxtFH, u8 *Buffer, u32 BufLen, u32 Method ); int SA_TxtDelete32( SA_FH TxtFH, u32 Record ); s32 SA_GetFilePosit32( SA_FH TxtFH, u32 posMode ); s32 SA_PositEndOfFile32( SA_FH TxtFH ); int SA_RepositFile32( SA_FH TxtFH, u32 position, u32 posMode ); int SA_WriteEndOfFile32( SA_FH TxtFH, u32 record ); 3. The 32 bit functions must be used for any applications that do not support 64 bit data types. For example, the 32 bit functions must be used for VB6 applications because VB6 does not support 64 bit data types. ------------------------------------------------------------------------------- WATCH.PLC - Corrected addition of new connection information. - Modified warning of data truncation in logging to only be displayed once. - Modified the refresh logic to keep the tab control on the currently selected panel. - Added an alternate row color for list data. - Modified the logging screen to show the record range and allow a maximum number of records to display. The maximum defaults to the last two thousand records. ------------------------------------------------------------------------------- DESIGNER.PLC - Added replace icon and replace bitmap functions to the imagelist editor. - Allow double-clicking on an event in the object tree to position the code window to the event label and bring the code window to the front. - Added the Paste function to the form shortcut menu. ------------------------------------------------------------------------------- DBEXPLORER.PLC - New program to browse Data Base Files. See the help pages in the Utilities Manual for more information. ------------------------------------------------------------------------------- EDITOR.PLC - Added support for dbexplorer SQL window. ------------------------------------------------------------------------------- DBGIFACE - Added support for encrypted SDB files. ------------------------------------------------------------------------------- SUNCS21.OCX - Corrected a GPF issue that could occur when opening a regular TXT file. - Fixed a display problem where the left margin was not properly reset when the language selection changed. - In the properties dialog, the category names for the color configurations were changed to be consistent with the PLB Language terms. - Corrected a code help tooltip sizing problem that occurs when the IDE is running on a secondary screen that has a negative position. - Modified the editor properties window to allow it to show on a secondary monitor. - When code folding is enabled, if the mouse is left to hover in the margin at the start of a collapsed region, a tooltip will appear containing up to the first 4 lines of collapsed source. ------------------------------------------------------------------------------- SUNIDE.PLC - Modified include dependency resolution to pull data from .lst file first, then if that fails or lst file is not present, it will parse the source as before. This improves the performance of adding a program where a lst file exists ( refresh dependencies ) and addresses a scenario where include filenames may not be determined until compile time. - Corrected an untrapped F04 error that would occur when changing the IDE Settings when no project was open. - Corrected a bug in the source extension dialog where the external editor config items were not initially disabled when "Use External Editor" was not set. ------------------------------------------------------------------------------- SODBC2SCHDB.PLS - New demo program to illustrate using the DBxxx verbs to construct the runtime schema. This program imports a SUNODBC schema to a runtime schema database. -------------------------------------------------------------------------------