-
If you are using Access 2000, you should get and install the
newest (version 2.6 or higher) Microsoft MDAC
(Microsoft Data Access Components
) from
https://www.microsoft.com/data/. This fixes a
bug in Access that when you export data to MySQL, the table
and column names aren't specified. Another way to work
around this bug is to upgrade to MyODBC 2.50.33 and MySQL
3.23.x, which together provide a workaround for the problem.
You should also get and apply the Microsoft Jet 4.0 Service
Pack 5 (SP5) which can be found at
https://support.microsoft.com/default.aspx?scid=kb;EN-US;q239114.
This fixes some cases where columns are marked as
#DELETED#
in Access.
Note: If you are using MySQL 3.22, you must apply the MDAC
patch and use MyODBC 2.50.32 or 2.50.34 and up to work
around this problem.
For all versions of Access, you should enable the MyODBC
Return matching rows
option. For Access
2.0, you should additionally enable the Simulate
ODBC 1.0
option.
You should have a timestamp in all tables that you want to
be able to update. For maximum portability, don't use a
length specification in the column declaration. That is, use
TIMESTAMP
, not
TIMESTAMP(N
)
,
N
< 14.
You should have a primary key in the table. If not, new or
updated rows may show up as #DELETED#
.
Use only DOUBLE
float fields. Access
fails when comparing with single floats. The symptom usually
is that new or updated rows may show up as
#DELETED#
or that you can't find or
update rows.
-
If you are using MyODBC to link to a table that has a
BIGINT
column, the results are displayed
as #DELETED
. The work around solution is:
Have one more dummy column with
TIMESTAMP
as the data type.
Select the Change BIGINT columns to
INT
option in the connection dialog in ODBC
DSN Administrator.
Delete the table link from Access and re-create it.
Old records still display as #DELETED#
,
but newly added/updated records are displayed properly.