Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39B5F1B3.19580C3D@free.fr>
Date: Wed, 06 Sep 2000 09:26:43 +0200
From: Sylvain Wallez <wallez.anyware@free.fr>
Organization: Anyware Technologies
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: new sql logicsheet!
References: <Pine.LNX.4.21.0009060237580.987-100000@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Donald Ball a �crit :
> 
> On Tue, 5 Sep 2000, Per Kreipke wrote:
> 
> > > > This behaviour is allowed by JDBC. ResultSet javadoc states "For maximum
> > > > portability, ResultSet columns within each row should be read in
> > > > left-to-right order and each column should be read only once."
> > >
> > > Geez. Pardon my language, but that is simply ass.
> >
> > I love tech talk :) It's a shitty constraint but it might help speed up lots
> > of implementations, which JDBC needs as far as I can tell (or maybe it's the
> > JDBC-ODBC bridge that's slow).
> 
> note that the JDBC-ODBC bridge is terrible and is really not recommended
> for use in production environments - not only is it slow only implements
> JDBC minimally, it's known to have thread safety issues under certain
> circumstances. if you're stuck with access, i'm pretty sure there is a
> type 4 driver for access specifically (i could easily be wrong tho).
> access itself has been known to corrupt data when multiple processes are
> operating on the database simultaneously. my take - access is fine for
> rapid prototyping if you get off on that kind of thing but use a real
> database (mysql, postgresql, oracle, etc.) for storing real data.
> 
That's exactly how I discovered this "feature" of JDBC : prototyping
with Access an application that will run on Oracle.

> i think i'll probably simply stick to getString if the user wants me to
> cacheValues.
IMO, that's the most frequent case of column reuse within a row.

-Sylvain