I have searched here and Google, with no solution so far.
The problem is Access 2013 no longer wants to connect to DBF.
Each month, I will get 33 DBF files (each with a CDX file) that I have to import into MySQL. The front end for this is Access 2013.
I've built a few other applications that do similar functions, so I'll just tweak one of them for this new data.
I don't know the the actual source of the original data, but it's my understanding that dbase & visual foxpro use the same format.
The application is designed to link to the data files, where I'll run queries (and maybe VBA as well) to port the data into tables linked to MySQL. All tables are linked using VBA and a DSN-Less connection.
I can use VFPOleDb, or something else if it gets me what I want. I've actually already installed this, but can't figure out the code to do what I need.
I'm running 64-bit Access & Windows 7.
Thanks.
Can you launch a VB program to convert the files to xlsx. A friend of mine had the same situation and we finally found this on a forum (don't remember which one, I just had this code copied into a word doc I sent her.)
Function dbf2xlsx(dbffile)
Dim xlapp, objWorkbook As Object
Dim SaveFile As String
SaveFile = Left(dbffile, Len(dbffile) - 3) & "xlsx"
Set xlapp = CreateObject("EXCEL.application")
Set objWorkbook = xlapp.workbooks.Open(dbffile)
xlapp.Application.Visible = False
xlapp.Application.DisplayAlerts = False
xlapp.ActiveWorkbook.SaveAs SaveFile
xlapp.ActiveWorkbook.Close
End Function
Now she only had 1 file to import so I don't know how effective or efficient this may be.
I ended up using an external program called DBF to MySQL by Intelligent Converters. Except for the fact that it doesn't convert indexes, it does a great job. It has a command line interface, so I used Access to offer the options, build the command string, then execute it.
In retrospect, I think I would have rather read the raw data files and pulled the data that way instead.
For anyone with this issue you can link to a DBF table using code similar to below, (note that error checking etc ought to be included) AND obviously change the hard coded names to whatever is required
Dim tdf As TableDef
Set tdf = CurrentDb.CreateTableDef("NameYouWant")
tdf.Connect = "Dbase III;Database=c:\test\dbase\"
tdf.SourceTableName = "example.dbf"
CurrentDb.TableDefs.Append tdf
Using access as a frontend doesn't seem to be a good idea.
Anyway, if you want to import VFP data into MySQL, then it could be done in various ways. Unfortunately VBA with 64 bits is not one of them (doable with drivers from say Sybase ADS but not worth the effort IMHO).
You can use VFP itself or C#, or any other language like Go, Python ...
With VFP itself, you would create a cursorAdapter or remote view or SPT cursor to your MySQL, and then push the data into that cursor from VFP table and commit. It is a simple process.
With C#, you would open connection to both MySQL and VFP (using VFPOLEDB) and then pump data from one to other (same with other languages as well).
AFAIK, access doesn't have an option to get data from OLEDB sources directly (Excel does), if your office were 32 bits, you could use that.
(If it were MS SQL Server, then you could use BulkCopy class in .Net)
Access 2013 dropped support for DBF files. It shows error Could not find installable ISAM when trying to open a linked DBF table. But you can install Access 2010 component that supports DBF files and keep using them in Access 2013.
First, download and install Microsoft Access Database Engine 2010 Redistributable (free, contains 32bit and 64bit versions). This will install (among other things) the required ACEXBE.DLL library to access dBase files directly. But this is not enough, since this installs it under OFFICE14 (2010), not for OFFICE15 (2013).
Now you need to copy 4 registry keys from Office 14 to Office 15. This registry patch will do it for you, but it’s highly recommended that you understand what it’s doing. This one is for 64bit Office:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\Access Connectivity Engine\Engines\Xbase]
"win32"="C:\\PROGRA~1\\COMMON~1\\MICROS~1\\OFFICE14\\ACEXBE.DLL"
"DbcsStr"=hex:01
"Mark"=dword:00000000
"Date"="MDY"
"Exact"=hex:00
"Deleted"=hex:01
"Century"=hex:00
"CollatingSequence"="Ascii"
"DataCodePage"="OEM"
"NetworkAccess"=hex:01
"PageTimeout"=dword:00000258
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\Access Connectivity Engine\ISAM Formats\dBASE III]
"Engine"="Xbase"
"ExportFilter"="dBASE III (*.dbf)"
"ImportFilter"="dBASE III (*.dbf)"
"CanLink"=hex:01
"OneTablePerFile"=hex:01
"IsamType"=dword:00000000
"IndexDialog"=hex:00
"CreateDBOnExport"=hex:00
"SupportsLongNames"=hex:00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\Access Connectivity Engine\ISAM Formats\dBASE IV]
"Engine"="Xbase"
"ExportFilter"="dBASE IV (*.dbf)"
"ImportFilter"="dBASE IV (*.dbf)"
"CanLink"=hex:01
"OneTablePerFile"=hex:01
"IsamType"=dword:00000000
"IndexDialog"=hex:00
"CreateDBOnExport"=hex:00
"SupportsLongNames"=hex:00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\Access Connectivity Engine\ISAM Formats\dBASE 5.0]
"Engine"="Xbase"
"ExportFilter"="dBASE 5 (*.dbf)"
"ImportFilter"="dBASE 5 (*.dbf)"
"CanLink"=hex:01
"OneTablePerFile"=hex:01
"IsamType"=dword:00000000
"IndexDialog"=hex:00
"CreateDBOnExport"=hex:00
"SupportsLongNames"=hex:00
For 32bit Office 2013 running on 64bit Windows it’s slightly different:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Access Connectivity Engine\Engines\Xbase]
"win32"="C:\\PROGRA~2\\COMMON~1\\MICROS~1\\OFFICE14\\ACEXBE.DLL"
"DbcsStr"=hex:01
"Mark"=dword:00000000
"Date"="MDY"
"Exact"=hex:00
"Deleted"=hex:01
"Century"=hex:00
"CollatingSequence"="Ascii"
"DataCodePage"="OEM"
"NetworkAccess"=hex:01
"PageTimeout"=dword:00000258
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Access Connectivity Engine\ISAM Formats\dBASE III]
"Engine"="Xbase"
"ExportFilter"="dBASE III (*.dbf)"
"ImportFilter"="dBASE III (*.dbf)"
"CanLink"=hex:01
"OneTablePerFile"=hex:01
"IsamType"=dword:00000000
"IndexDialog"=hex:00
"CreateDBOnExport"=hex:00
"SupportsLongNames"=hex:00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Access Connectivity Engine\ISAM Formats\dBASE IV]
"Engine"="Xbase"
"ExportFilter"="dBASE IV (*.dbf)"
"ImportFilter"="dBASE IV (*.dbf)"
"CanLink"=hex:01
"OneTablePerFile"=hex:01
"IsamType"=dword:00000000
"IndexDialog"=hex:00
"CreateDBOnExport"=hex:00
"SupportsLongNames"=hex:00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Access Connectivity Engine\ISAM Formats\dBASE 5.0]
"Engine"="Xbase"
"ExportFilter"="dBASE 5 (*.dbf)"
"ImportFilter"="dBASE 5 (*.dbf)"
"CanLink"=hex:01
"OneTablePerFile"=hex:01
"IsamType"=dword:00000000
"IndexDialog"=hex:00
"CreateDBOnExport"=hex:00
"SupportsLongNames"=hex:00
Note that win32 path may be different on your system due to 8dot3 names assignments.
After this registry patch, your database with linked DBF files will work like in previous Access versions.
Related
I have a problem when trying to connect to MySQL database using Windows OBDC driver. There are plenty of search hits regarding the obvious... people are using old versions, however, I'm not.
mysqld is on CentOS 6.4 32bit
./usr/libexec/mysqld Ver 5.1.69 for redhat-linux-gnu on i386 (Source distribution)
So I'm at a loss to understand where any pre 4.1.1 protocol is coming from. Any ideas?
I guess that if you ask the right question its easier to find the answer.
In this case "my" problem relates to how the passwords are hashed and stored in the database. Legacy passwords were stored with a shorter hash that's now deprecated.
A few important points:
mysql_upgrade cannot and does not upgrade passwords, nor does it warn about it in some versions, see: http://bugs.mysql.com/bug.php?id=65461.
Even it you have mostly the latest server and clients, all it takes is one legacy client somewhere to create a legacy password and then you'll have trouble with that account no matter what client tries to use it.
Different versions have treated the situation differently so you can be sitting on some legacy passwords in your database and then suddenly, for no apparent reason, some accounts stop working... this is because of how different versions chose to handle the situation.
You cannot upgrade passwords. You must know what they are and you must change them.
EDIT: To be more clear, you must change the password that is stored with the shorter hash using a new client that uses longer hashes. By doing so you will be writing that accounts password with the longer hash, at which point nothing should be flagging attempts to access the account any more. If the problem is recurrent you should be looking for the older clients at your site which are still writing passwords with the deprecated hash length.
MySQL Workbench 6.08 in the Manage Server Connections, Connection tab, Advanced sub-tab you must check the box 'Use the old authentication protocol.'
Try installing old version driver 3.51.30: http://dev.mysql.com/downloads/connector/odbc/5.1.html#downloads
It works on my Mysql Ver 5.0.24a-community
I ran into this while using the ODBC Connector for Windows to connect to a Percona 5.5 server. which has secure_auth disabled.
From what I found the ODBC connector, unlike MySql Workbench, does not support an option to authenticate logins which use the old 16-byte hashed passwords. There is a bug report regarding this, but it appears the assignee is/was confused about the feature request (See bug #71234).
I was able to update the mysql login to use the new 41-byte hash using these commands:
set old_passwords=0;
set password=password('yourpasswordhere');
As I mentioned our server has secure_auth disabled, which appears to cause password() to return old_password() results. Running set old_passwords=0; will enable the password() method to generate the new 41-byte hashes (for the duration of your session).
I had a similar error message when remotely trying to access my MySQL database. Using Directadmin I easily changed the MySql database password as suggested above. This automatically generated the password using the newer hash method. This solved the remote connection problem instantly.
I found another solution in case anyone hits this - very weird -
Install the 5.1 64 bit ODBC driver - verify an ODBC connection by itself works, if you can connect then you should be able to after doing #2
Click on Linked Servers - Providers - right click on MSDASQL, click on Properties
uncheck "Allow inprocess" - which is a good thing to do unless you need to insert TEXT and NTEXT fields.
Create your linked server connection or test the one you have been fighting with - lol
When I had "Allow inprocess" checked I still got the error even though the ODBC system DSN worked fine. I'm assuming because I had a mixture of 5.2 (with servers that worked fine) and 5.1 for the servers that didn't, SQL was sharing the processes because the 5.1 driver does not give that error.
If you can't change your server, perhaps you can change your client: http://bugs.mysql.com/bug.php?id=75425
We have our application developed and tested with sql server 2008r2 using ASP.NET on windows server. Now we have a requirement to move the database from windows to oracle on red hat linux.
We haven't yet setup the infrastructure to test the same. I would like to know in the meantime if anyone has successfully done this kind of thing. Pointers to any resources will be a great advantage.
Is changing the connection string the only thing that needs to be done or are there any specific configuration in Linux to allow this?
I will verify this once I get the environment ready, but as a headstart if anyone has any similar experience, do share.
Thanks in advance.
P.S: For migration of table structure, storedprocedures etc to oracle we will be using the Sql Developer tool.
I would like to answer my question,because, migration to oracle is not that straight forward, but there are some tips that may help anyone migrate to oracle on windows or linux with less headache.
The first thing the Sql developer tool does a good job of migrating sqlserver schema and data to oracle including storedprocedures, constraints, triggers etc.
It also does a good job of datatype mapping and provides option to remap datatype if required.
Some caveats and precautions.
Oracle has a limitation on the length of stored procedure names of about 30 characters. This is the area you need to resort to some manual renaming as when migration SP's or identifiers whose name is greater than 30 characters may get truncated.
The other common issue that you may face is respect to date insertion and formatting. You can use the following snippet to avoid the headache. The common error will be "Not a valid month."
OracleConnection conn = new OracleConnection(oradb); // C#
conn.Open();
OracleGlobalization session = conn.GetSessionInfo();
session.DateFormat = "DD.MM.RR"; // change the format as required here
conn.SetSessionInfo(session);
The most annoying error would be well character to numeric conversion when inserting or updating data or related error.
The issue here is when you add parameters to command object for sql provider, the binding happens by name, but forOracle.DataAccess the default binding is by position. Here's the post that saved me lot of headache.
ODP .NET Parameter problem with uint datatype
What you can do is set the command.BindByName = true;
When migrating SP's that returns data, oracle creates an out parameter ref cursor. This needs to be taken care of while constructing command parameters.
For e.g.
OracleParameter refp = new Oracle.DataAccess.Client.OracleParameter("cv_1", OracleDbType.RefCursor, ParameterDirection.InputOutput);
command.Parameters.Add(refp);
Also the sqlserver requires parameters to SP be prefixed with "#" and oracle doesn't. This can be easily taken care of in your data layer.
Also since there is no bit datatype in Oracle, number(1) works fine. You may need to convert your bool to numeric, if required.
Hope this helps someone avoid a migration headaches. I will post more issues if I encounter.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
I have an ASP.NET app that uses a SQL Server database. I now need to pull data from Sybase ASE into that SQL Server database for my app to consume, and I'm not having any success with my ideas.
Has anyone done this? Any ideas/suggestions/tips?
You can configure a linked server from SQL Server to Sybase. It should be fairly vanilla using the Sybase provider on the MS side.
Okay, I've finally (through lame trial and error) found out how to link my Sybase ASE (12.5) server to my SQL Server (2008) which will allow the integration I want. Here's roughly how I did it:
Logged in to Sybase ASE OLE DB Configuration Manager (this is like the Sybase version of Windows' ODBC Data Sources) and added an OLE DB data source. I believe you must be an admin on the PC to do this.
In SQL Server 2008 Management Studio, went to Server Objects > Linked Servers. Right click and select "New Linked Server".
In the Linked Server Properties, I set the following properties:
General:
--Linked server: the name of your linked server as you want it to appear in your linked server list
--Provider: Select Sybase ASE OLE DB Provider from the dropdown list.
--Product name: The exact name of the OLD DB data source you just created in Sybase ASE OLE DB Configuration Manager.
--Data source: Same as Product name.
--Provider string: I left this blank
--Location: I left this blank
--Catalog: The default database (master or whatever) to log on to.
Security:
--You need to map a valid SQL Server logon to a valid Sybase logon. I did not use impersonation (which does a credentials pass-thru).
--I chose my connection Be made without using a security context.
Server Options:
--All the defaults worked for me.
Throughout, the standard SQL Server help worked fairly well as a guide. Though not always true, F1 was my friend here.
I can now do distributed queries, DTS or SSIS packages, and use SSRS. This takes a lot of the suck out of Sybase ASE.
Of course the above can be done via the command line using sp_linkserver, but the GUI is more comfortable for a lowly dev like me.
Use Management Studio or Enterprise Manager to import the data using the data importation wizard. That should be it, just make sure you pick the right data provider in the wizard and you should be good to go.
If you want this to be a live feed create a small windows service to manage the exchange of information. It should be relatively simple to do, just a little bit of leg work on your end. If you are adverse to that there are plenty of off the shelf solutions that can do this for you.
The question is a little vague on specifics:
Is this a one time conversion or part of a repeated process.
Is the source machine "reachable" from your destination machine (can you connect the two or do you need to read in files)
With most conversions there are two parts:
Physically getting data from the source into the destination.
Mapping data from the source to the destination tables.
It is hard to make any recommendations without more info. What would be fine for a one time conversion would not work if you need to read in data all day every day. Also, if the source database can not be connected to and you have to pass files, they methods change.
We commonly use MS Visual Foxpro v9.0 SP1, the language, tables, and reports. However, sometimes we use an ODBC driver to connect to the tables. The ODBC driver was written for Foxpro v6, and doesn't support certain nested selects, autoincrement fields, or embedded casts.
We would like to find an alternative to what we have. It could be another ODBC driver that works with Visaul Foxpro v9, or a complete alternative to ODBC. Is there such a thing?
Thanks.
(Talk about reuse, just answered this in another thread today)
If you are looking for an ODBC driver for VFP databases and tables you might consider looking at Advantage Database from iAnywhere. The have a local engine and a server engine. The local engine has the engine to access DBF data, but for your case, it also has an ODBC drive that works with VFP data up to and including the current Visual FoxPro 9. The local engine and the included ODBC driver are free.
http://www.sybase.com/ianywhere
You can via COM+ and do almost anything in VFP, however, you have security issues through Admin Tools, Component Services..
You can either build as a single-threaded or multi-threaded DLL.
Once registered, and the typelibrary info is "Add Referenced" to a C# (or other) app, you can make function calls with whatever parameters you need. There are many things you can return back, but typically tables, I send back as XML (via Foxpro's XMLAdapter class), then stream convert to a table once in C#. Its been a while since I worked it that way, but that give tremendous flexibility as you can do your queries, scan loops, and other complex conditional testing and updating of the cursor before generating out the XML and returning it as a string.
DEFINE CLASS YourClass as CUSTOM OLEPUBLIC
FUNCTION GetMyData( lcSomeString as String)
select * from (YourPath + "SomeTable" ) where ... into cursor C_SomeCursor readwrite
.. any other manipulation, testing, etc...
oXML = CREATEOBJECT( "xmladapter" )
lcXML = ""
oXML.AddTableSchema( "C_SomeCursor" )
oXML.ToXML( "lcXML", "", .f. )
return lcXML
ENDFUNC
ENDDEFINE