File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Linux / UNIX and the fly likes How to access .mdb file which is in remote folder in linux Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » Linux / UNIX
Bookmark "How to access .mdb file which is in remote folder in linux" Watch "How to access .mdb file which is in remote folder in linux" New topic
Author

How to access .mdb file which is in remote folder in linux

charu java
Greenhorn

Joined: Dec 05, 2012
Posts: 11
Hi Team,


The above code is sample piece which would connect to the Access DB which .mdb file is in the remote folder and execute a simple query and retrieve some sample data.This works fine in Windows. but in linux we are not able to access the remote .mdb file.
Please help me in resolivng this issue in java side.
Heard We could use jackcess library it will access an Access DB through a direct API.
Please Explain howcome jackcess help in resolving my issue.

Thanks in Advance
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42362
    
  64
but in linux we are not able to access the remote .mdb file.

Why not? What exactly happens? My first guess is that there is a problem with how the Linux share is mounted. Does it maybe require a password? I would also imagine that it needs to be a CIFS share in order for ODBC to be able to access it (maybe served via Samba), but that's just a guess.

Please Explain howcome jackcess help in resolving my issue.

Your first stop should be to read the Jackcess documentation, particularly the FAQ and Cookbook pages. That should get you started.


Ping & DNS - my free Android networking tools app
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42362
    
  64
As an aside, the exception handling in your code is problematic. The connect method returns null if the connection can not be established, but the getData method neither checks for that, nor does it catch it (catching SQLException does not catch a NullPointerException). And neither method does any logging of exceptions, so you will never know what happened.
charu java
Greenhorn

Joined: Dec 05, 2012
Posts: 11
Thanks Dude.

since am very new to linux environment. It will be very helpful if you could explain in detail what i can do inorder to acheive this in linux environment.
Whether to go with jackcess library will be correct choice. This issue is happening while deploying the project in linux environment in production and also was asked to solve it in java side itself.
Hope am making you all clear about my problem.

Thanks in Advance
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42362
    
  64
Whether to go with jackcess library will be correct choice.

We don't have enough information to answer that, because we don't know why it fails with ODBC. Since you're new to Linux, you may not be best placed to investigate this - consult with someone who has more experience, touching on how that Linux share is mounted, whether CIFS is involved, what exceptions you're getting (you haven't posted those here), etc.

Hope am making you all clear about my problem.

Actually, no. Please read TellTheDetails (<- that's a link), and then try to answer the questions I posed in my previous post.
charu java
Greenhorn

Joined: Dec 05, 2012
Posts: 11
Actually thing is there was no JdbcOdbc bridge driver installed on linux. thats why the UNC reference in the url will not work on linux.
This was the reason given by production team.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42362
    
  64
I doubt that that is true, but I'm certainly no ODBC expert, much less on Linux. UNC is about file systems, not ODBC. It makes no sense to install an ODBC driver on a remote server, when all the local driver wants is access to the remote file. I don't think that ODBC ever involves two drivers somehow talking to one another, even when two different machines are involved.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

A UNC name on Linux has the following format:

//SERVER/DIR/FILE.EXT

Compared to the Windows format:

\\SERVER\DIR\FILE.EXT

That's one item.

The JDBC-ODBC bridge driver is just that. It allows a Java app to use JDBC to communicate with an ODBC driver. And it comes standard with every JDK I know of. But the ODBC driver does not, and you need an ODBC driver that runs on the Linux machine, because the UNC name in the URL is for the DATABASE FILE, not the database driver. MS-Access (and FoxPro) don't have a client-server structure, so the driver must be wholly contained on a single system, and in this case, it's the Linux system, since that's where the logic resides.

Getting an ODBC driver for Linux has always been frustrating for me. It's not something Linux developers care much about. In part, because to do the job right, you need to know internal details of the Windows database, and Microsoft doesn't always provide useful information on such things. And even when they do, Microsoft is so good at churning details that the drivers frequently break.

There are some other issues as well. MS-Access is not designed for multi-user use. So it should be avoided for explicitly multi-user systems (such as web servers), and used with extreme care by multiple users on a LAN. You can very easily corrupt the file. A more practical approach might be to replicate the data into a real DBMS, which can then be safely accessed by a stock JDBC driver. You can use one of the ETL products such as Pentaho DI for that job.


Customer surveys are for companies who didn't pay proper attention to begin with.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42362
    
  64
Tim Holloway wrote:...you need an ODBC driver that runs on the Linux machine, because the UNC name in the URL is for the DATABASE FILE, not the database driver. MS-Access (and FoxPro) don't have a client-server structure, so the driver must be wholly contained on a single system, and in this case, it's the Linux system, since that's where the logic resides.

I interpreted the question to ask how to access an MDB file on a remote Linux machine - in which case the driver would be on the client machine, not the Linux machine, correct?

charu, can you clarify what, exactly, your scenario is?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16158
    
  21

Ulf Dittmer wrote:
I interpreted the question to ask how to access an MDB file on a remote Linux machine - in which case the driver would be on the client machine, not the Linux machine, correct?


Not for Access or FoxPro. Not unless the MDB itself was on the Linux machine. And while the question didn't actually specify, the use of a backslashed UNC name, plus the general absurdity of keeping an MDB on a Linux system made me assume that the MBD is on a Windows machine share, not a Linux CIFS share.

Unlike "Real" DBMS's, these 2 products do not run under server daemons. There's no active process on the "server" machine. All the work is done in the driver, which is to say on the client. Only the data itself resides on the server.

So if the Linux machine is the client, the Linux machine needs an ODBC driver.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to access .mdb file which is in remote folder in linux