PRODUCT   :  R:BASE                  VERSION      :  3.1
   Here are workarounds for verified problems. A Microrim reference number 
   is included at the end of each description.  Those marked "Fixed in 3.1C"
   have been corrected in release C of Upgrade Express, which can be ordered
   by calling 1-800-628-6990.
   R:BASE 3.1
   DATE Setting & dBASE Dates
   Dates in an attached dBASE file display as null when the R:BASE DATE 
   SEQUENCE is set to anything except MMDD(YY)YY. R:BASE reads a dBASE 
   date as a text string and converts the text string for display using 
   the default DATE SEQUENCE, which is MMDD(YY)YY. It doesn't matter what 
   the DATE FORMAT setting is. #3614
   WORKAROUND:  Change the DATE SEQUENCE setting to MMDD(YY)YY to force 
   R:BASE to display the dates correctly. 
   Folding Table in RBASE.CFG
   The folding table in the RBASE.CFG contains some errors. Some of the 
   high- order ASCII characters aren't mapped correctly for indexed column 
   comparisons. #3590
   WORKAROUND:  Make the following corrections to the RBASE.CFG file in 
   the folding table:
   <>  Change CASEP 130 69 to CASEP 130 144
   <>  Change CASEP 135 67 to CASEP 135 128
   <>  Add LCFOLD 128 135
   <>  Add LCFOLD 144 130
   The -T2 Startup Option
   When you start R:BASE using the -T2 option (RBASE -T2), R:BASE scrolls 
   the data on line 25, but it will not scroll the screen. When screen 
   output reaches line 25, R:BASE stops there and scrolls until you issue 
   a CLS command. Then everything is fine until you reach line 25 again. #3593
   WORKAROUND:  None, other than not using the -T2 option when starting 
   Negative Numbers in CTXT
   If you use a literal negative number in the CTXT function (for example, 
   (CTXT(-4))) R:BASE displays this error message: "Text function arguments 
   must be constants, columns, or variables. Expression cannot be evaluated." 
   #3600, Fixed in 3.1C
   WORKAROUND:  Put the negative number in a variable. Then use the dotted 
   variable in the CTXT function:
   SET VAR vnum INTEGER = -4
   SET VAR vtxt = (CTXT(.vnum))
   Report Locations & the Mouse
   After you locate a field in a report, R:BASE no longer allows you to 
   click the mouse to position the cursor on the screen. If you click the 
   mouse, R:BASE moves the cursor up to the menu instead of moving it to 
   the indicated screen location. You can use the mouse to move the cursor 
   to the right of the current cursor position on the same row, but that's 
   all. Even after typing other characters or using the arrow keys to move 
   the cursor, clicking the mouse takes you back and forth from the menu 
   only after you've located the first field. #3598
   WORKAROUND:  Use the arrow keys to move the cursor into position to 
   locate the second and subsequent fields in a report.
   When removing a view in R:BASE 3.1, use this command:
   DROP VIEW viewname
   If you use DROP TABLE instead of DROP VIEW, R:BASE correctly gives you 
   an error message. The problem is that the error message, -ERROR- Cannot 
   use REMOVE TABLE command for a view, use REMOVE VIEW, mentions the 
   REMOVE command instead of the DROP command. REMOVE is an undocumented 
   command in R:BASE 3.1. #3580
   WORKAROUND:  Use DROP VIEW to remove a view.
   DROP COL for Computed Column
   It seems to work correctly when you drop a computed column from a table 
   by using the DROP COLUMN or REMOVE COLUMN command at the R> prompt. But 
   if you look at the SYSCOMP table through R:SCOPE (a product available 
   for sale from Microrim), you can see that the row for that computed 
   column has not actually been deleted. You can add the column back with 
   a different definition, but each time you drop the column the row remains 
   in SYSCOMP. Eventually, you can get to a point where you can't add or 
   redefine the computed column. #3607
   WORKAROUND:  Drop computed columns by using the menus instead of the R> 
   prompt. Choose Create/modify under Data~bases, and then choose to modify 
   the table. When the cursor is on the column you want to remove, press 
   [F9]. When you use the menus to remove the computed column, R:BASE 
   doesn't leave rows in SYSCOMP. 
   Transaction Processing Settings
   If you have MULTI (multi-user) set OFF, TRANSACT (transaction processing) 
   set ON, and AUTOCOMM (automatically commit changes) set ON, R:BASE doesn't 
   update database file 1 (DBNAME1.RBF, the database definition file) 
   correctly when you add rows to a table. The actual disk size of database 
   file 2 (DBNAME2.RBF, the data file) increases, but F2SIZE in file 1 
   doesn't reflect the new size. You can illustrate this by using the 
   following commands:
   LIST tblname
   COMPUTE COUNT(1) FROM tblname
   SELECT COUNT(*) FROM tblname
   The last two commands read database file 2 and display the correct, 
   updated number of rows in the table. But the first two commands read 
   database file 1 and display the number of rows that were in the table 
   before the new row was added. In other words, the results from COMPUTE 
   COUNT and COMPUTE ROWS don't match. In addition, R:BASE can't find the 
   new row. The SELECT...WHERE COUNT=LAST command says no rows satisfy the 
   WHERE clause, and the SELECT * command with no WHERE clause doesn't 
   display the new row.
   Sometimes you won't be able to see the problem until you disconnect from 
   the database and then later reconnect to it. #3608
   WORKAROUND:  You will usually have MULTI set ON when using transaction 
   processing because you're sharing the data~base with others, so you won't 
   run into this problem. If you must have MULTI set OFF and you want to use 
   transaction processing, however, set AUTOCOMM OFF and enter the COMMIT 
   command to manually commit changes after you enter a command.
   If the results of the COMPUTE ROWS and COMPUTE COUNT commands don't match, 
   you can use PACK or RELOAD to correct the problem, but you'll have to 
   reenter the new rows. If the data~base resides on the network, disconnect 
   from the database and then reconnect it with MULTI set OFF before using 
   COMPUTE ROWS and COMPUTE COUNT to check it. Alternatively, use R:SCOPE to 
   Grant/Revoke & Variable Forms
   You might have a problem with the display in variable forms if you're 
   using the Grant/revoke password system and you aren't the owner. Only 
   the first variable on the variable form displays a value; the other 
   variables display their values as you move into the field. If you use 
   the DRAW WITH ALL command, all the variables display briefly and then 
   disappear as R:BASE executes the EDIT VAR command. If you are the owner 
   or use ENTER VAR instead of EDIT VAR, all the variable values display 
   correctly. #3603
   WORKAROUND:  Many possible workarounds exist. Here are a few examples:
   <>  Replace the variable form with FILLIN and other R:BASE commands
   <>  Use a table form instead of a variable form
   <>  Enter the owner password before using a variable form and then set 
       it back to the current user afterward
   If you issue a BROWSE DISTINCT command and then press [Ctrl-F3] twice 
   in a row to go into QBE (Query By Example) and immediately return to 
   the Browse/edit screen, R:BASE displays a couple of junk rows containing 
   spurious data (very large numbers), and your computer might stop 
   responding. #3611, Fixed in 3.1C
   WORKAROUND:  None, other than doing something in QBE before you again 
   press [Ctrl-F3] to return to the Browse/edit screen.
   Rules that Look into dBASE Tables
   This problem occurs exclusively in multi-user environments when you use 
   EDIT * FROM tblname and tblname has a rule that verifies a value by 
   checking acceptable values listed in a dBASE table. When you enter a 
   new value that breaks the rule, R:BASE continues to display the old 
   value without highlighting the field. The highlight reappears if you 
   enter a valid value or press [F5] to reset the field.
   If the rule-protected column is an INTEGER, R:BASE displays the rule's 
   error message but fails to highlight the field when you press a key. If 
   the rule-protected column is TEXT, R:BASE displays this message: Another 
   user has updated/changed this row. Press any key to continue. This 
   erroneous message is displayed in red on gray; again R:BASE doesn't 
   highlight the field when you press a key.
   Because no field is highlighted and the value shown in the field is the 
   old (acceptable) value, you can't be sure where the cursor is and thus 
   might keep pressing [Enter]. If you do, R:BASE continues to display the 
   error message and you might think the computer has stopped responding 
   to input. #3615, Fixed in 3.1C
   WORKAROUND:  Enter a new, acceptable value or press [F5] to reset the 
   Converting from DATE to TEXT
   In both Personal R:BASE and R:BASE 3.1, you are supposed to be able to 
   convert a column from DATE to TEXT. In the RBDEFINE menus (choose 
   Create/Modify under Databases), however, TEXT is not listed as an 
   acceptable new data type; NOTE, DATE, and COMPUTED are the only 
   acceptable choices. #3617
   WORKAROUND:  If you have R:BASE 3.1, use the REDFINE command from the R> 
   prompt to convert DATE into TEXT directly.
   If you have Personal R:BASE, you must use the menus, so change the 
   column's data type from DATE to NOTE and save the table. Then choose 
   to modify the table again and change the column from NOTE to TEXT.
   It is possible to damage a database when all of the following conditions 
   are true:
   <>  You are using the EDIT command with a multi-table form that has a 
       lookup expression defined on the first table in the form
   <>  The EDIT command includes an ARRANGE BY clause to sort the rows in 
       the lower tables and an ORDER BY clause to sort the rows in the 
       first table
   <>  You press [F8] to move to the next row in the main (first) table or 
       choose Next row under Go to on the menu
   Under these conditions, you might get this error: Disk Problems. Check 
   disk and files. When you press a key, R:BASE sends you to the menu or 
   to DOS. It's possible that database file 1 will no longer be usable.
   #3613, Fixed in 3.1C
   WORKAROUND:  None, other than avoiding one or more of the conditions 
   listed above.
   RENAME FORM & Variable Forms
   If you try to rename a variable form from the R> prompt with the RENAME 
   FORM command, R:BASE displays this error message:  is a 
   undefined form. #3618
   WORKAROUND:  Use the Forms Create/modify menu to change the name of a 
   variable form. 
   The LOAD DATA FROM  AS ASCII command loads the null symbol as 
   a literal -0- (or whatever the current NULL setting is) instead of as a 
   null in TEXT fields. This problem occurs only with TEXT columns. R:BASE 
   correctly loads null values into the other data types. #3616
   WORKAROUND:  If you omit the AS ASCII clause, the command works correctly 
   but more slowly. To use the faster AS ASCII option, set your null symbol 
   to either a four-character code or a blank before unloading the data. For 
   example, use either of these two commands before unloading your data:
   SET NULL '<~>'
   SET NULL '-00-'
   LOAD...AS ASCII loads a null value correctly if R:BASE sees two commas 
   right next to each other (,,). The four-character code works because 
   R:BASE stores all TEXT values in a minimum of four bytes, so if a value 
   has fewer than four characters, R:BASE does not match it with the null 
   If you use the DISTINCT option on the BROWSE command, switch to QBE 
   (Query By Example) to add a condition, and then return to browse through 
   the table, the rows are no longer distinct you see all the rows, not just 
   the distinct ones.
   To illustrate, issue this command:
   BROWSE DISTINCT empid,empstate FROM employee
   Press [Ctrl-F3] to add this condition:
   WHERE empid 100
   Then press [Ctrl-F3] to return to browse the data. Now all the rows are 
   displayed, not just the distinct rows. #3610 - Fixed in 3.1C
   WORKAROUND:  Include a WHERE clause on the initial BROWSE DISTINCT 
   command, then you can add conditions in QBE without incident. If you 
   remove all the conditions, the problem will recur  you'll get all 
   rows instead of just distinct rows.
   INDEXR program in R:SCOPE
   INDEXR, a program that comes with R:SCOPE, builds indexes quickly. But 
   INDEXR doesn't build indexes on TEXT columns that contain high-order 
   ASCII characters in the same way that R:BASE does. R:BASE uses the 
   folding table in the RBASE.CFG file to determine equivalence between 
   upper and lower case and with regular ASCII characters. INDEXR looks 
   at each character as being a different, unique value. Therefore, R:BASE 
   treats uppercase foreign characters as equal in value to lowercase 
   foreign characters when it builds indexes so it builds a multiple 
   occurrence table (MOT), but INDEXR builds its indexes as if the uppercase 
   and lowercase values are distinctly different values. As a result, an 
   indexed search using R:BASE-built indexes will find different values 
   than does an indexed search using INDEXR-built indexes. #3592
   WORKAROUND:  If you're using foreign characters or other high-order 
   ASCII characters in your data, use R:BASE to build indexes, not INDEXR.
   Checking Indexes in R:SCOPE
   When R:SCOPE checks the index on a TEXT column that contains a blank 
   value, it reports an error: "No index file references were found for 
   the following values: < > at the data file address 
." R:BASE has no trouble finding a blank value in an indexed TEXT column. #3582 WORKAROUND: Ignore the erroneous R:SCOPE error message. No problem exists because R:BASE won't have any trouble finding the index file references. R:SCOPE & Directories ===================== R:SCOPE will not list directory names that include extensions when you want to change to a new directory. #3587 WORKAROUND: Choose Other... and then enter the full path, or change to the directory before you start R:SCOPE. R:SCOPE & Indexes ================= R:SCOPE can't find index entries for the lowercase high-order ASCII characters (CHAR(129) or higher). R:SCOPE displays this error: "No index file references were found for the following values: at the data file address
." It does find entries for the uppercase characters. R:BASE has no trouble finding them on an indexed search. #3591 WORKAROUND: Ignore the erroneous R:SCOPE error message. No problem exists because R:BASE won't have any trouble finding the index file references.