----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
> >Moral of the story? Don't bother with JDBC-ODBC and Access with JDK 1.2
>
> We created a small commercial application that used Access as the database.
> It has a low volume of data and few concurrent db connections. Added to ease
> of administration and low cost we chose Access. The application has not once
> crashed during production. It is running as a service on an NT box with
> JServ 1.0 on JDK 1.2.
That's interesting. My data volumes are medium sized, ~1Gb but my JVM
crashed
very early so I assumed the data size wasn't an issue.
o What SP are you using with NT 4?
o Have your tried your s/w on a multi-processor box?
o Were you using RMI in your servlets?
I did download and install the latest Microsoft Data Access upgrade
(mdac_typ.exe), the
result being little noticeable improvement in reliability.
Perhaps the introduction of RMI along with JDBC-ODBC prompts the
destabilisation in the JVM?
I'm interested in why you've experience none of the glitches posted on
both this mail list
and on the Sun bug parade.
> We used standard methodologies including connection pooling, prepared
> statements etc. We also used the standard SUN JDBC:ODBC bridge that comes
> with the JDK. We had full intentions of upgrading the bridge if it proved
> unstable. Despite SUN's disclaimers with the JDK documentation the bridge
> survived testing and has worked fine in production. In the right environment
> and conditions the SUN JDBC:ODBC bridge is fine for a commercial
> application.
I think the key problem here is determining "right environment and
conditions" isn't it?
Particularly since you've been the only person I've encountered with a
good story w.r.t. JDBC-ODBC and Access. You must have a golden touch ;-)
> Access's main limitation is the 27 concurrent connections, break that limit
> and it fails. You can hide that limitation to an extent to users via a
> connection pool. Access in the right environment and within the correct
> limits, is a viable choice as a low cost and easily managed db for a Servlet
> Application running on Win32.
Concurrency wasn't an issue with my s/w since it crashed the JVM with
only one connection to
the database. I tested the destabilisation on both a single processor
and dual processor box with
the same unstable results. Since my migration from Access to Interbase
fixed the problems I can
only conclude that either I have a weird set-up or you've been lucky ;-)
andy s.
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
