I've not done this since the days of Access 97, but while it was
straightforward enough to import the data into Access tables I did run across
a few things connected with dBASE memo fields which needed further attention:
1. The data in the Access memo fields appeared to be truncated. The data
was there however but to see it all in a form or report it was necessary to
add a text box to the form or report first and then set its ControlSource
property to the name of the memo field. All data then showed, whereas if the
control was added by dragging from the 'field list' or f the form or report
was created by a wizard, the apparent truncation which occurred in datasheet
view of the table was also apparent in the form or report.
2. If carriage returns/line feeds had been included in the dBASE memo
fields these appeared as a high ASCII character in Access (I don't recall
which, but its easy to find out by copying the character and then pasting it
as the argument of the ASC function in the debug window), so it was necessary
to use an update query to substitute a carriage return/line feed for each
instance of the high ASCII character. At the time I wrote my own function,
but the built-in Replace function can now be used.
As well as the points made by John you'll need to rethink how indexes are
used. In dBASE an index is used to govern the order of output of data. In
Access this is done by sorting a query. Indexes in Access are used to
improve performance and/or to restrict a column to unique values. Its
particularly important that the key columns on which tables are joined are
indexed, the primary key of the referenced table uniquely, the corresponding
foreign key in the referencing table non-uniquely.
Another significant difference is that in Access there is no concept of a
'record number' as in dBASE. Access tables are sets, and as such have no
intrinsic order. A row in a table is addressed by a value or values in a
column or columns, not by its position.
Ken Sheridan
Stafford, England
