Print
page
Beginning with this version a new internal function was implemented - named "getsqlerror()" - which returns the error number ("errno") returned by the database server being used.
Configuration variables: The following variable was added:
ORACLE_PROC: Indicates to the "gateway" if the Oracle server allows to create SQL procedures. By default it is ON.
Environment variables: The variables ORACLE_SID, ORACLE_HOME and ORACLE_UID are working identical to client-server environments. In this way it is possible to use a general value which can be assigned through the configuration file "gworacle.env" detailed for each client.
Foreign Keys: For the name of a "foreign key" the prefix FK doesn't has to be applied. (If you intended to delete a "foreign key" in older versions you had to delete them directly with the Oracle server and also in MultiBase in the maintenance mode).
INSERT statement: All of the limitations in functionality that existed were removed and also those that had to be considered when the datatype SERIAL was used.
IMPORTANT: The internal table "mbserial", used to simulate this datatype, has changed its structure. The following CTL program drops the table and creates a new scheme and updates the data that it keeps. It has to be executed as many times as MultiBase databases are existent.
define
parameter[1] dbname char(20)
parameter[2] user_pass char(40)
end define
main begin
call putenv("ORACLE_UID", user_pass, 2)
database $dbname
tsql "execsql create table mbtserial
(tabname char(30),lastserial integer)"
tsql "execsql insert into mbtserial select tabname,
lastserial " && "from
mbserial, mbtables
where mbserial.tabid = mbtables.tabid"
tsql "execsql drop table mbserial"
tsql "execsql rename mbtserial to mbserial"
end main
PRACTICAL CASES:
The field "dirpath" in "mbtables" contains the user where the table is located. If the field contains a null value inherited from previous versions, it must be filled with the corresponding value to guarantee correct functionality.
Changing of MultiBase database: The desired effect may be reached with the following instruction:
DATABASE name_of_the_database
but before a "putenv" of the variable "ORACLE_UID" with the corresponding value must be issued:
call putenv("ORACLE_UID", user_password, 2)
Temporary tables: If in a long session you have changed successively databases, it can be that in the moment of finishing the process temporary tables in different Oracle users are existent. The "gateway" ordinary drops them in order to simulate this temporal character, but there are two suppositions in the moment you connect to the users: that you have not changed ORACLE_SID and that the PASSWORD of this user coinsists with his name. In any other case the tables are left without being dropped.
Shared Tables: To share a table between two databases (two Oracle users) a possible way to realize this in the MultiBase server is given.
The user A, creator of the table to be shared, gives the permissions he considers to be appropriate to the user B for the same table and for the table "mbserial" if there is a field existent which is of SERIAL datatype.
The user B creates a synonym:
CREATE SYNONYM name_of_the_table FOR user_A.name_of_the_table
to be able to use the same name of the table. Next, create the table in maintenance mode in order your catalogue contains it and modify the field "dirpath" with UPDATE in the row which appears in "mbtables" for this table. Change the value "userB" to "userA" (because in reality it is the userA where the table resides).
If the structure of the table is changed in any moment, the previous procedures must be repeated (ALTER in maintenance mode and change of "dirpath").
MultiBase catalogue: It is possible to break the special relation existent between MultiBase databases and Oracle users.
If you want that one MultiBase database corresponds to various Oracle users maintaining one single catalogue, the "mb*" tables must be shared in the way described before. One of the users is the creator of the real catalogue ("grantor" of permissions) while the others share the tables (creating synonyms).
The table "mbserial" doesn't appear in the catalogue, because of its internal nature, but all of them have to be manipulated, therefore permissions must be granted:
EXECSQL GRANT ALL PRIVILEGES ON mbserial TO PUBLIC
Every user, except the creator of the catalogues, has to have the following synonym established:
EXECSQL CREATE SYNONYM mbserial FOR create_user.mbserial
This procedure can also be applied to the tables of the programming environment ("ep*") if you should wish to do this.
Datatype: The conversions:
| Informix | MultiBase |
| VARCHAR(size) | CHAR(size) |
| FLOAT | DECIMAL(p,s) |
| SMALLFLOAT | DECIMAL(p,s) |
were not specified in the manual, but were performed automatically.
Environment variables: The variable INFORMIXDIR is working identical to client-server environments. In this way it is possible to use a general value which can be assigned through the configuration file "gwinformix.env" detailed for each client.
CREATE statement; DEFAULT attribute: This attribute doesn't exist in version 4 of the Informix server. From now on the "gateway" simulates this in INSERT operations for VALUES which are inserted using constants or host variables (this is extended also for the FORM).
This simulation, however, doesn't work in the case that the values are given by a SELECT statement, because the result can't be controlled (INSERT ... SELECT ...).
Foreign Keys: For the name of a "foreign key" the prefix FK doesn't has to be applied. (If you intended to delete a "foreign key" in older versions you had to delete them directly with the Informix server and also in MultiBase in the maintenance mode).
START DATABASE statement: This statement is only used to write the "syslog" registry into the MultiBase catalogue, informing that the database is transactional. It does not send any command to the Informix server.
Temporary tables: If you are using this server temporary tables can not be shared among databases.
1. The logical operator "OR" utilized in a "WHERE" clause of a SQL instruction (SELECT, UPDATE or DELETE) didn't return the correct derived table in certain circumstances.
2. The editing in a "multiscreen" FRAME (with several pages) produced an error, assigning unreadable values to variables and later cancelling the program.
3. [MS-DOS]. The command trepidx admits the argument "-y" to disable any question to the user. This argument was already implemented in previous versions for UNIX and Windows.
4. In the moment of printing a manual generated with tdocu of MultiBase the page skip was not performed correctly. The problem was due to the command tprocess who is in charge of interpreting the commands generated by the user's oder programmer's documentation of MultiBase.
5. The ROLLFORWARD DATABASE statement didn't work properly in a transaction which used the clause "WHERE CURRENT OF..." while reading a CURSOR declared as "FOR UPDATE".
6. The WINDOW statement with a SELECT which didn't return a single row produced an error when found in a loop if any of the columns of the "select_list" was of type DECIMAL of MONEY.
7. A SELECT statement not declared as a CURSOR which included a reception clause ("INTO" or "BY NAME") resulted in a huge consum of memory of the CTL module if more than one row was returned ("ambiguous=true") provoking thus an error if the statement was executed several times.
8. When generating a current list in a FORM and intending to perform a new query, which was aborted by the user, the row in the before created current list was always the last one, giving the message "no more rows" when intending to choose the next one. Nevertheless, if the option to update or delete was chosen, the row affected by any of these operations was always the first and not the last.
9. The massive creation of temporay tables (CREATE TEMP TABLE) produced the message "Impossible to open the database table".
10. The function "evalfun(function, parameters)" didn't work correctly with certain internal functions of CTL.
11. If the value assigned to a variable of TIME type was above 24 hours, the value returned was "0". Currently, the expression "let hrs = 24:01:10" will return the value "NULL".
12. The "DISTINCT" clause of the "select_list" of a SELECT statement with more than 8 fields returned different results depending if an "INTO TEMP" was included or not.
13. The command THELPCOMP didn't take care on the variable MSGDIR, even though the programming environment was simulating this possibility. In the previous "release" this variable was not included in the command line of thelpcomp.
14. [Windows]. The selection of a second printer with the Windows specific function "setprtsetup("name", expression)" didn't update the paper size in the moment of using the Print Manager ("DBPRINT=PRINTMAN").
15. [Windows]. In a FORM with horizontal scroll (left-right) an error was produced when the key combination [CTRL]+[Q] was pressed. This combination is defined in MultiBase by default for this action.
16. [UNIX and MS-DOS]. A new environment variable, WINFN, was introduced to inform the compiler to ignore or not the Windows specific functions in order not to produce typical errors that the function doesn't exist in a module of the program during runtime. The possible values are "Y" and "N". The value "Y" can be simulated with the parameter "-wfn" of the command ctlcomp, which means that the syntax in those cases is of the following form:
ctlcomp -wfn module
17. For databases created with collating sequence the derived table from a "WHERE" condition in a SELECT, UPDATE or DELETE on a DECIMAL type column was correct or incorrect whether it was indexed or not.
18. [UNIX]. In UNIX versions who are compatible to the standard 4.0, supplementary groups can be defined. This version of MultiBase contemplates theses groups regarding the permissions relative to UNIX concerning programs and databases.
lastrowid(): Returns the "ROWID" number of the last row inserted through a FORM (ADD, ADD ONE or INTERCALATE statements) or as well through the INSERT statement of the DML sublanguage of SQL.
lastserial(): Returns the number assigned to a SERIAL column after performing an insert through a FORM (ADD, ADD ONE or INTERCALATE statements) or as well through the INSERT statement of the DML sublanguage of SQL.
licence(): This function, already implemented in previous versions, didn't work correctly in the version for Windows, returning always the value zero. Currently, the value returned is the one of the licence of the executed CTL.
DisableFormVar(expression1,expression2)
EnableFormVar(expression1,expression2)
Deactivates/activates the editing for the variable indicated in "expression2" during
the execution of a FORM which maintains the table specified in "expression1".
Example:
option "Changes"
call DisableFormVar("customers","total_invoiced")
add
DisableFrameVar(expression1,expression2)
EnableFrameVar(expression1,expression2)
Deactivates/activates the editing for the variabled indicated in "expression2" belonging
to the FRAME indicated in "expression1".
CountFormVars(expression1): Returns the number of variables that can be edited in a FORM which maintains the table specified in "expression1".
CountFrameVars(expression1): Returns the number of variables that can be edited belonging to the FRAME indicated in "expression1".
GetFormVarName(expression1,expression2): Returns the name of the variable of table "expression1" maintained in a FORM and which corresponds to the order number given in "expression2".
GetFrameVarName(expression1,expression2): Returns the name of the variable of a FRAME indicated in "expression1" and which corresponds to the order number given in "expression2".
Dynamic connection to the database server.
A new command line parameter ("-con") was implemented together
with a new option in the pulldown "File" of the main menu of
EasyReport ("Change Connection") to select a connection to a
database server different to the one previously defined in the configuration
editor ("confedit"). The environment variables implied in this
new concept of dynamic connection which receive a special treatment are
DBHOST, DBUSER and DBPASSWD.
The new command line parameters of EasyReport to manage the environment are the following:
In the [MultiBase] section of the file "WIN.INI" the entries "COSMOSDIR" and "EASYREP.INI" can be defined. "COSMOSDIR" identifies the directory ("path") of the application to find the commands belonging to EasyReport (easyrep, cdsedit and confedit). This directory must have at minimum the subdirectories "bin", "drw", "msg" and "etc" with the files constituting EasyReport. The entry "EASYREP.INI" defines the directory and name ("complete path") of the auxiliar configuration file of EasyReport. This file has the same structure as the file "COSMOS.INI", over which it has precedence. If "EASYREP.INI" is not specified the auxiliar configuration file will be defined as "COSMOSDIR\etc\easyrep.ini", whose existence is not obligatory.
IMPORTANT: EasyReport includes an interactive help system where the functionality and characteristics are explained. To get a more clear impression about the new possibilities consult this file.
The head line of a report may contain special characters ("-$Pn") to display the values assigned to possible parameters during runtime.
The parameter ("-par") of the command line of EasyReport should only be used to specify different parameters which influence the execution of the report.
The "USING" clause within a Conceptional Data Scheme produced an error when not indicated, even though it is not obligatory to specify a variable value in the defining SELECT statement.
The option "Unload tables" produced an error when you were working with the "gateway" for Oracle.
The option "Select" a database didn't work when working with "gateways".
[Windows]. The option "Output" of the SQL menu produced an error if the environment variable DBPRINT contained the value "PM" or "PRINTMAN" (utilisation of the Windows Print Manager).
The update to version 3.0.1.0 from versions 3.0.00 and 2.0.xx which are software serialized, that is the serialization number was given from the Support Department of TransTOOLs, can be made by copying over the existent version with the command:
# cpio -iBduv -I /dev/r...
or as well:
# cpio -iBduv < /dev/r...
The clause "u" of the cpio command takes care of the unconditional update of all of the MultiBase files.
IMPORTANT: If you have personalized your copy of MultiBase in version 3.0.00 save the files "$TRANSDIR/etc/termcap" and "$TRANSDIR/etc/tprinter" before proceeding with the installation of the new software.
To continue and dependant whether your licence is a Development of a Runtime, execute as superuser the commands installctl or installrt, respectively, so your copy of MultiBase will be automatically updated to the new version.
The installation of a new licence of version 3.0.1.0 (not an update) is carried out as being described in Chapter 3 of the Administrator's Manual.
If your licence of MultiBase is "limited" (time limit) it is possible to increase the date of expiration by prior authorization through the Commercial Department of TransTOOLs.