• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
charulatha Ramalingam
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
charulatha Ramalingam
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic