The majority of Microsoft applications have been tested with Connector/ODBC, including Microsoft Office, Microsoft Access and the various programming languages supported within ASP and Microsoft Visual Studio.
To improve the integration between Microsoft Access and MySQL through Connector/ODBC:
For all versions of Access, enable the Connector/ODBC
Return matching rows
option. For Access 2.0, also enable theSimulate ODBC 1.0
option.Include a
TIMESTAMP
column in all tables that you want to be able to update. For maximum portability, do not use a length specification in the column declaration (which is unsupported within MySQL in versions earlier than 4.1).Include a primary key in each MySQL table you want to use with Access. If not, new or updated rows may show up as
#DELETED#
.Use only
DOUBLE
float fields. Access fails when comparing with single-precision floats. The symptom usually is that new or updated rows may show up as#DELETED#
or that you cannot find or update rows.If you are using Connector/ODBC 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 may still display as
#DELETED#
, but newly added/updated records are displayed properly.If you still get the error
Another user has changed your data
after adding aTIMESTAMP
column, the following trick may help you:Do not use a
table
data sheet view. Instead, create a form with the fields you want, and use thatform
data sheet view. Set theDefaultValue
property for theTIMESTAMP
column toNOW()
. Consider hiding theTIMESTAMP
column from view so your users are not confused.In some cases, Access may generate SQL statements that MySQL cannot understand. You can fix this by selecting
"Query|SQLSpecific|Pass-Through"
from the Access menu.On Windows NT, Access reports
BLOB
columns asOLE OBJECTS
. If you want to haveMEMO
columns instead, changeBLOB
columns toTEXT
withALTER TABLE
.Access cannot always handle the MySQL
DATE
column properly. If you have a problem with these, change the columns toDATETIME
.If you have in Access a column defined as
BYTE
, Access tries to export this asTINYINT
instead ofTINYINT UNSIGNED
. This gives you problems if you have values larger than 127 in the column.If you have very large (long) tables in Access, it might take a very long time to open them. Or you might run low on virtual memory and eventually get an
ODBC Query Failed
error and the table cannot open. To deal with this, select the following options:Return Matching Rows (2)
Allow BIG Results (8).
These add up to a value of 10 (
OPTION=10
).
Some external articles and tips that may be useful when using Access, ODBC and Connector/ODBC:
If you have problems importing data into Microsoft Excel, particularly numeric, date, and time values, this is probably because of a bug in Excel, where the column type of the source data is used to determine the data type when that data is inserted into a cell within the worksheet. The result is that Excel incorrectly identifies the content and this affects both the display format and the data when it is used within calculations.
To address this issue, use the
CONCAT()
function in your
queries. The use of CONCAT()
forces Excel to treat the value as a string, which Excel
will then parse and usually correctly identify the embedded
information.
However, even with this option, some data may be incorrectly
formatted, even though the source data remains unchanged.
Use the Format Cells
option within Excel
to change the format of the displayed information.
To be able to update a table, you must define a primary key for the table.
Visual Basic with ADO cannot handle big integers. This means
that some queries like SHOW
PROCESSLIST
do not work properly. The fix is to
use OPTION=16384
in the ODBC connect
string or to select the Change BIGINT columns to
INT
option in the Connector/ODBC connect screen. You may
also want to select the Return matching
rows
option.
If you have a BIGINT
in your
result, you may get the error [Microsoft][ODBC
Driver Manager] Driver does not support this
parameter
. Try selecting the Change
BIGINT columns to INT
option in the Connector/ODBC
connect screen.
When you are coding with the ADO API and Connector/ODBC, you need
to pay attention to some default properties that aren't
supported by the MySQL server. For example, using the
CursorLocation Property
as
adUseServer
returns a result of −1
for the RecordCount Property
. To have the
right value, you need to set this property to
adUseClient
, as shown in the VB code
here:
Dim myconn As New ADODB.Connection
Dim myrs As New Recordset
Dim mySQL As String
Dim myrows As Long
myconn.Open "DSN=MyODBCsample"
mySQL = "SELECT * from user"
myrs.Source = mySQL
Set myrs.ActiveConnection = myconn
myrs.CursorLocation = adUseClient
myrs.Open
myrows = myrs.RecordCount
myrs.Close
myconn.Close
Another workaround is to use a SELECT
COUNT(*)
statement for a similar query to get the
correct row count.
To find the number of rows affected by a specific SQL
statement in ADO, use the RecordsAffected
property in the ADO execute method. For more information on
the usage of execute method, refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdmthcnnexecute.asp.
For information, see ActiveX Data Objects(ADO) Frequently Asked Questions.
Select the Return matching rows
option in
the DSN.
For more information about how to access MySQL through ASP using Connector/ODBC, refer to the following articles:
A Frequently Asked Questions list for ASP can be found at http://support.microsoft.com/default.aspx?scid=/Support/ActiveServer/faq/data/adofaq.asp.
Some articles that may help with Visual Basic and ASP:
MySQL BLOB columns and Visual Basic 6 by Mike Hillyer (
<mike@openwin.org>
).How to map Visual basic data type to MySQL types by Mike Hillyer (
<mike@openwin.org>
).