I use JMP stats software to open an Access database (Version 2108 32-bit) and keep getting the error "ODBC Microsoft Access Driver Login Failed - The database you are trying to open requires a newer version of Microsoft Access". Looking further into the error, it seems that the database is using the features (BigInt, etc..) which cause Access to upgrade to the version 16.7. I checked the version of the database (?Application.CurrentDB.Version) and it was 16.7.
My questions are:
Is it possible to determine which table(s) is using the new features? I have 20+ tables in the database so it is very time consuming to go through each table.
How to properly revert the version back to 12.0? This is the known working version for my case.
How to prevent users from using the new features?
Thanks in advance!
Yes. Use DAO to open the TableDef objects and read the data type of the fields. However, for only 20 tables, manual inspection is probably faster, indeed if you wish to modify those fields using BigInt.
After having made the necessary corrections, create a new (empty) database file and import the objects from the corrected database.
Educate the users.
Related
I am using MySQL DB for my android application. I have installed phpmyadmin on my Ubuntu LAMP server and using it to access my DB. Is there any possibilities to access the DB using MS access 2010, as I need to do perform modifications on a regular basis to my DB
If the aim is to change the data and not the structure, using MS access is a good solution, as you can edit anything in linked tables very efficiently with litlle setup efforts.
To achieve this, first you need to download and install the MySQL ODBC driver.
In order to avoid issues, I advise you to install the 32 bit driver, even if you're on a 64 bit system. The 32bit will work flawesly, which is not always the case of the 64 bit.
Once installed, open the ODBC control panel and add an entry pointing to your MySQL database
Then in Access you can add linked tables using this ODBC entry
Once the table are linked, they will behave as if they are MS access tables and you can open them and edit data, and much more.
You can use Microsoft Access as a front-end to your MySQL database.
Refer: MySQL Documentation
But for your case, directly accessing database is wrong. I suggest better you have a view page with php to update DB with proper required validations.
The answer by Thomas G does an excellent job of describing WHAT we need to do, and even provides some good links.
What we need now is a good, step-by-step description of HOW to accomplish all the steps Thomas G describes.
I've been looking for this for a long time, and still no luck. However, I'm possibly on the track of getting that answer, and if I find it, I'll come back here and post it.
I am converting my C# asp site to use a mysql db instead of the local db that the project is first built with. I am using two dbs, one for the built in account functionality, and one for the functionality that I have added.
The problem I have is that when the second db is seeding, I get the following message:
The underlying provider does not support the type 'nvarchar(max)'.
I'm assuming this is due to MS syntax that works with the .mdf db, but doesn't work with MySQL?
How do I go about solving this?
I'm having a problem. One of my databases on our shared network will not open for any user. It says "Unrecognized Database Format."
I've had this problem before but was still able to open the database, compact and repair, or import all of the database objects into a new database.
The problem here is -- I can't even get it to the point of opening. Is there a solution here without the use of third party software to repair the database?
Open access, go to the database tools tab, select compact and repair database. You can choose the database from there.
WE had this problem on one machine and not another...the solution is to look in control panel at the VERSION of the Access Database Engine 2007 component. If it is version 12.0.45, you need to run the service pack 3
http://www.microsoft.com/en-us/download/confirmation.aspx?id=27835
The above link will install version 12.0.66...and this fixes the problem...thought I would post it since I haven't seen this solution on any other forum.
After much struggle with this same issue I was able to solve the problem by installing the 32 bit version of the 2010 Access Database Engine. For some reason the 64bit version generates this error...
Try to create a new database and import every table, query etc into this new database. With this import Access recreates all the objects from scratch. If there is some sort of corruption in an object, it should be solved.
If you're Lucky only the corrupted item(s) will be lost, if any.
Well, I have tried something I hope it helps ..
They changed the schema a little bit ..
Use the following :
1- Change the AccessDataSource to SQLDataSource in the toolbox.
2- In the drop down menu choose your access database (xxxx.accdb or xxxx.mdb)
3- Next -> Next -> Test Query -> Finish.
Worked for me.
Sometimes it might depend on whether you are using code to access the database or not. If you are using "DriverJet" in your code instead of "DriverACE" (or an older version of the DAO library) such a problem is highly probable to happen. You just need to replace "DriverJet" with "DriverACE" and test.
I want to create a desktop version of my mysql installation without having to setup a server on my machine.
I want to make use of MS Access' query designer so I can produce complicated queries.
I know I can produce an SQL file but I've no idea how to create an MS Access database from it ?
I'm not going to jump on the "Access sucks" bandwagon, though it can be very frustrating at times.
Worst case, You can start with a blank Access database (mdb file, since you specified pre-2007). Open the query designer & go to SQL view. Paste in one complete SQL statement (CREATE TABLE...), and run it. Fix any incompatibility errors, paste in the next (replacing the first), rinse, repeat. Be sure to do this in such order that any dependency "sources" get created before the dependents.
There may be a batch process available, but I don't know what it is offhand.
Moving from MySQL to something like Access is heading in the wrong direction.
If you need a server-less SQL installation or package as part of your distribution (which is a pretty common requirement these days since admins don't like users to install database servers on their machines), consider SQL Server Compact Edition (CE) or SQL Lite. They're both fully SQL compliant (unlike Access) and will cause you far fewer headaches than Access (which sucks). (Did I mention that Access sucks? Big time?)
SQL CE is a .NET assembly that runs in-process with your app, and is very easy to work with. Also, db objects you create will be upwards-compatibile with the full-blown SQL Server. It also works very, very well with Entity Framework if you're into ORMs.
I've heard praise for SQLite, but haven't worked with it. If you're not on .NET, this should be a good way to go.
Links:
SQL CE
SQLite
I don't know if this is a viable option, but if you can set up a DSN to point to your MySQL server, you can then use FILE | GET EXTERNAL DATA | IMPORT to import your MySQL tables into a blank MDB/ACCDB. It's a one-time operation, but I don't know that there's any other option here. You should get the option to import the table schema only and not schema+data. You may have to tweak data types in the resulting tables, since the MySQL data types won't necessarily map directly to Jet/ACE data types.
Then you can carry the MDB/ACCDB file anywhere you want.
I've recently been given a MS Access .mdb database file and asked to make it usable in a Linux system. What I'm looking for is a way to convert the Access database to an open-source database such as MySQL or PostGres.
I don't have MS Office, and it's a one-time project for a volunteer organization so I don't want to spend money if it's avoidable. I'm running Vista x64, and have a Linux virtualbox, so something usable in either one will be good.
Forunately you don't need MS Access to get data out of an Access database. While there are tools like MDBTools that will read .mdb files on Linux, I've found them to be unstable for larger, more complicated databases. The best way is to use ADO or ODBC on Windows to export the data from the .mdb database into a format you can import somewhere else (like csv).
I've had good luck using DBI with Ruby, or using ADO in a Ruby script.
Following links may be useful for you.
MySQL:
access migrate
read.php?65,27115,27115
PostgreSQL:
Microsoft Access to PostgreSQL Conversion
Converting from other Databases to PostgreSQL
I used the MySQL Migration Toolkit and it worked very well for tables, even creating a reusable script. It is free and simple to use.
This toolkit is now EOL and the MySQL Workbench 5.2 replaces it.
Unfortunately, it falls over with "A problem caused the program to stop working correctly" when I try it with MS Access on my system. At the last step, of course. (Jan 16 2013)
Either MySQL or Postgres will work fine as a replacement data store for your access data. If your Access database contains Forms or Reports there really isn't a direct replacement in Open Source, and you'll either need to retain the Access front end and access the data using ODBC drivers, or code a new series of Forms or Reports in PHP or your favorite web scripting language.
I had the same problem now, and found this freeware to be exactly what I needed: http://www.bullzip.com/products/a2m/info.php
It extracted everything from the MDB file generated an SQL file I imported directly into my MySQL server.
There are two parts to the process
1) convert from Access database to scripts, there are some good options although you may need Access and potentially Sql Server too, to do this
2) Pick your target database - MySql would seem like a good fit, run it up on Linux or Windows and run the ddl and data in from the scripts.
Not sure how you can do this without Access though, do you have any idea what the schema looks like? If you do run into probs I could help out with step 1, but I don't have a Linux install at the moment.
i beg to differ: there is no need to use external tools or costly middleware. the simplest, cleanest, cheapest, fastest, safest (did i say BEST?) solution is using ODBC and integrating fully.