I am trying to access a Visual FoxPro Database through MS Access 2013 on a Windows 7 Machine, but I am getting this error.
"specified driver could not be loaded due to system error 0. The operation completed successfully(Microsoft Visual FoxPro Driver C:\Windows\system32\vfpodbc.dll).(#160)"
I tried installing Microsoft OLE DB Provider for Visual FoxPro 9.0 SP2 but I am getting the same results.
Any help is much appreciated.
You cannot use OLEDB with Access, can you? If you can then it is straight forward with VFPOLEDB driver.
You cannot use VFP ODBC driver if database version is later than VFP6.
If you are in a need to downgrade to access (which I never classify as a "database") then you could use Excel in between. Excel can import data using OLEDB (but strangely access can't, go figure). Or if you know how to write VBA code in access then maybe you could utilize the OLEBD driver from there too.
Another option might be to get the data to SQL server express via OleDb, then from SQL server to access (yet a bigger downgrade).
Another option would be to use code for this. If it were from VFP it would be as easy as 1,2,3 creating a cursor adapter or remote view to access and pumping data there. With C# too you can create connections to both sides, read from one and write to the other.
If I were you, I wouldn't choose to downgrade to access, but maybe upgrade to postgreSQL, MS SQL, ...
PS: Check out Advantage Database Server. It was supporting ODBC for VFP (local server version for free). That might be your option.
PS2: Access can import XML, right? Maybe you would want to export VFP data as XML and import from there.
Related
I have always worked with a LAMP stack - I'm a bit lost when it comes to Microsoft.
I have been sent a very large Microsoft SQL file (.bak) and I would like to take a look at it (using something like PHPMyAdmin).
What do I need to do from zero to importing/viewing this database (and what tools should I be acquiring/using in order to do so)?
Help is much appreciated, thank you.
Install MS SQL Server Express
Run SQL Server Management Studio and connect to your local instance.
Using GUI restore your database(SQL Server Express support max 10GB DB).
Now you can see DB Objects using Object Explorer and write custom queries.
If your DB is larger than 10GB download SQL Server Standard/Enterprise trial version.
I've been wondering what are the benefits of using an ODBC driver to interface with a MySQL server? What advantage does that have over directly connecting to the server via TCP and firing off your SQL commands directly?
I'm working with a code base written in labVIEW that references a UDL file which references a data source and its associated ODBC driver to handle the connection to the server. I'm not yet convinced its necessary. I can see the benefit of using a driver if you are connecting to Microsoft Access or excel but if your recipient is an SQL server of some type why would you need a middle man to handle your SQL commands?
I have used the ODBC driver 3.51 for connecting to MySQL Community Server 5.1 for some time now. The ODBC driver allows you (on a Windows computer) to add your MySQL connection to the ODBC data sources list. Now you can reference this data source in many compatible applications. I have been able to use this ODBC connection in VB.Net applications as well as proprietary applications for printing and other functions with ODBC functionality.
I would say that when coding web or python applications i always use the built in MySQL packages, but if you need to access your data through VB.Net or another proprietary application (like a stand-alone windows app) you probably need to set up a system ODBC data source to access your database. To me the ODBC lets Windows access MySQL easily. Without Windows i don't think you need it.
Why ODBC and not JDBC? Some reasons come to mind in order of helpfulness when using JDBC:
Standard api to access the results from a query. To iterate over the results and to get the actual values with the appropriate type.
No need to know how the protocol works to connect to the server. Just use the host, user, password, send the SQL and iterate over the result.
Abstract out the connection to the database. Changing the database should be simpler.
Standard way to commit and rollback for transaction based changes.
In my experience, JDBC is very verbose. You need to write many lines to accomplish simple things. I've found the Spring JDBCTemplate wrapper to be an extremely easy to use alternative for simple stuff.
I'm trying to import data coming from a Paradox Database (all files *.DB are located in a folder) to Sql server 2008 with SSIS 2008.
From my OLE DB Source, I created a new Connection using Jet 4.0 OLE DB Provider and then specified "Paradox 5.0" in Extended Properties but when testing the connection I get every time the same error : " ISAM Driver not found"
Any idea how to solve this ?
Thanks a lot
Run into this problem recently when trying to import Paradox 5.x files to SQL Server 2008 R2 via SSIS in Windows 7.
What was missing?
The Borland Database Engine (BDE). I have installed the 5.2.0.2 version downloaded at www.prestwood.com. You need to register into the site in order to get it. This is the name of the downloaded zip file "mprestwood_KB100537_attachment.zip".
So, after installing the BDE, solved the problem with these steps (witch i think all of you should already have tried with no success):
Create a System DSN with the Paradox Driver, using ODBC 32 bit Manager, usualy at <drive>:\Windows\SysWOW64\odbcad32.exe, configuring it to point to the folder where the paradox .DB files are.
In SSIS, create an ADO.Net connection manager using the previous created DSN
Configure the created connection manager to use the provider ".Net Providers\Odbc Data Provider", and in the Data source specification select the created system dsn
In a Data Flow Task, add an ADO Net Source using the created connection manager
"Automagicaly" everything goes as it should, you can see the paradox files appearing as tables, their columns, etc. Now you only have to choose your destination...
Hope this helps, i sure wasted a great deal of time to get this running... but is running, time to move on...
JB
I wonder whether it is possible to read data from mysql database not remotely from server, but just from a file on my disk, like from .mdb files. A happened to work with 2010 Office which gives .accmdb files rather then .mdb and cannot convert them, that's why I switched to mysql.
Any help would be greatly appreciated.
You can use MySQL Embedded server. That will be similar to how you are working with Microsoft Access. AFAIK, Anydac supports MySQL Embedded server. May be other libraries too.
But I does not see a reason to replace Access with MySQL. To work with .accdb files you need to use different OLEDB provider (I expect you are using ADO) - "Microsoft Office 12.0 Access Database Engine OLE DB Provider" or similar.
I am using 64-bit Vista and I need to migrate an access database, in Office 2007 to SQL Server.
I don't want to have to write an SSIS package to do this, but that may be my only option.
Is there any other way to do this? I have about 330M of data in Access that needs to be moved, so I can write a webapp to replace this database.
Update: The error is:
The upsizing Wizard does not work with the version of Microsoft SQL Server to which your Access project is connected. See the Microsoft Office Update Web site for the latest information and downloads.
In Access, use the upsizing wizard under tools menu...
Edit, checked to see if it's still there: it has issues with SQL Server 2008.
Do you get the same error? (yes you do, says your edit)
Alternative: SSMS/Migration for Microsoft Access
See if creating a Linked Table inside Access DB (which points to your destination table in SQL Server) helps.
OR
See if you can use SQL Server functions (such as OPENROWSET) to open the Access tables.
The SQL Server 2008 Import/Export tool has worked great for me for migrating tables as well as data. You may need to install the SQL Management Studio to get the import tool also (it'll show up in your Start menu). It supports moving tables/data around from various sources, and I'm guessing that Access 2007 is supported.
That said, the SSMS/Migration for Microsoft Access tool may work the best overall.
Best of luck.
When all else fails, you could try creating an ODBC DSN for your SQL Server and then export the tables to that DSN. It won't get all the datatypes right, but it might be good enough to get things started if nothing else works.
I think it's pretty amazing that you can export a Jet/ACE table to an ODBC data source, to be honest.