Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Databases / September 2003

Tip: Looking for answers? Try searching our database.

Q: Entity Bean & MS Access Database

Thread view: 
Soul - 27 Sep 2003 06:01 GMT
Hi,

I am learning to create an entity bean to connect to MS Access database. I
use the following method:

1.    Goto [Tool] -> [Server Configuration] in Deploytool.
2.    Select [Standard] at the tree in left pane.
3.    In the right pane, I add a new [JDBC Drivers]:
sun.jdbc.odbc.JdbcOdbcDriver.
4.    In the right pane, I add a new [Datasources]'s [JNDI Name]:
jdbc/MemberDB.

The problem is I don't know what should I enter in the [JDBC URL] for the
new datasource. My database is locate in "C:\aFolder\database.mdb".

Can someone show me what should the JDBC URL be?

Thank you.

Signature

Soul

Herman Timmermans - 27 Sep 2003 06:37 GMT
> Hi,
>
[quoted text clipped - 14 lines]
>
> Thank you.

I see that you'll be using the JDBC-ODBC bridge.  A JDBC URL identiefies a
specific db and different JDBC drivers use different URL syntax.  But they
all start with jdbc: follwed by a driver identifier, such as in your case
odbc: for the JDBC-ODBC bridge driver.  The rest of the URL identifies the
db instance in a driver specific way.  For the JDBC-ODBC bridge it is a
ODBC Data Source Name (DSN).  For your Access db, you have to create a
System DSN using the ODBC control in Windows.  So call it "example" (this
is now your system DSN) and refer it to your db (C:\aFolder\databse.mdb).
Make sure you create a System DSN as opposed to a user DSN.
Your url will now look like "jdbc:odbc:example"

Hope this helps,
Brgds Herman
Signature

Suse Linux Professional 8.1 on Athlon 1.1 Ghz 512 Mb
Anti Spam = remove the "dot" and the "at"
Registered Linux User #264690

Soul - 27 Sep 2003 08:06 GMT
If I configure the System DSN in ODBC control in Windows, I can connect to
the database directly from class by:

   Class.forName( "sun.jdbc.odbc.JdbcOdbcDriver" );
   Connection con = DriverManager.getConnection( "jdbc:odbc:exampleDB" );

without adding datasource in Deploytool right?

But if I want to do something like:

   private String dbName = "java:comp/env/jdbc/exampleDB"
   InitialContext ic = new InitialContext();
   DataSource ds = (DataSource) ic.lookup( dbName );
   Connection con = ds.getConnection();

I will then have to add datasource in deploytool.

For some reason my course require us to use the second method, but I really
don't understand what are their differences since both of them need to
configure the System DSN, but the second method need extra work to add
datasource in deploytool.

Thank you.

Signature

Soul

| [Snipped]
|
[quoted text clipped - 11 lines]
| Hope this helps,
| Brgds Herman
Herman Timmermans - 27 Sep 2003 09:18 GMT
> If I configure the System DSN in ODBC control in Windows, I can connect to
> the database directly from class by:
[quoted text clipped - 19 lines]
>
> Thank you.

Hi Soul,
Let me try to explain.  The DataSource interface (javax.sql.DataSource) , is
part of the J2SE (Java 2 Standard Edition) 1.4 and prior to this version,
it was available through the JDBC 2.0 Optional Package. It is now part of
JDBC 3.0.  In order to access a database you need to establish a connection
and opening such a connection is very time- and resource consuming. The
nice thing about DataSource is that is can represent something called a
connection pool, this is a pool of connections that can be shared by
multiple clients.  Once a connection is opened, it stays open until the
application is shut down.  When your client application has a database
action that needs a connection, it can get it from the pool through the
DataSource object and uses it to execute one or more SQL statements.  When
the client closes the connection, it will be returned to the pool where it
can be picked up by the next action requiring a database connection.  
So to be brief, it is recommended for larger multi-user applications
(typically J2EE type of architecture) to use a DataSource object instead of
directly working with connection objects.
Brgds, Herman

Signature

Suse Linux Professional 8.1 on Athlon 1.1 Ghz 512 Mb
Anti Spam = remove the "dot" and the "at"
Registered Linux User #264690

Soul - 27 Sep 2003 10:15 GMT
I understand what you mean. Thank you very much for explaining. But just to
double conform, no matter what, configuration through ODBC control in
Windows is a must right?

Signature

Soul

| [Snipped]
|
[quoted text clipped - 16 lines]
| directly working with connection objects.
| Brgds, Herman
Herman Timmermans - 27 Sep 2003 10:30 GMT
> I understand what you mean. Thank you very much for explaining. But just
> to double conform, no matter what, configuration through ODBC control in
> Windows is a must right?

Soul,
yes, in case of MS Access you are right.  Of course, this is only used for
educational purpose.  In a real world application, you would run a solid
relational database like Oracle, IBM DB2, MS SQLserver, Sybase, Caché, or
some free one's like mySQL, SAP-DB, Firebird, Postgresql, .... and use
directly a suitable JDBC driver without using the JDBC-ODBC bridge, so
there wouldn't be any need for a System DNS.  OK?

Brgds, Herman
Signature

Suse Linux Professional 8.1 on Athlon 1.1 Ghz 512 Mb
Anti Spam = remove the "dot" and the "at"
Registered Linux User #264690



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.