home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: InfoMgt / InfoMgt.zip / dbup208.zip / README.TXT < prev    next >
Text File  |  1999-09-02  |  49KB  |  892 lines
  1.  
  2.     DBExpert(tm) Relational Database for OS/2 from Sundial Systems
  3.     Release Notes (README.TXT) for DBExpert Version 2.0.8
  4.     September 1999
  5.  
  6.  
  7.     Thank you for using DBExpert Version 2.0 for OS/2.  This file contains
  8.     information which became available after the DBExpert User's Guide and 
  9.     Getting Started documents went to press.
  10.  
  11.  
  12.     What is Version 2.0.8?
  13.  
  14.     Version 2.0.8 is a maintenance release of the DBExpert 2.0 series.  In
  15.     general, the features of this version are identical to earlier releases
  16.     within the 2.0 series -- the primary differences are bug fixes, stability
  17.     improvements, and other corrections.
  18.  
  19.     A few significant changes have been made, however, which may affect your
  20.     use of the product.  These are outlined in the "Changes Of Interest To
  21.     All Users" sections below.
  22.  
  23.  
  24.     IMPORTANT Y2K INFORMATION
  25.  
  26.     A problem has been found in Versions 2.0.6 and 2.0.7 of DBExpert that
  27.     will affect the display of 2-digit dates once your PC clock rolls over 
  28.     to the year 2000.  The problem has been corrected in Version 2.0.8.
  29.  
  30.     While the problem will not affect your use of DBExpert until January 1,
  31.     2000, we strongly urge you to upgrade all your copies of DBExpert (full
  32.     and runtime versions) to 2.0.8 before that time.
  33.  
  34.     If, for some reason, you cannot upgrade to 2.0.8 and wish to address this
  35.     issue, contact technical support about availability of an updated DLL
  36.     to correct this problem in Version 2.0.7.
  37.  
  38.  
  39.     IMPORTANT INFORMATION IF UPGRADING FROM VERSION 2.0.4 OR EARLIER
  40.  
  41.     Beginning with Version 2.0.5 of DBExpert, significant changes were made
  42.     in the way dBase-style tables are "saved" when you make updates to the
  43.     definition of the table (via the Table Designer).  These changes may impact
  44.     your use of DBExpert tables with other applications.
  45.  
  46.     In the past, DBExpert (usually) saved a table into the DBExpert directory
  47.     even if the table was originally in a different directory.  Now, the table
  48.     is saved in its original location.  Further, in the past, the physical
  49.     table file(s) (DBF file and, optionally, DBT and index files) were given a
  50.     new name.  Now, the file names are preserved.
  51.  
  52.     In general, these changes are for the better.  However, if you are sharing
  53.     these tables with another application, you should consider if this change
  54.     will have any impact on that application or on your use of DBExpert.
  55.  
  56.     In particular, it was previously possible to "save" a table while it was
  57.     in use by another application (since a new table was actually being 
  58.     created from the old one).  This is no longer possible -- if the table is
  59.     in use (by another application or by another copy of DBExpert), it cannot 
  60.     be saved.
  61.  
  62.     Also, be aware that changes you make to a table could impact the other
  63.     application -- so we *strongly* recommend that you backup any such tables
  64.     and verify that versions you now save will be properly handled by any 
  65.     other such applications you use on the same tables.
  66.  
  67.     Further, as discussed below, DBExpert now includes the ability to "pack"
  68.     dBase-style tables to reclaim wasted space.  This packing operation works
  69.     much the same way (under the covers) as a "save" does -- thus all of the
  70.     above considerations apply when you Pack as well as when you Save.
  71.  
  72.     Finally, for this new save/pack method to work correctly, you must not
  73.     have changed the FileOpenCache setting of the "QEDBF[Q+E dBASEFile (*.dbf)]"
  74.     ODBC driver.  (The default setting is correct -- you may ignore these
  75.     instructions unless you have previously used the ODBCADM program to change
  76.     the default value.)   The value of this setting must be blank or zero.
  77.     If it is not, you will probably get unexpected "Table in use" errors 
  78.     whenever you try to Save a modified table design or Pack a table.  
  79.  
  80.     (Despite the similar name, do not confuse this setting -- FileOpenCache --
  81.     with the Cache Size setting; the two are unrelated and you may still wish
  82.     to adjust the default Cache Size setting as discussed elsewhere.)
  83.  
  84.  
  85.     Documentation Notes
  86.  
  87.     * The DBExpert User's Guide and Getting Started documents use a mix of old
  88.       (DBExpert 1.x) and new (DBExpert 2.x) style names for the various
  89.       different DBExpert functions you can use in queries, forms, and macros.
  90.       The new names are the same as the old names, except that the prefix
  91.       "dbe" has be added to the beginning.  (For example, dbeLoadPicture vs
  92.       LoadPicture.)  
  93.  
  94.       When working with DBExpert 2.x, the new style names are preferred and
  95.       should be used -- the old style names are primarily retained for
  96.       compatibility with Version 1.x DBExpert applications.  In all cases,
  97.       both names refer to the same actual function and only the new names are
  98.       documented (in Chapter 15 of the User's Guide).
  99.  
  100.     * Various examples in the User's Guide and in the Getting Started documents
  101.       inconsistently use different types of quote marks to surround strings.
  102.       For example: 'A', `A', and "A".   While either single or double quotes
  103.       can be used, they must be used in matching pairs.  (If you are using 
  104.       DBExpert with DB2, only single quotes may be used in queries due to a
  105.       limitation discussed later.) The "single left quote" (also known as a
  106.       grave accent) shown in the middle example cannot be used (either singly
  107.       or in pairs).
  108.  
  109.     * On page 9-19 of the User's Guide, the example of CharToDate is incorrect
  110.       because it is missing the required second parameter.  It should read:
  111.         < CharToDate("2/5/95","GD")       Date value is before 2/5/95
  112.       or, more properly (using the DBExpert 2.x style function name):
  113.         < dbeCharToDate("2/5/95","GD")    Date value is before 2/5/95
  114.  
  115.     * On page 11-15 of the User's Guide, the text correctly mentions the use
  116.       of square brackets ([]) to surround field names containing spaces but
  117.       the square brackets are shown as curly brackets ({}) instead.
  118.  
  119.     * On pages 12-15 and 12-16 of the User's Guide, the examples for
  120.       "repeating instructions while a condition is true" and "repeating
  121.       instructions until a condition becomes true" incorrectly omit the code
  122.       which increments the value.  In both examples, the second SetValue
  123.       statement should be:
  124.         rc = SetValue( 'Count', dbeGet( 'Count' ) + 1 ) )
  125.       or, a bit more properly using only DBExpert 2.x style function names:
  126.         rc = dbeSetValue( 'Count', dbeGet( 'Count' ) + 1 ) )
  127.  
  128.     * The following functions are not documented in Chapter 15 of the User's
  129.       Guide:
  130.  
  131.         dbeRunMacro
  132.           Runs a DBExpert macro and returns the value returned by the macro's
  133.           RETURN statement.  You can call this function in expressions to     
  134.           have macros calculate a value to use in an expression.  
  135.  
  136.           For example, if you have a macro called Format that capitalizes the
  137.           name passed as a parameter, then in a query, you could have a
  138.           calculated column defined as
  139.             NewName: dbeRunMacro( 'Format', name )
  140.           to get the value of the NewName column from the Format macro.
  141.  
  142.           Parameters:
  143.             macro name - the name of the macro to run
  144.             parameters - the parameter string to pass to the macro
  145.  
  146.             Note: If the macro requires multiple parameters, these must be
  147.             combined together into a single string that is passed in the
  148.             second parameter of the dbeRunMacro call.  The exact form of the
  149.             string will depend on the way in which the particular macro
  150.             separates (parses) the parameters.
  151.  
  152.           Returns:
  153.             The value returned by the macro if successful, otherwise 
  154.             '#ERROR n' where n is the error code.
  155.  
  156.           Example:
  157.             NewName = dbeRunMacro( 'FormatName', Name ) calls the FormatName
  158.             macro to format the value in the Name variable and returns the
  159.             formatted name into the NewName variable.
  160.  
  161.           C prototype:
  162.             const char* dbeRunMacro( const char* macroName,
  163.                                      const char* parameters )
  164.     
  165.         dbeTruncate -- 2.0.5 or later
  166.           Truncates a number at the specified number of digits past the
  167.           decimal point.  Similar to dbeRound, except no "rounding up" is
  168.           performed.
  169.  
  170.           Parameters:
  171.             number - the number to truncate
  172.             digits - the number of digits from the decimal point to round to
  173.                      (negative values round to the left of the decimal point)
  174.  
  175.           Returns:
  176.             Number truncated to digits
  177.  
  178.           Example:
  179.             dbeTruncate(123.456, 0) returns 123
  180.             dbeTruncate(123.999, 0) returns 123
  181.             dbeTruncate(-123.456, 0) returns -123
  182.             dbeTruncate(123.456, 2) returns 123.45
  183.             dbeTruncate(123.456, -2) returns 100
  184.  
  185.           C prototype:
  186.             char* dbeTruncate( char* numberString, long digitsPastDecimal )
  187.     
  188.         dbePack -- 2.0.5 or later
  189.           Packs (compresses) the physical table of a dBase-style table (by 
  190.           removing the space occupied by deleted records).  Has no effect
  191.           on tables that are not stored as dBase-style tables.
  192.  
  193.           Note that the table must not be in use by another copy of DBExpert
  194.           or by another application for the packing operation to be successful.
  195.  
  196.           Parameters:
  197.             name - name of the table to pack
  198.  
  199.           Returns:
  200.             0 if successful, otherwise, returns error code
  201.  
  202.           Example:
  203.             dbePack('MyTable') packs the table named MyTable 
  204.  
  205.           C prototype:
  206.             long dbePack( char* name )
  207.     
  208.     * Contrary to what is stated on page 15-30 of the User's Guide, the dbeMsg
  209.       function returns the following values:
  210.  
  211.         dbeMsg 
  212.           Displays a message box with the specified test, title, and style.
  213.  
  214.           Returns:
  215.             The id of the button the user pressed to dismiss the message box
  216.               1 - OK
  217.               2 - Cancel
  218.               3 - Abort
  219.               4 - Retry
  220.               5 - Ignore
  221.               6 - Yes
  222.               7 - No
  223.               8 - Help
  224.               9 - Enter
  225.              -1 - ERROR
  226.  
  227.     * On page 18-3 of the User's Guide, it discusses the need for binding
  228.       DBExpert to any DB2 database you wish to use.  One way to do this is
  229.       with the SQLBIND command shown in the Guide.  Alternatively, you can use
  230.       the Client Setup (on DB2 Version 2) or Client Configuration Assistant
  231.       (on DB2 Universal Server) to bind DBEDB2.BND to the database(s) of your
  232.       choice.  
  233.  
  234.       No matter how you bind DBExpert to your DB2 database, you may also
  235.       need to specify that the ISO date format be used for date information
  236.       being passed to and from DBExpert.  This is required if the database 
  237.       is configured to use a localized date format (rather than the default).
  238.       See the Limitations section below for more information.
  239.  
  240.     * It is strongly recommended that you not use SQL keywords as table or
  241.       field names.  While these may be acceptable in some cases, they may not
  242.       be acceptable in others.  This is particularly a problem if you intend
  243.       to move your tables from one database product to another.
  244.  
  245.       The full list of SQL keywords, including those used only in specific SQL
  246.       dialects, is very long.  One such list will be found in the SQLWORDS.TXT
  247.       file included with this version of DBExpert.
  248.  
  249.       Some of the more common words included in the list are:
  250.  
  251.       AND, ANY, BETWEEN, BY, CATALOG, CHECK, COMMENT, COUNT, DAY, DATE,
  252.       DISTINCT, GRANT, GROUP, HOUR, HOURS, IN, INDEX, KEY, LABEL, LIKE, MAX,
  253.       MIN, MINUTE, MINUTES, MONTH, MONTHS, NAMES, NOT, NULL, OR, ORDER, PAGE,
  254.       PAGES, PART, SECOND, SECONDS, SELECT, SIZE, SUM, TABLE, TIME, UPDATE,
  255.       VALUE, YEAR, YEARS, ZONE.
  256.  
  257.     * DBExpert's performance when using dBase-style tables can be greatly
  258.       impacted by the amount of memory devoted to database caching in the
  259.       ODBC drivers.  By default, this amount is only 256K bytes.  Unless your 
  260.       system is both memory and swap space constrained (or you are only using
  261.       very tiny tables), we recommend you increase this amount.
  262.  
  263.       To change the setting of the database cache size, you must run the
  264.       ODBCADM utility from an OS/2 command line (after switching to the 
  265.       directory where you have DBExpert installed).
  266.  
  267.       In the ODBCADM main window, select the entry entitled 
  268.  
  269.         "QEDBF[Q+E dBASEFile (*.dbf)]" 
  270.  
  271.       and press the Setup button.  In the field labeled Cache Size, enter a
  272.       number larger than the default value of 4.
  273.  
  274.       The number you enter is the number of 64K buffers the database will use.
  275.       Thus, you must have enough memory and/or swap space to accommodate this
  276.       number.  In most cases, the number 100 (i.e., about 6.4M bytes of cache)
  277.       is a good starting point.  However, if your system is somewhat memory
  278.       constrained (say a 12M to 16M system) this number is probably too high;
  279.       if you have lots of memory (say a 64M or larger system) you could easily
  280.       go higher.  There is, of course, a point of diminishing return.  In most
  281.       cases, this is approximately twice the size of the largest DBF file you
  282.       are using.
  283.  
  284.       (Do not confuse this setting with the similarly named FileOpenCache
  285.       setting.  For this version of DBExpert to work correctly, the 
  286.       FileOpenCache setting must be set to it's default value of blank 
  287.       or 0.)
  288.  
  289.       After you make the change, press the OK button in Setup window, and then
  290.       press the Close button in the ODBCADM main window to exit from ODBCADM.
  291.       The change will not take effect as long as DBExpert is running.  Also,
  292.       keep in mind that this change does not affect all DBExpert operations.
  293.       However, you should notice a significant difference in some operations
  294.       (such as moving to the last record of a large table) and/or in some of
  295.       your queries.
  296.  
  297.  
  298.     Changes Of Interest to All Users
  299.  
  300.     * Beginning with Version 2.0.8, a new option on the File menu in the main
  301.       DBExpert window allows you to "pack" DBExpert application (.DBE) files.
  302.       The Pack Application option works much the same way on files which contain
  303.       DBExpert applications as the Pack Physical Table option does on files
  304.       which contain dBase tables (.DBF files).
  305.  
  306.       As you design your DBExpert application and make changes to the various
  307.       forms, queries, macros, and reports you define, parts of the "old" 
  308.       definitions may remain in the application file.  These old definitions
  309.       take up space and make the .DBE file bigger than actually necessary.  
  310.       When the File->Pack Application option is used, these unnecessary 
  311.       definitions are removed and a new, smaller version of the .DBE file is 
  312.       created.  (A backup copy of your original .DBE file is also saved as
  313.       a .DBB file.)  Thus, if you have to make many changes to your application
  314.       over time, packing the application can make the .DBE file much, much,
  315.       smaller and faster to load as well.
  316.  
  317.       The File->Pack Application option can only be applied to applications
  318.       (.DBE files) that are not open, however.  Thus you cannot pack the
  319.       application you are currently using nor can you pack an application
  320.       that other users might have open on a network.
  321.  
  322.     * Beginning with Version 2.0.8, the dbeRequeryControl function has been
  323.       extended to support subform controls (in addition to the combo box and 
  324.       listbox controls previously supported).  Thus, you can now use
  325.       dbeRequeryControl to force a subform to redetermine what records should
  326.       be displayed in a subform.
  327.  
  328.     * Beginning with Version 2.0.8, limitations on WHERE clauses in the Filter
  329.       parameter of the dbeQueryAvg, dbeQueryCount, dbeQueryFirst, dbeQueryLast,
  330.       dbeQueryMax, dbeQueryMin, and dbeQuerySum functions have been removed.
  331.       The limitations sometimes required you to make the WHERE clause more
  332.       complex than apparently necessary.
  333.  
  334.       Importantly, however, the change also affects the way DBExpert handles
  335.       some queries involving Group By or other "total" functions (such as Count,
  336.       Sum, Average, Minimum, or Maximum) when conditions are applied to columns
  337.       of the query.
  338.  
  339.       Usually, the difference is unimportant but in rare circumstances it may
  340.       yield a different result than would have been produced by earlier versions
  341.       of DBExpert. In fact, such a query may be permanently changed if you load
  342.       it into the Query Designer and save it (even if you do not make changes
  343.       to it yourself).
  344.  
  345.       If you find that you are having trouble with any such queries, please
  346.       contact technical support for assistance and for information about 
  347.       configuring Version 2.0.8 to handle such (unmodified) queries as they
  348.       were handled in earlier versions.
  349.  
  350.     * Beginning with Version 2.0.7, the Enter key (and the keypad Enter key)
  351.       now perform actions on forms.   In general, these keys now move the
  352.       cursor from one field to another in the same way as the Tab key.  On
  353.       a pushbutton, however, these keys "press" the button (rather than move
  354.       to the next field).  Similarly, on a multi-line entry (MLE) text field, 
  355.       these keys do not move to the next field but end the current line of 
  356.       text instead (as they have in earlier versions).   In the case of a
  357.       combo box control, these keys do not move to the next field if the list
  358.       associated with the combo box is currently displayed.
  359.  
  360.     * Beginning with Version 2.0.7, rows of data from other applications can
  361.       be pasted from the OS/2 clipboard into the spreadsheet view of a table.
  362.       (Previous versions only allowed pasting of rows copied onto the 
  363.       clipboard from within DBExpert itself.)  Each row of data must appear
  364.       as one line with tabs between the fields (as specified by the OS/2
  365.       standard for clipboard text).  
  366.  
  367.     * Beginning with Version 2.0.6, rows of data copied from a spreadsheet
  368.       view to the clipboard are now placed on the clipboard in text format
  369.       (in addition to the internal format used by DBExpert) using one line
  370.       for each row with tabs between the fields (as specified by the OS/2
  371.       standard for clipboard text).  This allows you to more easily transfer
  372.       data from DBExpert to other applications.
  373.  
  374.     * Beginning with Version 2.0.6, the use of the dbeShowWarnings function
  375.       has been extended to also apply to the confirmation message that may
  376.       appear when a form is being closed.  If, for example, the form has
  377.       been moved or resized, and dbeShowWarnings(TRUE) has been called, the
  378.       message asking if the form should be saved will not be displayed -- the
  379.       save will be done automatically instead.
  380.  
  381.     * Beginning with Version 2.0.5, a problem was corrected in the way date
  382.       values were converted after being entered into a field of a table or 
  383.       form.  The correction makes the program conform to what is stated in
  384.       the User's Guide but has the side-effect of breaking an undocumented
  385.       feature of Version 2.0.4 and earlier.  In those earlier versions, it
  386.       was possible to enter a "formatted" date (such as "1997 January 1") and
  387.       have it properly interpreted by the program if the display format for
  388.       the field was set to a matching format (such as "YYYY Mmmm DD" in this
  389.       case).  Such functionality has never been officially supported since,
  390.       as the User's Guide shows on page 16-7, the general date format is 
  391.       always used while a value is being entered/edited.
  392.  
  393.       We do realize this capability is useful and may support it as an option
  394.       in the future.  In the mean time, if you need compatibility with this
  395.       behavior of earlier versions, please contact Sundial Systems Support
  396.       Services for information about making this version of DBExpert work in
  397.       "Version 2.0.4 Date Entry" compatibility mode.
  398.  
  399.     * Beginning with Version 2.0.5, a change has been made in the way in which
  400.       parameters are passed to DBExpert macros.  This change allows blanks
  401.       (spaces) to be preserved within parameters and/or blanks to be used to
  402.       delimit parameters (depending on how the macro itself interprets the
  403.       REXX parameter string).  
  404.  
  405.       Previously, all blanks were removed and all the parameters converted to
  406.       upper case to insure compatibility of macros designed for use with
  407.       DBExpert 1.x.  If you have any remaining DBExpert 1.x macros, you should
  408.       check to make sure they continue to work correctly -- or contact Sundial
  409.       Systems Support Services for information on making this version of
  410.       DBExpert work in "Version 1 Macro" compatibility mode.
  411.  
  412.     * Beginning with Version 2.0.5, a new dbeTruncate function has been added.
  413.       This function is like dbeRound (and takes the same parameters) but does
  414.       not perform any "rounding up" of the value.
  415.  
  416.     * Beginning with Version 2.0.5, a change has been made in the way in which
  417.       the dbeInt function treats negative numbers to make the behavior of the
  418.       function more consistent with the generally accepted definition of an
  419.       "integer portion of" function.  This means that negative numbers are now
  420.       "rounded down" rather than "truncated toward zero".  Thus, for example, 
  421.       dbeInt(-4.5) will now return -5 rather than -4 (as it would have done in
  422.       earlier versions).
  423.  
  424.       This change has no impact on the treatment of positive numbers.  However,
  425.       if you have macros or queries that rely on the older behavior which 
  426.       "truncates" negative numbers, you should use the new dbeTruncate function
  427.       in place of dbeInt.
  428.  
  429.     * Beginning with Version 2.0.5, additional options (Semicolon and Space) 
  430.       have been added to the Delimiter options which can be selected when
  431.       importing text files into DBExpert.
  432.  
  433.     * Beginning with Version 2.0.4, a change has been made in the way in which
  434.       dates in the year 2000 and beyond are displayed.  While DBExpert has
  435.       always handled such dates, the "general" date formats (GD and GDT) have
  436.       displayed only the last two digits of the year.  This has been changed
  437.       so that all four digits will be displayed if the year is not between
  438.       1900 and 1999.  If you still wish to display only a two digit year, you
  439.       must use a format string containing 'yy' as discussed in Chapter 16 of
  440.       the User's Guide.
  441.  
  442.     * Similarly, beginning with Version 2.0.4, a change has been made in the
  443.       way in which times containing fractional seconds are displayed.  The
  444.       "general" time formats (GT and GDT) will now display these values
  445.       whenever they are found.  If you wish to always display times only in
  446.       whole seconds, you must use a format string containing 'ss' as discussed
  447.       in Chapter 16 of the User's Guide.
  448.  
  449.       Also, please note that the level of support for fractional seconds
  450.       depends on the type of field and the type of database being used.  In
  451.       particular, dBase-style tables support fractional seconds only in
  452.       timestamp fields (not time fields) while other database types support
  453.       fractional seconds in both time and timestamp fields.
  454.  
  455.     * Beginning with Version 2.0.4, a change has been made in the way in which
  456.       DBExpert recognizes the international configuration settings on your
  457.       system.  Previously, DBExpert determined this information solely based
  458.       on the COUNTRY setting in your CONFIG.SYS file.  Beginning with 2.0.4,
  459.       DBExpert will now override this information based on any changes you
  460.       have made using the Country object in the OS/2 System Setup folder as
  461.       well.  (Changes you make, however, will not take effect while DBExpert
  462.       is running.)
  463.  
  464.       While there are still some limitations to DBExpert's international
  465.       formatting support, this and other changes that have been made 
  466.       (including corrections included in Version 2.0.5) should improve the
  467.       situation significantly (when compared to earlier DBExpert versions).  
  468.  
  469.       The primary remaining restriction concerns the use of numbers containing
  470.       "decimal commas" (as opposed to "decimal points" -- 2,9 vs 2.9 for
  471.       example) in SQL statements and related situations.  These include
  472.       numbers typed directly into SQL statements in the SQL Viewer window of
  473.       the query designer, conditions entered in the Field lists of the query
  474.       designer, and WHERE clauses which are parameters to certain DBExpert
  475.       functions such as dbeQueryCount.  In all such cases you must use the 
  476.       "decimal point" representation of the number rather than any
  477.       internationally localized representation which includes a "decimal
  478.       comma."  (The comma confuses the SQL interpreter in these situations.)
  479.  
  480.       If you encounter other situations where your country settings cause
  481.       problems in DBExpert (or, are not properly reflected in DBExpert), 
  482.       please report them to Sundial Systems Support Services so that they
  483.       may be addressed in a future version.
  484.  
  485.     * Beginning with Version 2.0.2, a change has been made in the way in
  486.       which text import is handled.  This results in substantially increased
  487.       performance when importing (by as much as a factor of 50).
  488.  
  489.  
  490.     Changes Of Interest to dBase-style Table Users
  491.  
  492.     * Be sure to consult the information elsewhere in this document about
  493.       changes beginning in Version 2.0.5 to the way in which table designs
  494.       are saved when using the Table Designer.
  495.  
  496.     * DBExpert follows the standard conventions for deleting records from
  497.       dBase tables.  This means that the space occupied by these records in 
  498.       the actual DBF file is not recovered -- instead, the file will continue
  499.       to grow as more records are added to the table.  In general, this growth
  500.       will also occur when using DBExpert to simply update the data in the
  501.       table as well.  The growth not only consumes disk space but also affects
  502.       the performance of queries against the table, etc.
  503.  
  504.       Beginning with Version 2.0.5, DBExpert provides a facility which can be 
  505.       used to reclaim the wasted space by "packing" the table.  To do this,
  506.       highlight the table on the Tables page of the DBExpert main window, then
  507.       select File->Pack Table.  Note that the table must not be in use (by
  508.       DBExpert or any other application) for the packing operation to be
  509.       completed successfully.
  510.  
  511.       For people that wish to pack tables on a more automated basis (or within
  512.       applications being used with the DBExpert Runtime), a dbePack function
  513.       is also now provided (as explained elsewhere).
  514.  
  515.       Finally, if you intend to pack tables that are used by applications 
  516.       other than DBExpert, it is recommended that you verify that the packing
  517.       will not adversely affect the other application.  (Make sure you have
  518.       a backup copy of the table and all indices before you attempt the
  519.       packing operation the first time -- contact Sundial Systems Support
  520.       Services if you have questions.)
  521.  
  522.     * Beginning with Version 2.0.1, a change has been made in what happens
  523.       when attaching dBase-style tables.  The current directory now is set to
  524.       the directory that the table is in so you can attach more than one table
  525.       from the same directory without selecting the directory each time.
  526.  
  527.  
  528.     Of Interest to DBExpert Users Upgrading from Version 1
  529.  
  530.     * When you open forms created with Version 1.x, the menu, VCR buttons, and
  531.       tool bar will not be displayed.  To enable them, switch to design view
  532.       and set the Menu, VCR Buttons, and Tool Bar attributes to Yes and save
  533.       the form.
  534.  
  535.     * If you have trouble using macros which you created in DBExpert Version 1,
  536.       contact Sundial Systems Support Services for assistance.
  537.  
  538.  
  539.     Limitations Of Interest to All Users
  540.  
  541.     * If you choose to use the Default Value attribute for a field in a table
  542.       or on a form, the value you enter must be an actual value -- use of an 
  543.       expression or macro call is not allowed.  This restriction may be eased 
  544.       in a future version.
  545.  
  546.     * While horizontal scrollbars can be included on a DBExpert form, they can
  547.       not actually be used to scroll the form.  (Vertical scrollbars, however,
  548.       do work.)  We plan to address this problem in a future version.
  549.  
  550.     * When using the vertical scroll bar on a spreadsheet (table) view or a 
  551.       form, the scroll bar "thumb" may temporarily "paint" part of itself above
  552.       the top (or below the bottom) of the scroll bar in some circumstances. 
  553.       The problem is strictly cosmetic in nature and does not affect the 
  554.       operation of the program or the scrollbar.  However, we are aware that
  555.       it can be disturbing and hope to correct the problem in a future version.
  556.  
  557.     * In general, if you run multiple copies of DBExpert, you may not be able
  558.       to access your data (or run macros) from the second and subsequent
  559.       copies once you close the first copy.  (On the other hand, there is not
  560.       a problem if you close any copy other than the first copy.)  The only
  561.       workaround is to close and reopen all running copies of DBExpert.  We
  562.       hope to address this limitation in a future update.
  563.  
  564.     * Contrary to the statement on page 6-7 of the User's Guide, the CTRL key
  565.       cannot be used in connection with the left mouse button to select 
  566.       multiple rows in the spreadsheet view of a table (or query).  This may 
  567.       be addressed in a future version.
  568.  
  569.     * There is a limitation on the use of dbeLoadPicture (also known as
  570.       LoadPicture) when used to load an image onto a form from a disk file (as
  571.       outlined on page 10-44 of the User's Guide).  The picture will only be
  572.       loaded if there is a source query or table associated with the form
  573.       (even though the picture is not coming from the database).  This
  574.       situation typically arises on forms being used as the initial form for 
  575.       an application.  As a workaround, for pictures on forms without a source
  576.       table/query, place the dbeLoadPicture call (inside a dbeSetValue call)
  577.       in the On Current event for the form as a whole.  For example:
  578.  
  579.         =dbeSetValue('picturefield',dbeLoadPicture('logo.bmp')).
  580.  
  581.     * Contrary to the discussion on page 11-10 of the User's Guide, DBExpert
  582.       2.0.x does not support the use of List Box or Combo Box controls on
  583.       reports.  This will be addressed by a future update.
  584.  
  585.     * Contrary to the statement and examples on page 16-4 of the User's Guide,
  586.       DBExpert does not currently support the use of "e+" or "e-" to format
  587.       numbers in scientific notation.   This will be addressed by a future 
  588.       update.
  589.      
  590.     * In general, setting the background color for elements of a report does
  591.       not produce the desired result -- the elements will have a white
  592.       background regardless of the color settings in the report definition.
  593.       (Foreground color settings, such as the text color, do work correctly,
  594.       however.)  We hope to address this issue in a future version.
  595.  
  596.     * When printing some reports that have multiple data groupings, an extra
  597.       page without any actual data (only headers and/or footers) may appear at
  598.       the beginning or end of the report (depending on the page break options
  599.       selected).  There currently is no workaround for this problem but we hope
  600.       to address it in a future version.
  601.  
  602.     * When printing some reports (typically those with controls which can grow
  603.       to contain more data), it may not be possible to print selected pages
  604.       unless the selection begins with page 1.  For instance, if you request
  605.       that only pages 3 through 5 be printed, some or all of what would have
  606.       appeared on page 1 appears on page 3 instead.  There is currently no
  607.       workaround for this problem but we hope to address it in a future version.
  608.  
  609.     * Using subreports (or sometimes controls which can grow) in report headers
  610.       or footers sometimes causes blank pages between printed pages or, in the
  611.       worst case, a report which prints blank pages forever.  Making the header
  612.       or footer taller usually makes the problem go away.  We hope to address
  613.       this in a future version.
  614.  
  615.     * If you try to create a report on an OS/2 system which has no default 
  616.       print queue, a misleading error will be displayed and you will not be
  617.       able to create the report.  There is no workaround but we plan to 
  618.       address this problem in a future update.
  619.  
  620.     * Some update queries which involve a join and attempt to update a field
  621.       to a computed value not specifically involved in the join, fail for no
  622.       apparent reason.  There is no workaround and we are continuing to 
  623.       identify the exact source of the problem.  If you have such a query,
  624.       please send the details to Sundial Systems Support Services.
  625.  
  626.     * On occasion, cut, copy, and/or paste operations in DBExpert may stop
  627.       working.  The only solution is to close and reopen DBExpert.  We are
  628.       continuing to try to identify the source of this problem and hope to
  629.       have it corrected in a future version.
  630.  
  631.     * While an application created with DBExpert can be copied (or moved) from
  632.       one system to another, in general, it must be placed on the same disk 
  633.       drive and in the same directory on the target system as it was in on the
  634.       original system.  (This also means that it is impractical to move a 
  635.       DBExpert application from one disk to another on the same system.) This
  636.       limitation will be addressed in a future version.
  637.  
  638.       If, however, you do copy or move a DBExpert application to a different
  639.       drive or directory, you can generally get the application working once
  640.       again by using the File -> Change Physical Table option to change the
  641.       location (i.e., drive and directory) of each dBase-style table which
  642.       moved along with the application.
  643.  
  644.     * When an application created with DBExpert is copied (or moved) from one 
  645.       system to another, any reports in the application expect to be able
  646.       to find the same OS/2 printer (by name) as they were originally defined
  647.       for.  
  648.  
  649.       If no such printer is found, then the report will become associated with
  650.       the default printer on that system and any printer-dependent attributes
  651.       of the report (such as landscape-vs-portrait printing) will be reset to
  652.       the default values for the new printer.
  653.  
  654.       If the same printer is found, then print job characteristics which were
  655.       saved with the report will be passed to the printer on the new system.
  656.       Usually this is not a problem.  However some OS/2 printer drivers do not
  657.       cope well if the information saved by one version of the driver is 
  658.       passed to another version of the same driver.
  659.  
  660.       The only work around is to change the printer associated with the report
  661.       to some other printer, change it back to the desired printer, and then
  662.       the printer-dependent aspects of the report.
  663.  
  664.     * If you move DBExpert from one directory (or disk) to another, you most
  665.       likely will not be able to access your existing DBExpert data (unless
  666.       you are using only DB2 tables).  To solve the problem, you need to
  667.       perform the following steps but ONLY if you are not using ODBC drivers
  668.       in connection with other products (in which case you should contact
  669.       Sundial Systems Support Services for assistance).
  670.  
  671.       In your OS/2 directory, you should find two files named ODBC.INI and
  672.       ODBCINST.INI.  (If you cannot find the files, contact technical support.)
  673.       
  674.       Rename the two files (or move them to a safe place in case you need 
  675.       them later).
  676.  
  677.       Reinstall DBExpert over the copy you have in the new directory.  This 
  678.       will not affect any of your existing DBExpert applications or files
  679.       (with the exception that any changes you have made to the Sample 
  680.       application will be undone).
  681.  
  682.       Verify that new copies of the ODBC.INI and ODBCINST.INI files have 
  683.       appeared in your OS/2 directory and that you can now access your 
  684.       existing DBExpert data.  (If not, contact Support Services.)
  685.  
  686.  
  687.     Limitations Of Interest to Users of dBase-style Tables
  688.  
  689.     * DBExpert cannot be used to access dBase tables which are stored in files
  690.       where the base part of the filename is longer than 8 characters.  The
  691.       only workaround is to rename the file to a conventional "8.3" format
  692.       name (using .DBF for the extension).  This is likely to be a permanent
  693.       restriction.
  694.  
  695.     * DBExpert cannot be used to access dBase tables which are stored in a
  696.       directory where the name of the directory, or any parent directory,
  697.       contains a space in the name.  The only workaround is to move the
  698.       file(s) containing the table to a different directory.  We hope to
  699.       address this limitation in a future update.
  700.  
  701.     * As noted above, dBase tables do not support fractional seconds in time
  702.       fields (though they are supported in timestamp fields).  If you enter
  703.       fractional seconds in a dBase time field, they may appear on the screen
  704.       to have been accepted as part of the value.  However, they will not be 
  705.       stored in the database and will be discarded when you close (or    
  706.       refresh) the table or form.
  707.  
  708.     * For the version of DBEQ.DLL included in this version to work correctly,
  709.       the DBEXPERT directory MUST appear in the LIBPATH statement in your
  710.       CONFIG.SYS file.  Ordinarily, this addition should have been made by the
  711.       DBExpert installation program.  However, some earlier versions of the
  712.       installation program did not make the change.  Thus, after installing
  713.       this version, we recommend that you check your CONFIG.SYS file if you
  714.       find you cannot attach or access dBase tables in other directories.
  715.  
  716.  
  717.     Limitations Of Interest to DB2 Users
  718.  
  719.     The following known issues may arise when using this version of DBExpert
  720.     (or any earlier 2.0.x version) with any version of DB2:
  721.  
  722.     * If DB2 is not properly installed and operational, DBExpert will trap
  723.       if you try to access a DB2 database or table.
  724.  
  725.     * In general, it is strongly recommended that you be logged on with your
  726.       DB2 User ID before trying to access DB2 through DBExpert.  Failing to do
  727.       so may cause DBExpert and the UPM logon to jointly hang the system.  We
  728.       are continuing to try to determine the cause of this problem.
  729.  
  730.     * When creating expressions which involve string constants (such as ='NY'
  731.       or LIKE('SM%') ), be sure to use single (not double) quote marks.  This
  732.       is due to the fact that DB2 does not recognize string constants that
  733.       are surrounded by double quotes.  We hope to be able to handle this
  734.       conversion automatically in some future version.
  735.  
  736.     * The current method DBExpert uses to import data from a non-DB2 source
  737.       into a DB2 table, or to change the structure of an existing DB2 table,
  738.       can result in very large transactions when the volume of data being
  739.       imported or converted is large.  This may result in a transaction that
  740.       is larger than DB2 can fit in its uncommitted transaction logs.  In
  741.       general, the total size of the data being converted, together with
  742.       index information on that data, must be able to fit in the transaction
  743.       log.  You can reduce the required space by importing/converting to
  744.       tables which do not have indices defined on them (and then add the
  745.       indices later).  You may also find it necessary to increase the log file
  746.       space used by DB2 for uncommitted transactions.
  747.  
  748.       To do this on DB2 Universal Server using the DB2 Control Center, select
  749.       the database you are using and then use the Configure option on the
  750.       Selected menu (or the Configure option on the popup menu for the
  751.       database) to reach the settings notebook.  On the Logs page, select the
  752.       Log File Size entry (if is not already selected) and adjust the value of
  753.       Log File Size to a higher value than the default.  Alternatively, you can
  754.       also do this by using the DB2 Command Line Processor and the UPDATE
  755.       DATABASE CONFIGURATION command to set the LOGFILESIZ parameter for the
  756.       database.
  757.  
  758.       To do this on DB2 Version 2 using the DB2 Database Director, select the
  759.       database you are using and then use the Selected option on the Configure
  760.       menu to reach the settings notebook.  On the Log Files page, set the
  761.       value of Log File Size to a higher value than the default.
  762.       Alternatively, you can also do this by using the DB2 Command Line
  763.       Processor and the UPDATE DATABASE CONFIGURATION command to set the
  764.       LOGFILESIZE parameter for the database.
  765.  
  766.       To do this on DB2 Version 1 using the DB2 CONFIG program, select the
  767.       database you are using, and then, using the Change Database option on
  768.       the Configure menu, change the LogFileSize parameter to a larger number.
  769.  
  770.     The following known issues may arise when using this version of DBExpert
  771.     (or any earlier 2.0.x version) with DB2 Version 2 or DB2 Universal Server:
  772.  
  773.     * The current method used by DBExpert for locking records in DB2 causes
  774.       the lock to be held for the entire time a user is editing a row within
  775.       the spreadsheet view of a table (or the fields of a row on a form).
  776.       This will cause other users to be locked out of access to that row (and
  777.       possibly adjacent rows) for unacceptably long periods of time unless you
  778.       configure DB2 Version 2 or DB2 Universal Server to enable lock timeouts.
  779.  
  780.       To do this on DB2 Universal Server using the DB2 Control Center, select
  781.       the database you are using and then use the Configure option on the
  782.       Selected menu (or the Configure option on the popup menu for the
  783.       database) to reach the settings notebook.  On the Applications page,
  784.       select the Lock Timeout entry (scrolling the entry into view if
  785.       necessary).  Uncheck the None option if it is checked and and set the the
  786.       Lock Timeout value to a small number (such as 2; the value is in
  787.       seconds).  Alternatively, you can also do this by using the DB2 Command
  788.       Line Processor and the UPDATE DATABASE CONFIGURATION command to set the
  789.       LOCKTIMEOUT parameter for the database.
  790.  
  791.       To do this on DB2 Version 2 using the DB2 Database Director, select the
  792.       database of interest and use the Selected option on the Configure menu to
  793.       reach the settings notebook.  On the Locks page, select the Time option
  794.       and set the timeout value to a small number (such as 2; the value is in
  795.       seconds).  Alternatively, you can also do this by using the DB2 Command
  796.       Line Processor and the UPDATE DATABASE CONFIGURATION command to set the
  797.       LOCKTIMEOUT parameter for the database.
  798.  
  799.     * There is a known issue with mixed case column and table names that can be
  800.       created in DB2.  Currently, these cannot be properly accessed with
  801.       DBExpert.  There is no workaround but we plan to address the issue in a
  802.       future update.
  803.  
  804.     * There is a known issue with column and table names created in DB2 that
  805.       contain non-English alphabetic characters.  Currently, these cannot be
  806.       properly accessed with DBExpert.  There is no workaround but we plan to
  807.       address the issue in a future update.
  808.  
  809.     * There is a known problem with displaying DB2 date fields in DBExpert
  810.       when localized DB2 date formats are being used.  If the default date
  811.       format for a database is set to one of these formats, you must bind
  812.       DBExpert to the database using ISO date format.  To do this, use the
  813.       following alternate form of the BIND command (rather than that shown on
  814.       page 18-3 of the User's Guide):
  815.  
  816.         SQLBIND DBEDB2.BND database_name DATETIME ISO
  817.  
  818.       Alternatively, you may also use the DB2 Command Line Processor (on any
  819.       DB2 version) or Client Setup (on DB2 Version 2) or Client Configuration
  820.       Assistant (on DB2 Universal Server) to bind DBEDB2.BND using the ISO date
  821.       and time format.
  822.  
  823.     * There is a known issue which sometimes affects the ability of DBExpert
  824.       to access DB2 properly.  If you have performed the SQL bind statement as
  825.       outlined on page 18-3 of the User's Guide, and have granted the
  826.       necessary privileges as outlined on pages 18-3 and 18-4, but get an
  827.       error about "package CHRIS.DBEDB2 not being found" when trying to access
  828.       your data, try using an alternative form of the GRANT statement to
  829.       correct the problem.  In this form, the statement is the same as that
  830.       shown, for your version of DB2, on page 18-4 of the User's Guide except
  831.       that "CHRIS.DBEDB2" is substituted for "DBEDB2".  For instance, in the
  832.       case of DB2/2, rather than
  833.  
  834.         GRANT EXECUTE, BIND ON PROGRAM DBEDB2 TO PUBLIC
  835.  
  836.       use
  837.  
  838.         GRANT EXECUTE, BIND ON PROGRAM CHRIS.DBEDB2 TO PUBLIC
  839.  
  840.     * If you install DB2 on your workstation after installing DBExpert, you 
  841.       may not be able to run DBExpert or access your data.  This is due to a 
  842.       confusion which arises between the DB2 ODBC drivers and the DBExpert 
  843.       ODBC drivers (even though neither is used by DBExpert to access DB2).
  844.       To correct the problem, you must edit your CONFIG.SYS file and modify 
  845.       the LIBPATH statement so that the DBEXPERT directory (the directory 
  846.       where you have DBEXPERT installed) comes before the SQLLIB\DLL 
  847.       directory.
  848.  
  849.  
  850.     The Legal Fine Print
  851.  
  852.     The terms and conditions of your DBExpert License apply to the software
  853.     and documentation accompanying this file.
  854.  
  855.     DBExpert is a trademark of Designer Software, Inc., and is used by Sundial
  856.     Systems Corporation under license.
  857.  
  858.     Other phrases used herein may be brand names, trademarks, or registered
  859.     trademarks of Apple Computer, Inc., Borland International, Inc., Computer
  860.     Associates International, Inc., Designer Software, Inc., International
  861.     Business Machines Corporation, Intersolv Corporation, Microsoft   
  862.     Corporation, Novell, Inc., Oracle Corporation, Sundial Systems
  863.     Corporation, or others.  All such names and trademarks remain the 
  864.     property of their respective companies.
  865.  
  866.  
  867.     Technical Support
  868.  
  869.     We at Sundial Systems are committed to supporting you, our customer.
  870.  
  871.     We track all questions, comments, and "bug reports" concerning our
  872.     products and use this information in planning future releases.  If
  873.     there are features you particularly like or things you think should
  874.     be added to our products, please let us know.
  875.  
  876.     If you have questions or suggestions, the most effective way to contact
  877.     us is by email to dbexpert@sundialsystems.com or dbexpert@ibm.net.
  878.  
  879.     You can also visit us on the web at www.sundialsystems.com where you 
  880.     will find information about DBExpert as well as other members of the 
  881.     Sundial Systems family of OS/2 products.  That's also the best place to 
  882.     find out about updates and other enhancements as they become available.
  883.  
  884.     You can also call us at (562) 596-5121 between 9:00 AM and 4:30 PM 
  885.     Pacific time, Monday through Friday.  We can't guarantee the immediate
  886.     availability of support personnel at all times, but all calls are handled
  887.     as quickly as possible.  You can also FAX your questions and comments to
  888.     us at (562) 596-7825 at any time.
  889.  
  890.     Thanks in advance,
  891.     Sundial Systems Support Services.
  892.