List of changes for portingset 6.2a.03.03List of changes for portingset 6.2a.03.03 MergeProject: Grieg: # 6277 (bugf): Delete all temporary database driver files when empty Date: Tue, 20 Jul 1999 17:03:30 +0200 (METDST) Release: Grieg Date: 1999/07/20 Script: MergeProject Project: EDUX1997 Problem: Problem Description (Customer terms) Project EDNT184 did only part of its job: Also remove empty temporary files of the database drivers. Problem Description (Technical terms) Workaround Solution Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 74685 (filled in by KD) TCS remark id(s) Priority (e.g. not workable) 45360 Reduced workable MergeProject: Grieg: # 6551 (bugf): Informix session pool Date: Wed, 1 Sep 1999 17:00:31 +0200 (METDST) Release: Grieg Date: 1999/09/01 Script: MergeProject Project: EDUX2109 Created on: Corelli Problem: Problem Description (Customer terms) The client is not in all situations informed about ocurring errors by the database driver. Problem Description (Technical terms) The function local_server() calls functions like dbs_exec_server() or dbs_attach_server() or dbs_attach_session() or others but doesn't check for the return value. This can cause an illegal state when such a function returns a negative value to indicate an error but it doesn't assign an error code unequal to zero to the dbs_errno variable. Workaround No workaround. Solution The function local_server() checks now the return value of the called function. If the return value is negative and the value of dbs_errno is zero, the value of dbs_errno is set to E_BDB_ILLEGAL (215). Test Procedure This situation should never occur as it indicates coding implementation erros. So it is not possible to test this with a normal binary. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) N.a. N.a. N.a. TCS remark id(s) Priority (e.g. not workable) N.a. N.a. MergeProject: Grieg: # 7480 (EDUX2462): Database hints improved for level-2 drivers Date: Thu, 9 Dec 1999 16:45:23 +0100 (MET) Release: Grieg Date: 1999/12/09 Script: MergeProject Project: EDUX2462 Created on: Verdi Type: bugfix Problem: Problem Description (Customer terms) The database driver sometimes generates hints that are far from optimal. Problem Description (Technical terms) Sometimes columns are considered for index hints that can not be used resulting in a wrong hint. See solution for some examples. Workaround Solution Applied changes: 1. Queries like: select qmptc020.qitg from qmptc020 where qmptc020._index2 = {:xxx} | incomplete condition on combined column. This was handled by the query processor and hint generation as: where {qmptc020.item, qmptc020.qitg} = {:xxx, } leading to an index hint based on index1 because both fields (qitg and item) were part of the internal where clause. The new driver handles this type of query like: where qmptc020.item = :xxx leading to an index hint based on index2 because fields qitg is not part of the internal where clause anymore. 2. Queries like select qmptc020.qitg from qmptc020 where qmptc020.item = :xxx and qmptc020.qitg != :yyy | operator with very bad selectivity. The hint generator used to take almost all operators as possible hint candidates even if the operator has a bad selectivity. This led to an index hint based on index1 because both fields (qitg and item) were considered. The new driver ignores those parts of the where clause that have operators with a very bad selectivity (like not-equal) or operators that can not be handled by an index efficiently. The new driver will generate an index hint based on index2 because the field qitg is ignored as it is an operand of the not-equal operator. Test Procedure Use qptool to run queries like the ones mentioned above. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) The archive contains several cases 20 TCS remark id(s) Priority (e.g. not workable) Boeing issue 2407 Serious MergeProject: Grieg: # 6370 (bugf): Direct allocating in create.new.symbol does not work. Date: Mon, 2 Aug 1999 08:23:03 +0200 (METDST) Release: Grieg Date: 1999/08/02 Script: MergeProject Project: EDUX2040 Created on: Grieg Problem: Problem Description (Customer terms) During Verdi 2 development a feature of create.new.symbol was used that wasn't used before: allocating data directly in stead of deferring it for later use Problem Description (Technical terms) create.new.symbol fails to allocate the symbol data. Workaround This is what doesn't work right now: create.new.symbol("new.var", DB.LONG, 3) use create.new.symbol("new.var", DB.BASED+DB.LONG, 1) alloc.mem(push.by.name("new.var"), 3) Solution mir_fun.c: change a | to &. There was insufficient memory allocated in the case of allocating an array variable For example create.new.symbol("new.sym", DB.LONG, 3) does not work correctly and can lead to core dumps. Test Procedure Joris Alkema has a special test program. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) xxxxx yyyyy zz TCS remark id(s) Priority (e.g. not workable) 100/50707 MergeProject: Grieg: # 7578 (EDUX1881): Compnr.check resets compnr of cursors Date: Wed, 22 Dec 1999 12:58:19 +0100 (MET) Release: Grieg Date: 1999/12/22 Script: MergeProject Project: EDUX1881 Created on: Verdi Type: bugfix Problem: Problem Description (Customer terms) Problem Description (Technical terms) In the bshell, when a cursor is opened (for database actions like db.insert) the cursor remains fixed for the company it was opened in. When compnr.check() is called to switch to another company number, the cursors are not affected. They remain locked in their original company number. Workaround There is no workaround. Solution Modified the compnr.check() function so that it sets the company number of the cursors to the new company number. Test Procedure Write a script like the one below: table tddcts100 function main() { ddcts100._compnr = 112 compnr.check(110) ddcts100.int = 1 db.insert(tddcts100) compnr.check(111) ddcts100.int = 2 db.insert(tddcts100) commit.transaction() } Verify that the first record is inserted in company 110 and that the second record is inserted in company 111. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 7809 (VHUX2945): database drivers always use dbsinit 020 flag Date: Thu, 27 Jan 2000 10:47:46 +0100 (MET) Release: Grieg Date: 2000/01/27 Script: MergeProject Project: VHUX2945 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) Performance problems on queries containing OR statements. Problem Description (Technical terms) See Technical reference manuals of the database drivers. When a database driver is configured to use the iterative method to solve complex queries, several checks are done to see if the iterative method can be used. If not, the driver will fall back on the nested method. As soon as a query contained an OR clause, the iterative method was discarded. The dbsinit 020 flag was introduced to change this behavior. When this bit was enabled, OR clauses where allowed when they are part of an AND clause in the first nesting level of the WHERE clause of the query. The dbsinit 020 flag has been used by several customers for a long time. The results can be divided into two groups: - no performance changes at all - big performance improvement for certain problem queries. No one mentioned a negative impact of this flag. As the results where either very positive or neutral, it has been decided to make the behavior of dbsinit 020 hard coded when the iterative method has been configured. Workaround None Solution Made the behavior of the dbsinit 020 flag hard coded enabled. Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8028 (VHUX3039): adding functionality to repgen for 10 positions for the date field. Date: Tue, 8 Feb 2000 15:50:47 +0100 (MET) Release: Grieg Date: 2000/02/08 Script: MergeProject Project: VHUX3039 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) There is a problem when using the special field `date` on a report to print the date of today. The format of this field is YY-MM-DD and not YYYY-MM-DD like other date fields on the report. Problem Description (Technical terms) The variable r.today$ is printed on the place where the date field is specified. In maintain reports it is now posible to specify if that datefield is 8 or 10 positions ( with or withour century) The ostprepdll could however not recognize what format is used in the compiled report. Workaround n.a. Solution rg_isam.c: adding functionality Test Procedure Create a report with a special field of type date and set the lenght of that field to 10. Then compile the report and execute it. See if the complete date is printed with century. For this change also the bic_repgen is changed and ostpstddll is changed. These objects are also needed for this solution. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 91503 30 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8041 (VHUX3055): Licmon errorcode Date: Wed, 9 Feb 2000 09:22:32 +0100 (MET) Release: Grieg Date: 2000/02/09 Script: MergeProject Project: VHUX3055 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) When the licence server is stopped with the program licmon6.1 an error message is logged in the file log.licmon6.1. This is not realy an error message, because everything is working fine. Problem Description (Technical terms) When licmon6.1 had stopped the licmon server it tried to logof the current user from the licmon server. But this was not possible anymore, because the server was already down. Workaround n.a. Solution licmon.c: Error code in log_licmon6.1 Test Procedure Start the licence daemon and stop it with help of licmon6.1. Check if an error message is in the file log.licmon6.1. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 77301 30 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8108 (VHUX3113): Fixed assertion in hint generation Date: Wed, 16 Feb 2000 07:59:21 +0100 (MET) Release: Grieg Date: 2000/02/16 Script: MergeProject Project: VHUX3113 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) For customers none. For internal used porting sets: Assertion failed, core dump. Problem Description (Technical terms) For internally compiled porting sets, an assertion is violated in the hint generation when indexes on combined columns occur. Workaround none Solution qdb_tree.c: fixed code. Test Procedure Use an internally compiled database driver ( -DBAAN_ONLY during compilation) and try a query with WHERE _index = { . . . } this index definition should contain a combined column. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) internally found Medium MergeProject: Grieg: # 8143 (SCUX3128): fix incorrect tax on multi-line invoices/orders Date: Fri, 18 Feb 2000 08:21:03 +0100 (MET) Release: Grieg Date: 2000/02/18 Script: MergeProject Project: SCUX3128 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) On multi-line invoices/orders the tax is sometimes incorrect. Problem Description (Technical terms) The message structure (msgin_raw.mtext in get_next_message function) was not getting cleared properly before a new message was put into it. If a shorter message followed a longer message, then it would cause the problem. Workaround (Fill this in) Solution api_baan.c: message structure (msgin_raw.mtext in get_next_message function) was not cleared properly. Test Procedure Sent same transactions that did not work with previous api across the new api, and am now getting the correct results. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) xxxxx yyyyy zz TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8318 (VHNT3235): Add -giveaway command line option to BW. Date: Thu, 9 Mar 2000 10:26:11 +0100 (MET) Release: Grieg Date: 2000/03/09 Script: MergeProject Project: VHNT3235 Created on: Verdi Type: bugfix Problem: Problem Description (Customer terms) A time ago was a new functionality introduced in BW which when a bwc file is created the the username is encrypted within the password in password64 parameter. User can only run if their login name matchs with the user name which is encrypted with the password. If that is not the case, the password field becomes empty and users should fill in the password when loging on the Baan application. This new functionality have created the following problem. The Baan Job Daemon service runs under LocalSystem account and the jobd.bwc file is configured beforehand (evt. via de Baan NT Manager) and the password is saved under an account other than the LocalSystem account. When the jobd.bwc is executed by the the Baan Job Daemon Service (jobd.exe) on Windows NT, the password field should be filled by user since the username (account) who created jobd.bwc may not match with the username of the user. It is suggested that the user should not be confronted with the password dialog when the Baan Job daemon is started. Problem Description (Technical terms) A new option is introduced. When configuring bwc file, the username which is encrypted with the password can be specified with the option -giveaway. Workaround Solution configsheet.h: Add -getaway command line option to BW. bwconfig.h: Add -giveaway command line option to BW. configsheet.cpp: Add -getaway command line option to BW. bwconfig.c: Add -giveaway command line option to BW. Test Procedure Create a bwc file for a friend with the password field specified. Let the friend run the bw with the bwc file. S/He should be able to run bw without specifing password field. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8326 (VHNT3245): Fixing defects after merging project VHNT3235 (Verdi I) to Grieg. Date: Thu, 9 Mar 2000 14:50:38 +0100 (MET) Release: Grieg Date: 2000/03/09 Script: MergeProject Project: VHNT3245 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) Problem Description (Technical terms) Fixing defects after merging project VHNT3235 (Verdi I) to Grieg. Workaround Solution bwconfig.h: Correcting errors when merging from project VHNT3235 (Verdi I ) to Grieg. configsheet.cpp: Correcting errors when merging from project VHNT3235 (Verdi I ) to Grieg. bwconfig.c: Correcting errors when merging from project VHNT3235 (Verdi I ) to Grieg. Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 7256 (VHUX2559): Fixed prototypes of memory functions in system.h Date: Fri, 12 Nov 1999 15:41:42 +0100 (MET) Release: Grieg Date: 1999/11/12 Script: MergeProject Project: VHUX2559 Created on: Corelli Problem: Problem Description (Customer terms) Problem Description (Technical terms) Compiler choked on syntax errors in system.h. The prototypes of some memory functions (memcpy, memset and memcmp) were incorrect. Workaround Solution system.h: Fixed the syntax of the memory function prototypes. Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8354 (VHUX3259): Fixing a bug in AMS related to ttaad4100 and adding AMS trace Date: Tue, 14 Mar 2000 13:19:22 +0100 (MET) Release: Grieg Date: 2000/03/14 Script: MergeProject Project: VHUX3259 Created on: Verdi2 Type: bugfix Problem: Problem Description (Customer terms) 1) A problem with the following session line: ttaad4100:*:31 does not allow this program to be started in company 0 2) there is no way to show what AMS does. Problem Description (Technical terms) 1) Internally the session code is stored as "ttaad4100 " while the AMS-roles are stored with "ttaad4100" This has been fixed now 2) idem Workaround 1) Add an extra line with ttaad4100 :*:31 (with four spaces) 2) tersely go thru the ams roles by hand. Solution 1) strip the session names alg.c: Strip names before they call allowed_to_start_session_in_company() 2) Adding ams tracing calls: Example of reading a role: A new role is being read of 'ROLANDV' of type session A:0000000:::(-0001):ROLE: role name ROLANDV type Session: New Role : The line of the role being read from the file, including the line number A:0000001:::(-0001):LINE: read role entry line no : 1 : '*:*:31:00002400' The role as stored in the internal role structure A:0000002:::(-0001):ROLE: role name ROLANDV type Session: Add Perm for Role : '*:*' A:0000003:::(-0001):LINE: read role entry line no : 2 : 'tt:*:0:00002400' A:0000004:::(-0001):ROLE: role name ROLANDV type Session: Add Perm for Role : 'tt:*' A:0000005:::(-0001):LINE: read role entry line no : 3 : 'ttdsk:*:31:00002400' A:0000006:::(-0001):ROLE: role name ROLANDV type Session: Add Perm for Role : 'ttdsk:*' A:0000007:::(-0001):LINE: read role entry line no : 4 : 'ttstp:*:31:00002400' A:0000008:::(-0001):ROLE: role name ROLANDV type Session: Add Perm for Role : 'ttstp:*' A:0000009:::(-0001):LINE: read role entry line no : 5 : 'ttaad4100:*:31:00002400' A:0000010:::(-0001):ROLE: role name ROLANDV type Session: Add Perm for Role : 'ttaad4100:*' A:0000011:::(-0001):LINE: read role entry line no : 6 : 'l*::1' A:0000012:::(-0001):ROLE: role name ROLANDV type Session: Add Perm for Role : 'l*:' Example of a permission being read: ttdskbbrowser. A:0000238:::(00004):PERM: permission_for_session for : 'ttdskbbrowser' Example of search process: A:0000239:::(00004):ROLE: role name ROLANDV type Session: Get Role : The matching role: A:0000240:::(00004):ROLE: role name ROLANDV type Session: Look for Perm : 'ttdsk:*' More examples can be obtained by using the '-dbgams' flag on the bshell command line. c_perm.c: Adding rpl_print_perm calls c_roles.c: Adding rpl_print_perm() al_rplm.h: Adding print call back to rpl_print_roles main.c: Adding -dbgams al_roles.c: Adding print of line read from role file. system.h: Adding DEBUG_AMS chk_perm.c: Adding rpl_print_perm call. al_rplm.c: Adding print callback to rpl_print_roles. Test Procedure See above. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 21125 512753 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8339 (VHNT2963): make some variables static Date: Fri, 10 Mar 2000 14:09:43 +0100 (MET) Release: Grieg Date: 2000/03/10 Script: MergeProject Project: VHNT2963 Created on: Verdi2 Type: porting specific change Problem: Problem Description (Customer terms) Link errors in ora7_srv.exe. Problem Description (Technical terms) _pbcport is defined twice in al_sit. Workaround Solution make_pbc_cs: static variabele Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8394 (SCNT3272): DDC mailslot fix Date: Tue, 21 Mar 2000 08:09:14 +0100 (MET) Release: Grieg Date: 2000/03/21 Script: MergeProject Project: SCNT3272 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) ddc_get_reply is not returning correct codes Problem Description (Technical terms) Problem occurs in code which handles mail slots. In UNIX, when the driver calls ddc_get_reply() when the incoming queue is empty, it gets a return code of zero, to indicate that the queue was empty. In NT, ddc_get_reply() returns -1 in the same situation. The driver interprets -1 as a system error, assumes that the communications with the Baan server have been terminated, and shuts down. Workaround none Solution ddc_baan.c: Modified function get_next_message to return correct value. Test Procedure Built and tested ddcdriver.exe and ddcserver.exe. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 6684 743082, 112175 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8467 (VHUX3262): Format strings Date: Fri, 24 Mar 2000 13:54:52 +0100 (MET) Release: Grieg Date: 2000/03/24 Script: MergeProject Project: VHUX3262 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) Still problems with format strings. Problem Description (Technical terms) Sign is incorrectly placed at the right iso the left. Workaround None Solution al_sedit.c: - and + not at the begin or end of the format string should be treated as zero's. Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 82205 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8496 (VHUX3373): dump log.messages in native and not in TSS Date: Wed, 29 Mar 2000 09:17:42 +0100 (MET) Release: Grieg Date: 2000/03/29 Script: MergeProject Project: VHUX3373 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) The messages generated by the log_mesg() call contain both native and tss. Native is the preferred for both Problem Description (Technical terms) idem Workaround not really Solution al_log.c: Convert Log Message to Native character sets instead of TSS. Test Procedure after this fix the log messages should not contain TSS anymore Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 77945 419588 30 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8507 (VHUX3379): Core dump in Oracle-NT driver on db.nr.rows() Date: Fri, 31 Mar 2000 12:03:35 +0100 (MET) Release: Grieg Date: 2000/03/31 Script: MergeProject Project: VHUX3379 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) Core dump of the Oracle driver on NT in db.nr.rows() Problem Description (Technical terms) An internal pointer got outside its range causing an access violations on some rare situations in db.nr.rows() Workaround none Solution Test Procedure See description of defect 78509 Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 77509 731478 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8520 (BDUX3393): Remove Mailrecipient Date: Mon, 3 Apr 2000 09:09:38 +0200 (METDST) Release: Grieg Date: 2000/04/03 Script: MergeProject Project: BDUX3393 Created on: Corelli Type: porting specific change Problem: Problem Description (Customer terms) Martin Oosse is leaving PBC and Rimmert van der Veen was double in Imakefile Problem Description (Technical terms) See above Workaround Solution Imakefile: Removed moosse and 1 of double rvdveen2 Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) xxxxx yyyyy zz TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8557 (VHUX3326): Defect 74965 MB Sort Problem and Defect 75052 fset.min MB Problem Date: Wed, 5 Apr 2000 15:23:09 +0200 (METDST) Release: Grieg Date: 2000/04/05 Script: MergeProject Project: VHUX3326 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) 1) Defect 74695 and TCS 100/49605: Incorrect Sorting in Japanese 2) Defect 75052: fset.min() does not work correctly Problem Description (Technical terms) 1) MB characters were not used when sorting. Only byte sorting was done. 2) The domain.plen should be used for the fset.min() and domain.clen for fset.max() Workaround 1) None 2) setting the minimum yourself. Solution sort.c: Making sort true MB aware. Fix for Defect 74695 and TCS 100/49605 mbfun.c: Adding logging to weigth function to test sort under Japanese. Used for defect 74695 frm_alg.c: Fixing set.fmin() for MB. Look in domain. Fix for defect 75052. Test Procedure See Defect description Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 74695 20 75052 20 TCS remark id(s) Priority (e.g. not workable) 100/49605 Medium MergeProject: Grieg: # 8600 (VHUX3443): Failing db.eq() results in jump to the db.retry.point Date: Mon, 10 Apr 2000 14:37:01 +0200 (METDST) Release: Grieg Date: 2000/04/10 Script: MergeProject Project: VHUX3443 Created on: Verdi2 Type: bugfix Problem: Problem Description (Customer terms) The virtual machine performs a jump to the db.retry.point() on a failing db.eq() call. Problem Description (Technical terms) If a db.call() results in a jump to the retry point, then every failing db.call() which is executed after the jump will again result in a jump to the retry point. See the example Baan-3gl code below. The db.eq (line 4) fails with error 111 because the record does not exist. Execution of the script continues with line 5. At line 6 a record is inserted that already exists; but the insert is buffered. The db.eq at line 7 results in a flush of the buffered inserts; at that point the duplicate record is detected and a jump to the retry point (line 1) is made. Again the db.eq at line 4 is executed, but this time, instead of returning error 111, a jump to the retry point (line 1) is made. table tttadv150 function main() { long ret 1 db.retry.point() 2 ttadv150._compnr = 000 3 ttadv150.cpac = "XX" | non-existing key | The first time the db.eq is executed it returns ret=111 and e=111. | The second time, after the jump to the retry point, the db.eq() | results in a jump to the retry point, which is incorrect. | 4 ret = db.eq( tttadv150 ) message("ret = %d, err = %d", ret, e) 5 db.first( tttadv150 ) 6 db.insert( tttadv150, db.retry ) | At this point the buffered updates should be flushed to the | database. Because the record to be inserted already exists, this | results in a jump to the retry point. | 7 db.eq( tttadv150 ) } Workaround None. Solution Modified the source code. Test Procedure Use the code in the Problem Description (Technical terms). Use the debugger to monitor the processing of the code. Each time, the db.eq at line 4 should result in error 111 and should _not_ result in a jump to the retry point. The db.eq at line 7 should result in a jump to the retry point, until the maximum number of retries is exceeded. After this number is exceeded the session aborts with error: Fatal error: Error 100 (Duplicate value) on ttadv150000 (Max retries (10) exceeded) Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) N.a. TCS remark id(s) Priority (e.g. not workable) 100/55126 Medium MergeProject: Grieg: # 8604 (VHUX3450): Packet code with l is not handled correctly by AMS Date: Mon, 10 Apr 2000 15:53:57 +0200 (METDST) Release: Grieg Date: 2000/04/10 Script: MergeProject Project: VHUX3450 Created on: Corelli Type: bugfix Problem: Problem Description (Customer terms) Bshell core dumps after role is removed. Problem Description (Technical terms) Roles with package code 'l*' are not handled correctly by AMS. They are interpreted as libraries when the session permissions are checked since they start with an 'l' Workaround Don't use packet codes that start with an 'l' Solution chk_perm.c: When the packet code of a session starts with an 'l' the bshell AMS specific code will interprete this as a library. This is because the convert_name_for_level() looks at the first character of the item to be resolved for the level check. This has been changed. The convert_name_for_level() has a new parameter which tells whether it is called from get_session_perm_from_role() or get_library_perm_from_role() It will then generate the correct level string to match the permission. This however creates a new problem because the 'l' prefix is used primarily for libraries. The differences between session and library permissions is that session permissions do have a time frame while the library permissions don't have a time frame. When a role is found for sessions a time frame must be present and a role is ignored when the time frame is absent. When a role is found for libraries, only roles without a time frame are checked. This garantuees that the correct role is found for either session or library. Test Procedure Create a package code that starts with an 'l' e.g. la Try to start the session. The bshell should not core dump. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) xxxxx yyyyy zz TCS remark id(s) Priority (e.g. not workable) 100/55114 Medium MergeProject: Grieg: # 8611 (VHUX3442): Looping retry query Date: Tue, 11 Apr 2000 09:42:06 +0200 (METDST) Release: Grieg Date: 2000/04/11 Script: MergeProject Project: VHUX3442 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) Bshell loops on query with retry. Problem Description (Technical terms) A distributed query with a retry clause may cause the query processor to enter an infinite loop. This happens when the query is retried after is has been executed more than once. If this happens it is the client part of the query processor that enters the infinite loop (thus e.g. the bshell or qptool). Workaround There is no workaround. Solution The source code has been modified. Test Procedure Create a file 'query.txt' that contains the following query: select * from ttaad200 a, ttadv100 b where a.cpac refers to b order by a._index1 with retry as prepared set Configure tabledef such that table ttaad200 is accessed by a different driver than table ttadv100. For example: ttaad200:000:bisam(DUMMY):N *:*:bisam:N Run the query with qptool as follows: qptool6.1 -c 0 -apef1bef1bsref1bc -f query.txt This way the query is executed twice before it is retried. Verify that the query exits correctly. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 95060 516051 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8631 (VHUX3458): Put mail recepient to separate file (RFE of Process Support Group) Date: Fri, 14 Apr 2000 08:25:47 +0200 (METDST) Release: Grieg Date: 2000/04/14 Script: MergeProject Project: VHUX3458 Created on: BaanIVc Type: porting specific change Problem: Problem Description (Customer terms) Added some new scripts required for PS group. Problem Description (Technical terms) Added script to send mail after build of portingset has been completed. Created on request of Peter Voorthuijzen. Workaround Manually transfer file to NT host with outlook, and send e-mail.. Solution Added some new scripts in /general/porting directory Also adjusted blat/blatinst scripts in /ConfigTools/Util/Scripts/mail (outside this project) The new blat stuff has already been put on host srv-nld-maan. Upgraded blat version, and retrieved Alpha version of blat from internet (see Scripts/mail directory in the ConfigTools vob). Mail names of recipients have been put in a separete file. Test Procedure Send an e-mail by using sendreport.bat script on NT run (clear)make report on Unix to check changes. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8729 (SCUX3381): TaxFix Date: Tue, 25 Apr 2000 08:38:04 +0200 (METDST) Release: Grieg Date: 2000/04/25 Script: MergeProject Project: SCUX3381 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) Tax amounts are incorrect on order lines. Problem Description (Technical terms) The method used to decide when to accumulate taxes was incorrect. Have changed how it accumulates when it checks for NonTaxReasCd and ExemptReasCd. Workaround None Solution vertex.c: Fixes to calculations for "additional" taxes. Test Procedure Build new libraries. With the new libraries, create a new api. Using new api, test using the scenario which produced the incorrect results with the previous api. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 21413 214345 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8776 (VHUX3564): db.eq() call ignores database permissions Date: Fri, 28 Apr 2000 08:41:48 +0200 (METDST) Release: Grieg Date: 2000/04/28 Script: MergeProject Project: VHUX3564 Created on: Verdi2 Type: bugfix Problem: Problem Description (Customer terms) The db.eq() call ignores database permissions. This means that using the db.eq call it is possible to read data that the user is not allowed to read. Problem Description (Technical terms) There is no check to verify whether the row fetched with a db.eq call agrees with the permissions. Workaround Use an SQL select statement. For example, "db.eq( tdbtst120 )" may be replaced with "select * from dbtst120 where _index1 = {:dbtst120.empno}". Solution Modified the source code to check permissions in case of a db.eq() call. If a user has no permission to read a certain row, and he attempts to read that row using a db.eq() call, he will receive error 111 (E_BDB_NOREC). This behavior is consistent with other db.call() read functions and SQL select statements. Test Procedure Set up permissions as follows: dbtst120:000:-:empno = 20 Assume that dbtst120._index1 = empno and that it has the following records: empno ----- 10 20 30 Now execute the following gcommand script #1 dbtst120 REQUAL* 0 -i = dbtst120.empno = 10 #1 dbtst120 RUPD* 0 -i -E 208 = dbtst120.empno = 20 #1 dbtst120 RNEXT 0 -c c dbtst120.empno = 30 #1 dbtst120 REQUAL 0 -i -E 111 = dbtst120.empno = 20 The script should execute without errors. (Note that the db.next call should skip the record with empno=20 and that the second db.eq call will result in no record.) Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 79281 30 TCS remark id(s) Priority (e.g. not workable) - MergeProject: Grieg: # 8788 (VHUX3133): Stackoverflow 304 incorrected. Date: Fri, 28 Apr 2000 16:12:38 +0200 (METDST) Release: Grieg Date: 2000/04/28 Script: MergeProject Project: VHUX3133 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) When declaring minimal 18 values for an table field if the user may see the field or not. The session which accesses that table will crash, becuase of the many values specified. The session only crashes the first time it is started. When the session is started again during the same Baan session it won't crash again. The session ttaad4134m000 was used to enter the authorizations. Problem Description (Technical terms) The user got the following errors: Erreur: Stack overflow [QueryId = 8] (error 0) Erreur fatale: Error 304 (General SQL error) on SELECT Erreur fatale: Can not continue in tffbs1101m000 in DLL: ottstpstandard () The query processor may incorrectly detect an internal stack overflow when the query contains too many conditions. In this particular case, the query itself did not contain enough conditions to trigger this error. However, a database authorization condition was defined on one of the tables in the query. The query processor adds the database authorization conditions to the query. This triggered the error 304. Workaround n.a. Solution The database driver reserves a part of memory to store data. This is called the stack. If the size of the stack is not large enough the stack grows automatically. The database driver allocates more memory and the stacksize is increased. At some point a check was done if the current stackpointer was past the end of the stack. For this check a static value was used not the current stacksize. The check was changed to compare the current stackpointer with the current stacksize. Test Procedure Write a query that contains at least 100 AND conditions in the where clause. For example: select * from dbtst120 where empno = 10 and empno+0 = 10 and empno+0 = 10 ... Repeat the last line ( and empno+0 = 10) so that the query contains at least 100 AND conditions. Note, that it is important that the repeated AND condition cannot be used for an index scan. In this case this is forced by making it a subexpression. Run this query with qptool and verify that it returns the correct result and does not return error 304. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 89835 448729 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8802 (VHUX3468): Problem with long lines in debug Date: Mon, 1 May 2000 14:00:58 +0200 (METDST) Release: Grieg Date: 2000/05/01 Script: MergeProject Project: VHUX3468 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) When running session in debug the bshell will crash. This happens when the line in the debugger is very long. Problem Description (Technical terms) During debugging the line had to be displayed. However, the lenght of the line was to long so other memory parts where over written. Workaround N.A. Solution debug1.c: changing the lenght of variable to a define Test Procedure Compile a short script with a long line like: string.scan(vals,"%s^B%s^B%s^B%s^B ..... The test must be with 500 times "%s^B". Then compile this script in debug and run it. At the moment the debuger has to display this line the bshell will shut down and a core is generated. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 93053 477187 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8810 (VHUX3599): Changing the length for the vrc strucct Date: Mon, 1 May 2000 16:20:04 +0200 (METDST) Release: Grieg Date: 2000/05/01 Script: MergeProject Project: VHUX3599 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) When print reports to display with 'D', there is no horizontal scroll bar in display screen. If you resize the window where the print is, the scroll bar appears. Problem exists only when resolution is so small that whole print won´t fit to screen. Problem Description (Technical terms) The problem is in the size of a buffer. The vrc path is in the user file, but when the size is to large the string does not fit in the buffer, and you lose part of the vrc path. Workaround reduce the vrc path in the user file to less the 23 Solution rdi_fun.c: changing lenght of vrc struct Test Procedure change the user file and place a long vrc path of one of the packages. It must be more then 23, like: vrc_path:td:B40Cc4dev:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40 Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4 stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stn d:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B 40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40Uc4stnd:B40U c4stnd:B40 c4:B40 c3:B40 c2:B40 c1 Then execute the next script for that package: function main() { string vrctree(10,40) string cpac(2) long depth cpac = "td" depth =rdi.vrc.path(cpac,vrctree) } depth will not be higher then 23, and the last part of vrctree will not be complete. vrctree[22] "B40Sc5stnd" vrctree[23] "B4 " Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 96813 458246 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 8837 (VHUX3598): Bisam driver returns error 305 on float compare Date: Wed, 10 May 2000 08:21:46 +0200 (METDST) Release: Grieg Date: 2000/05/10 Script: MergeProject Project: VHUX3598 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) A session terminates with the error: Fatal error: Wrong row returned for table tirou410001 (error 0) Fatal error: Can not continue in tirou4201m000 in DLL otisfcdll0200 (get.company) tirou4201m000: A not terminated transaction is aborted Problem Description (Technical terms) The second field of Index 2 of table tirou410 is of type float. When a query, similar to the one below, was executed the bisam driver returned error 305 (wrong row returned). select * from tirou410 where tirou410._index2 > {"ZZZ",1046.57000,0} order by tirou410._index2 as set with 1 rows After the bisam driver fetches a record it checks all fields of this record against the search conditions in the query. In this case, the float field of index2 contained an approximation of the value 1046.57. This field needed to be compared against the double value 1046.57 specified in the query. To do so, the float value was converted to a double first. Because the float approximation of 1046.57 was actually slightly less than the double, the comparison failed and error 305 was returned. Workaround There is no workaround. Solution The check on fetched records in the level-1 drivers is modified. When checking a float field the float field is not converted to a double. Instead, the double value specified in the query is converted to a float. Test Procedure First, insert a record into table tirou410 with the following values: cwoc='ZZZ' wtcu=1046.57000 date=730285 (any date larger than 0 will do) The field wtcu is the float field of index2. Create a file "query.txt" that contains the following query: select * from tirou410 where tirou410._index2 > {"ZZZ",1046.57000,0} order by tirou410._index2 as set with 1 rows Execute the query using qptool and make sure you run it against the bisam driver: qptool6.2 -c 0 -f query.txt Verify that the query executes correctly and does not return error 305. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 92386 496968 20 504793 505173 830835 497662 502754 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8859 (VHUX3580): Level-1 driver returns duplicate rows Date: Mon, 15 May 2000 11:42:58 +0200 (METDST) Release: Grieg Date: 2000/05/15 Script: MergeProject Project: VHUX3580 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) Query returns duplicate rows. Problem Description (Technical terms) A query, similar to the query below, is expected to return a single record. However, the Oracle level-1 driver returns the expected record twice. select dbtst180.* from dbtst180, dbtst120 where dbtst180.empno = 100 and dbtst180.projno = 'OP2010' and dbtst180.empno refers to dbtst120 and ( not (2=4) or dbtst180.empno in (100,200) ) The error is triggered by a faulty cost calculation of the IN expression. The query processor is supposed to fetch at most one matching record from dbtst120. Due to the faulty cost, an incorrect execution tree is created which makes the query processor fetch matching records from dbtst120 for each "OR" branch that evaluates to true. This problem was reported on the Oracle level-1 driver, but may occur on all combi drivers (drivers that can run in level-1 or level-2 mode) that run in level-1 mode. The problem does not occur on level-2 drivers, nor does this problem occur on pure level-1 drivers (like bisam). Workaround There is no workaround. Solution Fixed the faulty cost calculation. Test Procedure Create a file "query.txt" that contains the above mentioned query. Make sure table dbstst180 contains at least one record that satisfies the query condition. Execute the query using qptool: qptool6.2 -c 0 -f query.txt Verify that the query returns the correct records and the correct number of records. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 91341 462938 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8888 (VHUX3655): Level-1 DB drivers: select count(*) optimisation Date: Tue, 16 May 2000 15:48:46 +0200 (METDST) Release: Grieg Date: 2000/05/16 Script: MergeProject Project: VHUX3655 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) Queries containing just a "count(*)" in the select clause and no where clause perform very badly on a level-1 database driver. Problem Description (Technical terms) Queries of the following form result in a full table scan on a level-1 database driver. select count(*) from table The database driver fetches all rows from the underlying database (using row level calls) to count the number of rows. This results in a lot of calls to the database, much data traffic and is far from optimal. Workaround One can use the db.nr.rows() call, but this will ignore any database permissions. Solution If the query is of the form described in the Problem Description (Technical terms) the database driver now issues a much faster "select count(*) from table" command against the underlying database. Note that optimisation will not take place if there are permissions (roles) defined that restrict read-access to the table. Test Procedure Run the following command. DBSLOG=020 qptool6.2 -c 0 -q "select count(*) from ttadv140" Verify that the dbs.log file contains an entry like the following. <25997> bkraats [1]--------- T_NRROWS 0 on ttadv140000 ------------ Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 93513 20 TCS remark id(s) Priority (e.g. not workable) N.a. MergeProject: Grieg: # 8891 (VHUX3525): DDC does not work when starting the bshell ui-less Date: Tue, 16 May 2000 15:50:02 +0200 (METDST) Release: Grieg Date: 2000/05/16 Script: MergeProject Project: VHUX3525 Created on: Corelli Type: bugfix Problem: Problem Description (Customer terms) DDC driver connection to UI-less Bshell does not work when handling events! Problem Description (Technical terms) The DDC driver can start the bshell by acting as a UI to the Bshell. In this scenario, a call to next.event waits for a result of the display driver for some strange reason! Workaround Solution ddc_baan.c: The DDC driver needs to send a DsAck acknowledge to the Bshell if initialization of the UI went correct or not! Because this message was not send, a future event of the DDC being sent to the Bshell was read incomplete. Incorrect scenario: DDC Bshell send 8 bytes dsNDllevent receive 5 bytes for ack event receive all bytes for an event! This caused the bshell to hang, since it needed more information from the UI in order to complete the request, but the UI failed to send it. The code of the DDC driver has been modified to send an acknowledge right after succesfull start of the bshell. Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 22648 459021 10 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8924 (VHUX3675): Fatal error : Error 205 (Out of Range) on cisli200613 in db_insert(51) Date: Fri, 19 May 2000 08:03:46 +0200 (METDST) Release: Grieg Date: 2000/05/19 Script: MergeProject Project: VHUX3675 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) An insert of a record leads to the error Fatal error : Error 205 (Out of Range) on cisli200613 in db_insert(51) Also, a log message is generated: cisli200.crpt not according to CONV (u) (value 'yyyy') Where 'y' is actually the y with two dots (character 255 in iso8859 character code sets). Problem Description (Technical terms) If a table field is in a domain that has the constraint "must be uppercase", the system C-function islower() was used to check this. The system islower() function's behaviour is not in line with the Baan conversion functions. For certain system locales the C-function islower() considers the "y with dots" to be lower case. The problem can occur on any character that has no upper case variant. Workaround None. Solution Now the Baan function iso_islower() is used to check whether strings are according to their domain. Also the function iso_islower() is modified to handle correctly cases where there is no distinction between lower and upper case characters. Test Procedure Run the following gcommand script and observe that inserting the records goes without problems. #1 ttaad200 RFIRST 0 #1 ttaad200 RINS 0 -i = ttaad200.user = gysje #1 ttaad410 RFIRST 0 #1 ttaad410 RINS 0 -i = ttaad410.dbse = SyBASE Note: the second character ('y') of both data strings must be replaced with the "y with dots". Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 95620 20 TCS remark id(s) Priority (e.g. not workable) - MergeProject: Grieg: # 8931 (VHUX3683): Change Mail from Freak to Eddie Date: Fri, 19 May 2000 09:54:26 +0200 (METDST) Release: Grieg Date: 2000/05/19 Script: MergeProject Project: VHUX3683 Created on: Verdi2 Type: porting specific change Problem: Problem Description (Customer terms) System Freak stopped services for buildprocess Problem Description (Technical terms) Eddie is in use instead of Freak Workaround Change by hand Solution Imakefile: System Freak changed in Eddie Test Procedure Done Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8959 (VHUX3701): Change Freak to Eddie Date: Tue, 23 May 2000 15:16:04 +0200 (METDST) Release: Grieg Date: 2000/05/23 Script: MergeProject Project: VHUX3701 Created on: Verdi2 Type: porting specific change Problem: Problem Description (Customer terms) Freak is not in use anymore, so some users were not reachable anymore Problem Description (Technical terms) bshell@freak.baan.com removed and buildrt@freak.baan.com moved to buildrt@baan.nl Workaround change Makefile by hand Solution maillist: Move Freak to Eddie reportlist: Move Freak to Eddie Test Procedure Test in general/porting: "make mail" and "make report" Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8966 (VHUX3711): Change Relnotes script Date: Wed, 24 May 2000 10:07:10 +0200 (METDST) Release: Grieg Date: 2000/05/24 Script: MergeProject Project: VHUX3711 Created on: Verdi2 Type: porting specific change Problem: Problem Description (Customer terms) Change ~sms to ~sms/bugfixes Problem Description (Technical terms) Change ~sms to ~sms/bugfixes Workaround Solution Relnotes: Change ~sms to ~sms/bugfixes Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8974 (VHNT3712): Double byte katakana resources Date: Wed, 24 May 2000 13:37:20 +0200 (METDST) Release: Grieg Date: 2000/05/24 Script: MergeProject Project: VHNT3712 Created on: Grieg Type: porting specific change Problem: Problem Description (Customer terms) New multibyte Katakana format of resource file Problem Description (Technical terms) see above Workaround none Solution bwprint.rc: Updated to double byte Katakana Test Procedure Let check text by people who understand Japanese Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 8977 (VHUX3715): Childs not deleted on cascade delete with auditing Date: Thu, 25 May 2000 08:50:04 +0200 (METDST) Release: Grieg Date: 2000/05/25 Script: MergeProject Project: VHUX3715 Created on: Verdi2 Type: bugfix Problem: Problem Description (Customer terms) Child record not deleted when parent record is deleted and reference mode is cascade delete. Problem Description (Technical terms) Under the following circumstances the child records were not deleted: - Reference mode is cascade delete - The parent table is audited - Primary key of the parent table contains a field of type enum Workaround There is no workaround. Solution Modified the code. Test Procedure Set up a set of tables as described in the section: "Problem Description (Technical terms)". Write a small gcommand script that deletes a parent record and verify that the child records are also deleted. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) 106/731 Critical MergeProject: Grieg: # 8984 (VHNT3718): New Japanese resoures Date: Thu, 25 May 2000 09:00:43 +0200 (METDST) Release: Grieg Date: 2000/05/25 Script: MergeProject Project: VHNT3718 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) Double byte katakana Japanese resource file added to BW resources. Problem Description (Technical terms) See above. Workaround None Solution bw.rc: Japanese double-byte katakana added. Test Procedure Test on Japanese Windows system. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) xxxxx yyyyy zz TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 9052 (VHUX3770): Retrieve portingset number from bversion.h Date: Wed, 31 May 2000 11:20:40 +0200 (METDST) Release: Grieg Date: 2000/05/31 Script: MergeProject Project: VHUX3770 Created on: BaanIVc Type: porting specific change Problem: Problem Description (Customer terms) Report at end of build (made by PS department) was not able to retrieve portingset version number Problem Description (Technical terms) Depends on project VHUX3690 which removed the portingset version number from COMPDATE Workaround (Fill this in) Solution Imakefile: Retrieve portingset version from bversion instead of COMPDATE Test Procedure Try make dump in /porting after a new Makefile was made. No error should occurr. The releasenumber should be filled in the template. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) Bugfix 6.2a: # 9067: Removed db2 delivery for SUN on Grieg Date: Tue, 6 Jun 2000 09:23:04 +0200 (MET DST) Release: 6.2a Date: 20000606 File Revision /vobs/general/porting/Imakefile /main/bugfix6.2a/26 /vobs/obj.SUN55/. /main/bugfix6.2a/6 /vobs/obj.SUN55/Util/imake/Project /main/bugfix6.2a/9 /vobs/obj.dbg.SUN55/. /main/bugfix6.2a/6 /vobs/obj.dbg.SUN55/Util/imake/Project /main/bugfix6.2a/13 Problem: Problem Description (Customer terms) Removed db2 delivery for SUN Problem Description (Technical terms) Workaround Solution Removed db2 for SUN Replaced MakeWorld script by /vobs/tt/MakeWorld Removed file element "MakeWorld". Added symbolic link "MakeWorld". Added db2 home Replaced MakeWorld script by /vobs/tt/MakeWorld Removed file element "MakeWorld". Added symbolic link "MakeWorld". Added db2 home Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) Bugfix 6.2a: # 9068: Removed patch command for db2 on SUN Date: Tue, 6 Jun 2000 09:27:50 +0200 (MET DST) Release: 6.2a Date: 20000606 File Revision /vobs/general/porting/Imakefile /main/bugfix6.2a/27 Problem: Problem Description (Customer terms) Addition to fix # 9067 Problem Description (Technical terms) Removed patch command for db2 driver on SUN Workaround Solution Removed patch command for DB2 for SUN Test Procedure run all target in porting dir Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9098 (VHNT3600): Desktop browser and BI Date: Fri, 9 Jun 2000 10:03:26 +0200 (METDST) Release: Grieg Date: 2000/06/09 Script: MergeProject Project: VHNT3600 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) I) If the user has set his startup program to desktop in the user data, the desktop is displayed with a wrong geometry. The shown window is to big, the right half of it consists only of background. All descriptions of the Icons are missing. II)When printing to display from any session in Baan when logged on via the BI Baan Internet server, the report display screen has the following problems. 1) No Menu bar is displayed. 2) No Tool bar is displayed. 3) The scroll bars dont work. (Both Horizontal and vertical) Problem Description (Technical terms) Several BI problems in Character Window and GWindow. Workaround None Solution DsGpart.java: Allow for using the Baan Desktop Manager BiCwindow.java: Allow for usage of the Display browser for showing reports DsGwindow.java: Allow for using the Baan Desktop Manager DsGpartRectangle.java: Menu browser Gwindow updates DsGpartText.java: Allow for using the Baan Desktop Manager DsScrollbar.java: Allow for usage of the Display browser for showing reports DsMessage.java: Allow for usage of the Display browser for showing reports DsMwindow.java: Improved layout management and resize events DsEdit.java: Allow for usage of the Display browser for showing reports DsScrollwindow.java: Allow for usage of the Display browser for showing reports DsDrawnbutton.java: Allow for usage of the Display browser for showing reports DsGpartPolyline.java: Menu browser GWindow updates DsCwindow.java: Allow for usage of the Display browser for showing reports Test Procedure - Test desktop browser with BI. - Test report writing to Display Browser with BI. (Note: also an update of ostpsplopen at the BaanERP server is needed for this). Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 86664 30 93952 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 9103 (VHUX3808): Removed b3 stuff from delivery for other OSs Date: Fri, 9 Jun 2000 10:37:49 +0200 (METDST) Release: Grieg Date: 2000/06/09 Script: MergeProject Project: VHUX3808 Created on: Corelli Type: porting specific change Problem: Problem Description (Customer terms) Removed again some middleware stuff, now for AS/400 Problem Description (Technical terms) Workaround Solution Imakefile: Remove b3 stuff Test Procedure Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9153 (VHUX3855): error in printerdaemon when time is 0 Date: Wed, 21 Jun 2000 08:44:47 +0200 (METDST) Release: Grieg Date: 2000/06/21 Script: MergeProject Project: VHUX3855 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) When trying to print a report on a device type 'printer' and specifying print time = 02:00, the print is not executed. In the device queue, the status is Error and the error message is 'Illegal record'. Problem Description (Technical terms) The problem is in the time setting of the system. The record will be saved with a time = 0 and this is the real problem. The printer daemon is doing a check if the time of the record is set to 0, and if so rejects the record. However, a time of 0 is a valid time. Workaround Change the time to a calue uneaual to 0. Solution pd_spool.c: remove check on time = 0 Test Procedure Start a print session like Print Paper Types. Choose a device of Printer-Type change the time to a value that will be represented by 0 in the table then print. Output should be created at the printer on the correct time. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 83286 807445 30 TCS remark id(s) Priority (e.g. not workable) N.A. MergeProject: Grieg: # 9160 (VHNT3782): Array inserting corrupts data on SQLServer Date: Wed, 21 Jun 2000 08:48:11 +0200 (METDST) Release: Grieg Date: 2000/06/21 Script: MergeProject Project: VHNT3782 Created on: BaanIVc Type: bugfix Problem: Problem Description (Customer terms) When running bdbpost.exe and the variable msql_max_arrsz is set in db_resource, the created records are all corrupted when the 'create rows before indexes' option is used. Problem Description (Technical terms) When the SQLServer driver uses array inserting, the data in string columns gets corrupted. For example, if you insert the following 4 records using array inserting with an array size 3: 'ABC' 'DEF' 'GHI' 'JKL' then the string values that are actually inserted are: 'ABC' 'EFG' 'I ' 'JKL' The problem was caused by the fact that the SQLServer driver calculated the array element size incorrectly for string columns and hash columns. For string columns and hash columns it calculated an array element size that was exactly 1 larger than the actual column size. Workaround Disable array inserting to prevent data corruption when using bdbpost with the -f option (create rows before indexes). Solution The SQLServer driver code is modified. It now calculates the array element size correctly. Test Procedure Import a table using bdbpost with the -f option. Make sure that the table contains at least one column of type string. Also make sure that the table contains at least one index with a string column, to verify that the hash columns are filled correctly. bdbpost6.2 -k -n -m -f -c0 < ttaad200.dump Execute a query using qptool to verify that the data has been inserted correctly: qptool6.2 -c 0 -q "select * from ttaad200" Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 96944 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9164 (VHUX3825): Wrong index hint with INRANGE operator on Oracle Date: Wed, 21 Jun 2000 09:14:17 +0200 (METDST) Release: Grieg Date: 2000/06/21 Script: MergeProject Project: VHUX3825 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) Problem Description (Technical terms) The following query takes a long time to complete, because the Oracle driver does not select the most optimal index hint: select cprmp120.* from cprmp120 where cprmp120._index2 = { 'VD1', 1, ' MM' } and cprmp120._index2 inrange {'VD1', 1, ' MM', 1} and {'VD1', 1, ' MM', 9 } When determining the index hint, the driver only checked the first column of the combined column _index2. This was due to fix VHUX3113. Because the first column of _index2 and _index1 are the same, the driver selected index1 for its index hint. It should have selected index2. Note, however, that prior to fix VHUX3113 the driver may also have selected the wrong index hint here. This is because of the inrange expression. For the inrange expression, the driver considered all 6 columns of _index2 even though only 4 are actually specified. The two columns that are not specified are also columns of index1. This would make index1 and index2 equal candidates for the index hint. Workaround There is no workaround. Solution Modified the hint selection mechanism. The proper columns of the where clause are now considered for index hint selection. Test Procedure Create a file "query.txt" that contains the above mentioned query. Execute the query using qptool with DBSLOG=400: DBSLOG=400 qptool6.2 -c 0 -f query.txt Examine the dbs.log file and verify that the index2 is hinted. The dbs.log file should contain one SQL query that contains the following hint after the select keyword: /*+ FIRST_ROWS index(a tcprmp120813$idx2) */ Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 94851 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9272 (VHNT3523): Expand BSE and BSE_TMP in the argument of run.prog using backslashes in case of OS is Windows. Date: Tue, 4 Jul 2000 11:18:31 +0200 (METDST) Release: Grieg Date: 2000/07/04 Script: MergeProject Project: VHNT3523 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) When starting a program using run.prog() on Windows platform, and the arguments of this program contains ${BSE} or ${BSE_TMP), ${BSE} or ${BSE_TMP} is expanded using unix slashes. Therefor the program started cannot use these arguments. Problem Description (Technical terms) Because the argument is only passed through to the program started, the slashes should not be converted to unix slashes, while explanding ${BSE} or ${BSE_TMP}. Workaround Hardcode the path in the argument of run.prog(). Solution al_proto.h: Added declarations for new functions get_bse_ex, get_bse_tmp_ex, expand_fname_ex. sh_server.c: New function expand_fname_ex calls original function expand_fname, and passes new argument TreatAsArgument to the original function expand_fname. Now expand_fname_ex is called, and variable TreatAsArgument is set to 1 in case ${BSE} or ${BSE_TMP} are part of the argument. al_fpath.c: In case of get_bse and get_bse_tmp now new functions get_bse_ex and get_bse_tmp_ex are used. These functions calls the original functions get_bse and get_bse_ex, and passes new argument TreatAsArgument. al_gtenv.c: New functions get_bse_ex and get_bse_tmp_ex calls original functions get_bse or get_bse_tmp, and passes the argument TreatAsArgument. Functions get_bse and get_bse_tmp modified in that way in case TreatAsArgument=1, no conversion to unix slashes is made. Also made modification for re-using the expantions of ${BSE} or ${BSE_TMP} in case TreatAsArgument 1. Test Procedure Run the following script on Windows platform: string shell.arg(300) string shell.cmd(300) long ret function main() { shell.cmd = "${BSE_TMP}\test.bat" shell.arg = "${BSE_TMP}\test" ret = run.prog(shell.cmd, shell.arg, RP_WAIT) shell.cmd = "${BSE}\test.bat" shell.arg = "${BSE}\test" ret = run.prog(shell.cmd, shell.arg, RP_WAIT) } Test are done having ${BSE} or ${BSE_TMP} set in the system environment variables, and tests are done having these variables not set. By using the 4GL debugger you can jump back in to a previous line and repeat commands to test re-use of earlier expanded variables. The test.bat program contains the following lines: echo "%1 %2 %3" >> c:\temp\testbat_output type "%1 %2 %3" >> c:\temp\testbat_output so you can check if the argument is correctly. (Open testbat_output) Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 99064 838536 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 9280 (VHNT3900): Use of correct slashes for path BSE and BSE_TMP when used in argument of program started by app_start Date: Wed, 5 Jul 2000 12:34:15 +0200 (METDST) Release: Grieg Date: 2000/07/05 Script: MergeProject Project: VHNT3900 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) When starting for example a program like: winword ${BSE_TMP}\worddoc on a windows platform, winword cannot find worddoc because the ${BSE_TMP} is expanded using unix slashes. Problem Description (Technical terms) To start winword app_start(winword "${BSE_TMP}\worddoc", ${BSE_TMP}, "", stdout, stderr) is used. When expanding ${BSE_TMP} conversion is made to unix slashes. Workaround Hardcode the path to worddoc. Solution applobj.cpp: Call expand_fname_ex instead of expand_fname and pass TreatAsArgument=1 By setting TreatAsArgument to 1, no conversion to unix slashes is done by function get_bse(_tmp) in al_gtenv. Refer to project VHNT3523. Test Procedure Take care a text file "worddoc" is available in ${BSE_TMP} on the pc running bw.exe Execute app_start(winword "${BSE_TMP}\worddoc", ${BSE_TMP}, "", stdout, stderr) Winword should be able to find and open worddoc now. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 96914 506137,535271,831502 20 TCS remark id(s) Priority (e.g. not workable) xxxxx MergeProject: Grieg: # 9291 (VHNT3611): SHIFTJIS & KANJIEUC: add Microsoft CP932 extensions Date: Thu, 6 Jul 2000 09:32:28 +0200 (METDST) Release: Grieg Date: 2000/07/06 Script: MergeProject Project: VHNT3611 Created on: Corelli Type: bugfix Problem: Problem Description (Customer terms) Microsoft CP932 extensions are not available in ShiftJIS and KanjiEUC charsets, especially the Unicode conversion Problem Description (Technical terms) Microsoft has added three extensions to the ShiftJIS character set. The ShiftJIS character set has lead byte range 81-9F and E0-EF (47 positions), and trail byte range 40-7E and 80-FC (188 positions), in total 47*188=8836 positions. Highest actually used value is EAA4. The microsoft extensions are: 1. 8740-879C this extension is inside the ShiftJIS range. 2. ED40-EEFC this extension is inside the ShiftJIS range, but above the highest actually used ShiftJIS character EAA4. 3. FA40-FC4B this extension is outside the ShiftJIS range. In Kanji and KanjiEUC the same 8836 positions are encoded differently. Kanji uses the range 21-7E (94 positions) both for lead bytes and trail bytes, total 94*94=8836. KanjiEUC sets the most significant bit of each byte and uses A1-FE both for lead bytes and trail bytes. The Baan character set TSS uses the Kanji encoding for these 8836 positions, and prepends 9B21 to it. In this project, Microsoft CP932 extensions 1 and 2 are added to the Unicode files for ShiftJIS and Kanji(EUC). Extension 3 is not (yet) supported. Currently there are no codes available for it in Kanji(EUC) and TSS. In projects 3613 and 3614 the maximum form and maximum sort values for the corresponding character sets are adapted in $BSE/lib/tss_locale6.x. Workaround Don't use the Microsoft extensions Solution SHIFTJIS.txt: Add extensions 1 and 2 KANJI.txt: add two Microsoft CP932 extensions: map 8740-879C extension to 2D21-2D7C, map ED40-EEFC extension to 7921-7C7E. leave third extension FA40-FC4B extension unmapped generate: adapt leadbyte ranges KANJIEUC.U2N: add Microsoft CP932 extensions KANJIEUC.N2U: add Microsoft CP932 extensions SHIFTJIS.U2N: add Microsoft CP932 extensions SHIFTJIS.N2U: add Microsoft CP932 extensions Test Procedure use Microsoft extension characters and try Unicode conversion Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 95549 522699 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9292 (VHNT3457): UNICODE: replace METAMAX by max sort value Date: Thu, 6 Jul 2000 10:27:38 +0200 (METDST) Release: Grieg Date: 2000/07/06 Script: MergeProject Project: VHNT3457 Created on: Corelli Type: bugfix Problem: Problem Description (Customer terms) Client software does not know what to fill in for range maximum Problem Description (Technical terms) each locale has its own maximum sort value, but client software does not know its value Workaround none Solution mbfun.c: in Unicode-to-native conversion, replace U+FFFD (Replacement Character) by maximum multi byte sort value from the locale, and replace U+7F (Delete) by maximum single byte sort value from the locale. Test Procedure Insert the special 'metamax' chars into an XML document and parse it. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9293 (VHNT3475): TSS: adapt max sort values Date: Thu, 6 Jul 2000 10:29:27 +0200 (METDST) Release: Grieg Date: 2000/07/06 Script: MergeProject Project: VHNT3475 Created on: Corelli Type: bugfix Problem: Problem Description (Customer terms) max form and sort values of many locales are incorrect Problem Description (Technical terms) values were filled in without knowing exact meaning of the fields. Workaround none Solution tss_locale6.2: adapt several values mb: merge from Verdi-2 branch Added directory element "tabledumps". ttttss002000.S: adapt several values Test Procedure compare with values on saturn (/usr5/baan5/bse/lib/tss_locale6.2) Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9294 (VHNT3520): tssinfo: solve compiler errors caused by VHNT3457 Date: Thu, 6 Jul 2000 10:30:21 +0200 (METDST) Release: Grieg Date: 2000/07/06 Script: MergeProject Project: VHNT3520 Created on: Corelli Type: bugfix Problem: Problem Description (Customer terms) compiler error in tssinfo.c Problem Description (Technical terms) struct field changes in tss.h Workaround none Solution tssinfo.c: some new and some renamed locale fields mbfun.c: repair badfix VHNT3457 Test Procedure compile Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9295 (VHNT3535): TSS: adapt CP932 max multibyte values Date: Thu, 6 Jul 2000 10:31:09 +0200 (METDST) Release: Grieg Date: 2000/07/06 Script: MergeProject Project: VHNT3535 Created on: Corelli Type: bugfix Problem: Problem Description (Customer terms) CP932 max multibyte value is incorrect. Caused in VHNT3475 and VHNT3478. Problem Description (Technical terms) According to unicode file for CP932, the highest character is 0xFC4B, but the conversion to TSS supports only the range 0x8140-0xEFFC. The highest character in this range for which unicode is available, is 0xEEFC. Workaround Adapt tss_locale6.x file by hand Solution tss_locale6.2: adapt CP932 max multibyte values ttttss002000.S: adapt CP932 max multibyte values Test Procedure run tssinfo Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9296 (VHNT3613): tss_locale: adapt ShiftJIS and KanjiEUC max values Date: Thu, 6 Jul 2000 10:32:07 +0200 (METDST) Release: Grieg Date: 2000/07/06 Script: MergeProject Project: VHNT3613 Created on: Verdi2 Type: bugfix Problem: Problem Description (Customer terms) $BSE/lib/tss_locale6.2 must contain correct max values for the MetaMax feature (see project 3457). These values must be adapted after the changes by project 3611 (Microsoft CP932 extensions). Problem Description (Technical terms) See projects 3457, 3475, and 3611. Workaround None Solution tss_locale6.2: adapt file header and max values for ShiftJIS and KanjiEUC char sets ttttss002000.S: adapt max values for ShiftJis and KanjiEUC Test Procedure use Metamax feature for corresponding locales Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) 95549 522699 20 TCS remark id(s) Priority (e.g. not workable) MergeProject: Grieg: # 9301 (VHNT3956): Modification of VHNT3523 caused core dump of sum6.2 on DEC Date: Thu, 6 Jul 2000 14:07:58 +0200 (METDST) Release: Grieg Date: 2000/07/06 Script: MergeProject Project: VHNT3956 Created on: Grieg Type: bugfix Problem: Problem Description (Customer terms) sum6.2 core dumps on DEC Problem Description (Technical terms) strsave in function get_bse of al_gtenv is executed on null pointer. Workaround No Solution al_gtenv.c: strsave now done on correct variable. Test Procedure Expand variable BSE or BSE_TMP for the first time. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) xxxxx yyyyy zz TCS remark id(s) Priority (e.g. not workable) xxxxx Bugfix 6.2a: # 9309: Fixed bug in retrieving version number (merge changes of Reger) Date: Fri, 7 Jul 2000 11:35:12 +0200 (MET DST) Release: 6.2a Date: 20000707 File Revision /vobs/general/porting/Imakefile /main/bugfix6.2a/29 Problem: Problem Description (Customer terms) Bug in retrieving version number via bversion.h Problem Description (Technical terms) Workaround Solution Applied fix on retrieving version number Test Procedure Deliver portingset and check version number in report. Scopus defectnumber(s) Scopus casenumber(s) Priority (e.g. 10) TCS remark id(s) Priority (e.g. not workable)