By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,679 Members | 2,069 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,679 IT Pros & Developers. It's quick & easy.

Access and MYSQL

P: n/a
Hi there

I am an Access developer, and I have written applications for a 30
telephone call center, using the standard multiuser jet engine, it all
works fine, but I want to move our systems onto MySQL, as we get the
odd #DELETED# (that old chestnut) so that it is more stable, I have
installed mysql and myodbc and configured it in data sources (ODBC) and
it works fine (done the TEST).
But when I try to export a table from the mdb

I get the following prompt
"[MySQL][ODBC 3.51 Driver] Could not determine the driver name"
In advanced part of the ODBC config it says
DRIVER={MySQL ODBC 3.51 Driver} (I don't know if this is a description
or a path)

I am using a dev serv, not sure if I need to configure it or if it is
as simple as to change the driver name to the DLL or if is is
descriptive

I'm confused

May 31 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a

"Vanessa" <va**********@yahoo.com> wrote in message
news:11*********************@c74g2000cwc.googlegro ups.com...
Hi there

I am an Access developer, and I have written applications for a 30
telephone call center, using the standard multiuser jet engine, it all
works fine, but I want to move our systems onto MySQL, as we get the
odd #DELETED# (that old chestnut) so that it is more stable, ...
You shouldn't be seeing #DELETED# errors.
It makes me concerned that you may have deeper problems that won't be solved
by merely porting to MySQL.

You may want to explain this a bit more.

Hopefully, you are using Access version 2000 or higher. Access 97 at this
point is positively prehistoric. With prehistoricly oversized bugs, it is
beyond redemption.
I have
installed mysql and myodbc and configured it in data sources (ODBC) and
it works fine (done the TEST).
That's good and useful, but it does little more than prove you can
communicate with the MySQL server. A good starting point, however.
But when I try to export a table from the mdb
I get the following prompt
"[MySQL][ODBC 3.51 Driver] Could not determine the driver name"
In advanced part of the ODBC config it says
DRIVER={MySQL ODBC 3.51 Driver} (I don't know if this is a description
or a path)
It sounds like you are trying to use the Access table export utility to port
your Access tables to MySQL. I'm sure you can muddle through that but I
don't recommend it.

If you have Access expertise but are MySQL green, then I would suggest -

1) That you construct your tables in MySQL to match your Access tables.
Best to use a GUI utility. I use MySQL Control Center, but there are many
others that will work. Use fields that are direct analogues of field types
available in Access.

2) Create linked tables (in Access) to your new (empty!) MySQL tables.
Create these linked tables right alongside your Access data tables.

3) Use the Access query builder to create "append" queries that will
populate your empty MySQL (linked) tables with data from your Access tables.

Errors you get when you do these data appends will be indictive that your
MySQL table structure does not match your Access table structure precisely.
This method gives you the opportunity to work these differences out. The
data appends should work smoothly and error free.

Once this is accomplished, you can work with the linked tables just as you
would any other Access tables, even though the data actually resides inside
MySQL.
Or
You can put Access asside and communicate.
DAO or ADO <-> MySQL ODBC <-> MySQL

Don't erase Access though! It does come in handy.
I am using a dev serv, not sure if I need to configure it or if it is
as simple as to change the driver name to the DLL or if is is
descriptive
"using a dev serv" ???
I don't know what you are talking about here.
I'm confused


That will pass ;-)
Thomas Bartkus
May 31 '06 #2

P: n/a
Had similar problem, even thouth you may have an auto incremant field in
mysql, still use a dmax in access to incremant it and it goes into mysql
just fine and the #deleted# goes away. To gain access to a remote mysql
database, link the tables in access (need access 2000) and use ado if needed
to manipulate tables. No different than ms access 2000 as front end for sql
server. If you know access you know what I'm referring to. By the way
access 97 is still as good as a b-52 bomber, which is slated to still be
around til the year 2043. In fact, I have said all along, that microsoft
has too many employees now and are going way way too fast. Modern plastic
is good, but grainite is still better for a counter top.
They are wipping out too much too fast. Leave something that works well
alone. I truley believe that some of these young, wet behind the ears,
fresh out of college programmers are the type that would jump off of a cliff
if they heard it was the end thing to do. For now, I will keep using access
97 and 2000 for ado, and I will not get anywhere near the edge of a cliff.
"Vanessa" <va**********@yahoo.com> wrote in message
news:11*********************@c74g2000cwc.googlegro ups.com...
Hi there

I am an Access developer, and I have written applications for a 30
telephone call center, using the standard multiuser jet engine, it all
works fine, but I want to move our systems onto MySQL, as we get the
odd #DELETED# (that old chestnut) so that it is more stable, I have
installed mysql and myodbc and configured it in data sources (ODBC) and
it works fine (done the TEST).
But when I try to export a table from the mdb

I get the following prompt
"[MySQL][ODBC 3.51 Driver] Could not determine the driver name"
In advanced part of the ODBC config it says
DRIVER={MySQL ODBC 3.51 Driver} (I don't know if this is a description
or a path)

I am using a dev serv, not sure if I need to configure it or if it is
as simple as to change the driver name to the DLL or if is is
descriptive

I'm confused

Jun 4 '06 #3

P: n/a
Had similar problem, even thouth you may have an auto incremant field in
mysql, still use a dmax in access to incremant it and it goes into mysql
just fine and the #deleted# goes away. To gain access to a remote mysql
database, link the tables in access (need access 2000) and use ado if needed
to manipulate tables. No different than ms access 2000 as front end for sql
server. If you know access you know what I'm referring to. By the way
access 97 is still as good as a b-52 bomber, which is slated to still be
around til the year 2043. In fact, I have said all along, that microsoft
has too many employees now and are going way way too fast. Modern plastic
is good, but grainite is still better for a counter top.
They are wipping out too much too fast. Leave something that works well
alone. I truley believe that some of these young, wet behind the ears,
fresh out of college programmers are the type that would jump off of a cliff
if they heard it was the end thing to do. For now, I will keep using access
97 and 2000 for ado, and I will not get anywhere near the edge of a cliff.

"Thomas Bartkus" <th***********@comcast.net> wrote in message
news:LI********************@telcove.net...

"Vanessa" <va**********@yahoo.com> wrote in message
news:11*********************@c74g2000cwc.googlegro ups.com...
Hi there

I am an Access developer, and I have written applications for a 30
telephone call center, using the standard multiuser jet engine, it all
works fine, but I want to move our systems onto MySQL, as we get the
odd #DELETED# (that old chestnut) so that it is more stable, ...


You shouldn't be seeing #DELETED# errors.
It makes me concerned that you may have deeper problems that won't be
solved
by merely porting to MySQL.

You may want to explain this a bit more.

Hopefully, you are using Access version 2000 or higher. Access 97 at this
point is positively prehistoric. With prehistoricly oversized bugs, it is
beyond redemption.
I have
installed mysql and myodbc and configured it in data sources (ODBC) and
it works fine (done the TEST).


That's good and useful, but it does little more than prove you can
communicate with the MySQL server. A good starting point, however.
But when I try to export a table from the mdb
I get the following prompt
"[MySQL][ODBC 3.51 Driver] Could not determine the driver name"
In advanced part of the ODBC config it says
DRIVER={MySQL ODBC 3.51 Driver} (I don't know if this is a description
or a path)


It sounds like you are trying to use the Access table export utility to
port
your Access tables to MySQL. I'm sure you can muddle through that but I
don't recommend it.

If you have Access expertise but are MySQL green, then I would suggest -

1) That you construct your tables in MySQL to match your Access tables.
Best to use a GUI utility. I use MySQL Control Center, but there are many
others that will work. Use fields that are direct analogues of field
types
available in Access.

2) Create linked tables (in Access) to your new (empty!) MySQL tables.
Create these linked tables right alongside your Access data tables.

3) Use the Access query builder to create "append" queries that will
populate your empty MySQL (linked) tables with data from your Access
tables.

Errors you get when you do these data appends will be indictive that your
MySQL table structure does not match your Access table structure
precisely.
This method gives you the opportunity to work these differences out. The
data appends should work smoothly and error free.

Once this is accomplished, you can work with the linked tables just as you
would any other Access tables, even though the data actually resides
inside
MySQL.
Or
You can put Access asside and communicate.
DAO or ADO <-> MySQL ODBC <-> MySQL

Don't erase Access though! It does come in handy.
I am using a dev serv, not sure if I need to configure it or if it is
as simple as to change the driver name to the DLL or if is is
descriptive


"using a dev serv" ???
I don't know what you are talking about here.
I'm confused


That will pass ;-)
Thomas Bartkus

Jun 4 '06 #4

P: n/a
"jim whitaker" <kp*****@sbcglobal.net> wrote in message
news:j%******************@newssvr11.news.prodigy.c om...

By the way
access 97 is still as good as a b-52 bomber, which is slated to still be
around til the year 2043. In fact, I have said all along, that microsoft
has too many employees now and are going way way too fast. Modern plastic
is good, but grainite is still better for a counter top.
Sorry to disagree, but Office 97 was nowhere near as robust as a B-52.
Office 2000 was a major (and essential!) bug fix to 97. And even the
venerable B-52 has no useful place in aviation other than as an artifact ;-)
They are wipping out too much too fast. Leave something that works well
alone. I truley believe that some of these young, wet behind the ears,
fresh out of college programmers are the type that would jump off of a cliff if they heard it was the end thing to do. For now, I will keep using access 97 and 2000 for ado, and I will not get anywhere near the edge of a cliff.
You are in no danger whatsover of falling off the cliff edge.
From Access 97, the cliff edge is way, *way* over the horizon ;-)
Thomas Bartkus

"Thomas Bartkus" <th***********@comcast.net> wrote in message
news:LI********************@telcove.net...

"Vanessa" <va**********@yahoo.com> wrote in message
news:11*********************@c74g2000cwc.googlegro ups.com...
Hi there

I am an Access developer, and I have written applications for a 30
telephone call center, using the standard multiuser jet engine, it all
works fine, but I want to move our systems onto MySQL, as we get the
odd #DELETED# (that old chestnut) so that it is more stable, ...


You shouldn't be seeing #DELETED# errors.
It makes me concerned that you may have deeper problems that won't be
solved
by merely porting to MySQL.

You may want to explain this a bit more.

Hopefully, you are using Access version 2000 or higher. Access 97 at this point is positively prehistoric. With prehistoricly oversized bugs, it is beyond redemption.
I have
installed mysql and myodbc and configured it in data sources (ODBC) and
it works fine (done the TEST).


That's good and useful, but it does little more than prove you can
communicate with the MySQL server. A good starting point, however.
But when I try to export a table from the mdb
I get the following prompt
"[MySQL][ODBC 3.51 Driver] Could not determine the driver name"
In advanced part of the ODBC config it says
DRIVER={MySQL ODBC 3.51 Driver} (I don't know if this is a description
or a path)


It sounds like you are trying to use the Access table export utility to
port
your Access tables to MySQL. I'm sure you can muddle through that but I
don't recommend it.

If you have Access expertise but are MySQL green, then I would suggest -

1) That you construct your tables in MySQL to match your Access tables.
Best to use a GUI utility. I use MySQL Control Center, but there are many others that will work. Use fields that are direct analogues of field
types
available in Access.

2) Create linked tables (in Access) to your new (empty!) MySQL tables.
Create these linked tables right alongside your Access data tables.

3) Use the Access query builder to create "append" queries that will
populate your empty MySQL (linked) tables with data from your Access
tables.

Errors you get when you do these data appends will be indictive that your MySQL table structure does not match your Access table structure
precisely.
This method gives you the opportunity to work these differences out. The
data appends should work smoothly and error free.

Once this is accomplished, you can work with the linked tables just as you would any other Access tables, even though the data actually resides
inside
MySQL.
Or
You can put Access asside and communicate.
DAO or ADO <-> MySQL ODBC <-> MySQL

Don't erase Access though! It does come in handy.
I am using a dev serv, not sure if I need to configure it or if it is
as simple as to change the driver name to the DLL or if is is
descriptive


"using a dev serv" ???
I don't know what you are talking about here.
I'm confused


That will pass ;-)
Thomas Bartkus


Jun 5 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.