=======================================================================
JANUARY/FEBRUARY 1992 PROBLEMS & WORKAROUNDS
=======================================================================
PRODUCT : R:BASE VERSION : 3.1
CATEGORY : BUGS/WORKAROUNDS SUBCATEGORY : PROBLEMS/ANOMALIES
=======================================================================
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
R:BASE.
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.
DROP VIEW Versus DROP TABLE
===========================
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 ROWS FROM 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
recover.
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
BROWSE DISTINCT & QBE
=====================
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
field.
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.
ARRANGE BY & ORDER BY
=====================
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.
LOAD DATA...AS ASCII
====================
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
symbol.
BROWSE DISTINCT & QBE
=====================
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.
R:SCOPE
=======
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.