I made a little Java application which writes stuff to an Access database.
When I run it in Eclipse, it works just fine, but when i build it using Maven and run it, it fails.
As soon as I try to access the database it gives me the following error:
[Microsoft][ODBC Manager] Data source
name not found and no default driver
specified
I know this is a common error but there are so many vague solutions out there I'm too confused to get it fixed.
I have no User DSN's or System DSN's whatsoever, I also don't have a running SQL server as far as I know.
I have no clue as to what to do next.
Wondering if this could be a bitness issue (assuming the machine is 64bit)?
I suspect that this is more about which Java Runtime Environment) is being used to execute the built application rather than what is used to actually build it...
Microsoft only has a 32bit ODBC driver for Access - so, unless the Java application is being run in a 32bit JRE then I suspect there will be no way it can interface with the 32bit native C portion of the Bridge that, in turn, will load the 32bit ODBC Driver.
Just a thought...
You probably use connect string with relative .mdb filename. You can use full filename:
jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=c:\\Nwind.mdb
Related
The Problem
Hi, I'm trying to implement sqlite in a server plugin, but I'd like to use a different version than is provided with the server - is this possible?
I've set up sqlite in my project, and it works perfectly for most data types, however because of the server's sqlite version, I'm unable to write binary arrays to my database. The server ships with 3.7.2, however this version doesn't support Statement#setBinaryStream, so I'd like to use 3.8.11.2 in my project.
I'm unable to change the server's sqlite version, and it is unlikely that this version will be changed any time soon, so my solution was to try and include a different sqlite version in my project jar, and use that. I'm a big fan of sqlite, so if possible, I'd like to be able to use it.
What I've Tried
I have tried the following:
Use the maven shade plugin to include the sqlite-jdbc library with my project, relocating org.sqlite to me.Fupery.shaded.sqlite
Register my relocated driver with the java.sql.DriverManager singleton:
Driver driver = ((Driver) Class.forName("me.Fupery.shaded.sqlite.JDBC").newInstance());
DriverManager.registerDriver(driver);
Get the connection as usual
Connection connection = DriverManager.getConnection("jdbc:sqlite:" + dbFileURL);
But no luck! The lib is correctly included in my jar, and the code to register the driver (above) runs without exceptions, however when I try to write a byte stream, it throws an AbstractMethodError as usual (indicating it's using the old version, not the one I loaded).
Is there a way to specify which driver to use when getting a connection? I looked through the DriverManager and Driver methods but couldn't find anything I could use.
Alternative Methods
Alternatively, is there another method I can use to write a blob to a database in the server's provided sqlite version (3.7.2)? I tried Statement#setBytes before Statement#setBinaryStream, but I didn't have any luck - no exceptions are thrown, but the column I set the byte to is empty.
A test I wrote here returns without errors, but when I check the database afterwards, the "test" column is empty every time (other data types work fine):
$ SELECT * FROM test_table;
test1|
test2|
test3|
I've decided to use the Statement#setBytes method to write to a blob instead in 3.7.2, now that I've been able to get this to work correctly. It's is a simpler and tidier solution, and works just as well.
I'm working on some code that is acting strange. The code is using the Java reflection property, loading the method name from a JSON file. Works perfectly in Linux, yet, importing and running the same code in the same IDE, with the code running in the same version and profile of a Websphere Application server setup, they are both using the same source files through a file server mount. Other parts of the application manipulate these files without a problem in both environments. Yet, somehow in Windows, it is unable to load the method from the file while Linux can. Stepping through the debugger in Windows I find that the null pointer error occurs at the time of trying to dynamically load the method, while stepping through the code in Linux in the same manner it simply proceeds where Windows gets stuck without issues. I'm getting this null pointer error from the application pointing to a method that does not exist due to the failure to load:
java.lang.NullPointerException
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:19)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:33)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:41)
Given that the JRE is supposed to be portable and it shouldn't matter in what environment it runs, I suspect it's related to the OS. Has anyone experienced this issue before? I'm wondering if it's something that needs to be addressed at the OS level, or Java security settings? I know Windows is a bit more glitchy when it comes to drive mounts than Linux. I'm wondering if it's an obvious, well known issue with J2EE projects trying to use reflection in Java. I really don't think this has to do with the Webpshere, or project settings (Classpath, Deployment Descriptor, etc) since they are identical in both environments. Can't really find anything online about this quirk.
I've been trying to access a Visual Fox Pro database from Java for a week now. I'm getting desperate because my project is in a very tied budget and timeframe. (As any other project, I guess, hahaha)
I have a .dbf, a .cdx and a .fpt files. I need to be able to look for a record, extract data, and update data. I don't have a VFP licence.
I hope someone has some pointers or a working example that I can use. If the only way is buying a driver I'll be willing to consider it based on suggestions received.
This is a short description of what I have tried.
I found this xBaseJ: java objects to read and write to dBase files. But it doesn't suport CDX index files.
Also found this Example to access a dbf. But my tests show this exception: java.sql.SQLException: [Microsoft][Controlador ODBC dBase] La tabla externa no tiene el formato esperado.
I guess a translation to english of this error could be something like: java.sql.SQLException: [Microsoft][ODBC dBase Driver] External table is not in the expected format
Because of that error I think I need a newer driver. In this microsoft page say they no longer have an ODBC driver, and everybody should use OLE DB Provider. The problem is I haven't found a way to use it from java.
As far as I can tell, there is no way to do it directly. Found here someone talking about a JACOB "thingy", and someone comments about the need to create a C++ or C# "something" to be able to do what I need. I think he is talking about The JACOB Project: A JAva-COM Bridge. But I also don't know what COM calls would actually have to make.
Haven't been able to find a suitable JDBC driver.
Thank you all.
Ely.
I found the way to do it.
I ended up using JACOB (from here <= upd 2021-10-25: now here).
Downloaded and installed Visual FoxPro OLE DB driver from http://msdn.microsoft.com/en-US/vfoxpro/bb190232 (upd 2021-10-25: links there do not work anymore). the direct link is: Microsoft OLE DB Provider for Visual FoxPro 9.0 SP2 (upd 2021-10-25: does not work anymore)
Downloaded JACOB version 1.17 binary and source code.
Added jacob.jar as a Java Build Path library
Copied jacob-1.17-x86.dll to the project directory (same place as eclipse's .project file)
Copied jacob-1.17_src\jacob-1.17\samples\com\jacob\samples\ado contents to my src directory and:
Removed the ms directory
renamed test.java to Main.java
Changed the connection string to:
String connectStr = "Provider=vfpoledb;Data Source=C:\\path\\to\\Data\\;Collating Sequence=general;";
Changed the queryStr to match one of the dbf's name
Hope this helps someone else.
Since the jacob approach did not work anymore as described and others seemed to work without the OLE DB bridge, I cancelled trying there and successfully did it via hxtt.com drivers:
register with some email and the mailed link contains some password to get to the drivers page
there one can download the proper driver, e.g. v42 till Java 8 or v43 since Java 9
use the following JDBC settings in your env (e.g. Eclipse Database Explorer) to access your DBF files (e.g. you have some C:\foo\bar.dbf):
driver jar: e.g. DBF_JDBC42_tillJava8.jar
driver class: com.hxtt.sql.dbf.DBFDriver
URL: jdbc:dbf:/c:/foo/
(if required by your tool with dummy values:)
database: db
user/pass: usr / <empty pass>
You may find interesting to use a jdbc driver for foxpro files.
I made some quick tests with this one, and it almost looks like you are using a real database in Java.
Regards,
I have a program that, when compiled using the 32 bit JVM works fine, but has issues if I try to use the 64 bit JVM. The message I'm getting is: "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified".
I'm trying to connect to Excel and SQL Server databases using code like the following:
String file = directory + "/fileName.xlsm";
String connectStr= "jdbc:odbc:DRIVER={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" + file + ";READONLY=false";
try {
Class.forName(getDriver());
gConnection = DriverManager.getConnection(connectStr);
//do stuff with connection
}
When I tried to check the Driver Manager it didn't seem to have 64 bit version of the drivers. Any way to fix this easily and be able to connect using 64-bit drivers without manually changing settings on the computer (as this program will be distributed across multiple computers and I don't want to have to download a driver separately for ever computer that wants to run it)? Also, is it any more efficient to connect using 64-bit drivers, or are 32-bit ones just as good/fast (I do have very large data sets, so small differences would make a difference)?
64-bit applications cannot use 32-bit ODBC drivers, and vice versa, and that is why you are getting that error message. You can verify what ODBC drivers are available by running the 32-bit (C:\Windows\SysWow64\odbcad32.exe) and 64-bit (C:\Windows\System32\odbcad32.exe) ODBC Data Source administrator (Drivers tab) respectively - on a 64-bit system of course. The naming is confusing at first.
An application I worked with had a similar problem - the Access/Excel ODBC driver was 32-bit-only, meaning when run in 64-bit our application could not handle opening Excel or Access database files. We eventually switched to using the Apache POI library which is a Java library that can read/write Excel and other Office documents directly. You may want to consider giving that a try, though switching would involve some amount of work.
At the time, Office 2010 wasn't out yet. I didn't realize they created a 64-bit ODBC driver in Office 2010 and will have to see if that is a legitimate option now... even if it is I don't like relying on ODBC in a Java application.
How can I pack a Java application and MySQL installation files in a single exe file? Can I install the MySQL files automatically in background (or without any inputs from user)? This is just to simplify the installation procedure.
Java is cross platform, MySQL isn't, so you'd have to create various installers for multiple platforms with different MySQL binaries. If you want to include MySQL source code for non Windows systems, then that's another story... so I assume you want just an installation for Windows.
First of all, get an installation software that you'll feel comfortable with. There is a nice list of free and non free installers on Wikipedia.
Second thing, you can do a silent MySQL installation. How it's done is explained here.
But note that doing a silent MySQL installation without user's permission doesn't sound too good to me, since MySQL isn't exactly lightweight software and you might mess up something if a user already has MySQL somewhere installed.
So, by doing this, you have to be extra careful to check if port 3306 is already up and running (default MySQL port), and other sanity checks to see if there's a possibility of another instance lurking in the background.
It would be better if you at least informed your user that MySQL will be installed. Think about these details, because they might be dealbreakers so some of your users.
Use Java Web Start to launch the application.
JWS offers an ExtensionInstallerService that can be used for installing MySQL. Here is a small demo. of the ExtensionInstallerService.