Unfortunantly I only have the microsoft one.. I had heard jTDS was better, and faster, but have never found the evidence to back up that rumor..
Eric > -----Original Message----- > From: Sandeep Dath [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 5:53 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Hibernate] Problem with Hibernate and MSSQL JDBC diver > when Rereading columns > > > Eric, > > Have you tried using the jTDS driver? If so, what were your > results? I > believe jTDS passed all the Hibernate tests? (Is that a true > statement?) > > Sandeep > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Pugh > Sent: Thursday, October 16, 2003 10:47 AM > To: [EMAIL PROTECTED] > Subject: RE: [Hibernate] Problem with Hibernate and MSSQL > JDBC diver when > Rereading columns > > > I have a unit test demonstrating this issue. I would like to > commit it in > test/mssql directory. I also want to commit a couple other > unit tests that > demonstate limitations with MSSQL and hibernate. For > instance, the standard > tests fail due to some timestamp issues, but it would be nice to show > complimentary MSSQL tests passing.. Maybe tune the unit > tests to take into > account the database platform, although this does mean > pandering to each > jdbc driver! > > I think the fix for my issue is to read all the rows only > once, which looks > like it is doable.. Eric > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > Behalf Of Eric > > Pugh > > Sent: Thursday, October 16, 2003 3:29 PM > > To: [EMAIL PROTECTED] > > Subject: [Hibernate] Problem with Hibernate and MSSQL JDBC > diver when > > Rereading columns > > > > > > We have a problem with the Microsoft JDBC driver throwing a > "can not > > reread column" exception. We have discovered that it only appears > > if the resultset > > contains a NTEXT, TEXT or IMAGE column. The driver then imposes the > > limitation that columns must be read increasing column > > indexes and that they > > may not be re-read. This limitation is permitted by the > JDBC spec: See > > <http://java.sun.com/products/jdk/1.4.1/docs/guide/jdbc/spec/j > > dbc-spec.frame > > 7> .html#4149 "For maximum portability, columns within a row > > should be read > > in left-to-right order, and each column should only be read > once. This > > reflects implementation limitations in some underlying database > > protocols. > > > > I would like to commit to the /test directory some unit tests > > demonstrating this problem. I believe it can be fixed by just > > enforinc the left-to-right > > order, by reading columns by index versus by name. I wrote a > > unit test that > > only runs if the Dialect is Sybase. However, should we > > create a subclass of > > SybaseDialect that is MSSQLDialect so that the test case will > > only run with > > MSSQLServer versus Sybase. > > > > Any objection to committing the unit tests? Even if we don't solve > > the problem, it can serve to Prove the problem exists.. > > > > Eric > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Gavin > > > King > > > Sent: Thursday, October 16, 2003 11:41 AM > > > To: Neill Robbins > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: [Hibernate] Hibernate issue found on > > > [Springframework-developer] - Hibernate commit/rollback > > > > > > > > > This is correct behaviour. If the commit() fails, you are > > supposed to > > > call rollback(), as described in the Hibernate doco. > > > > > > Neill Robbins wrote: > > > > > > >Sirs, > > > > > > > >I noticed this post on the Spring developer ist. It seemed > > > important enough to make you guys aware of... > > > > > > > >Regards, > > > >N > > > > > > > > > > > >-----Original Message----- > > > >From: jürgen höller [werk3AT] > [mailto:[EMAIL PROTECTED] > > > >Sent: 16 October 2003 05:53 > > > >To: [EMAIL PROTECTED] > > > >Cc: [EMAIL PROTECTED] > > > >Subject: Re: [Springframework-developer] Hibernate > commit/rollback > > > >Importance: Low > > > > > > > > > > > >You're right, of course, but there's a general issue. I've > > > checked the implementation of Hibernate's > JDBCTransaction: It really > > > behaves the way I've outlined, i.e. if there's a flushing > failure on > > > commit, the commit call returns without having rolled back the > > > database transaction. We need to make sure that the database > > > transaction is completed, i.e. either committed or rolled back, > > > after the transaction manager has finished its work. > > > > > > > >Juergen > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > Gesendet: Do 16.10.2003 02:34 > > > > An: jürgen höller [werk3AT] > > > > Cc: [EMAIL PROTECTED] > > > > Betreff: Re: [Springframework-developer] Hibernate > > > commit/rollback > > > > > > > > > > > > > > > > Juergen, > > > > > > > > The log shows that it is a MySQL database - do we know > > > that the table is one > > > > that support transactions? If not then no matter what > > > we or hibernate do is > > > > going to help. > > > > > > > > Thomas > > > > > > > > > There's a bug entry on SourceForge regarding > > > HibernateTransactionManager's > > > > > committing: > > > > > > > > > > If the flushing of changes is delayed (i.e. > > > HibernateTemplate is in > > > > > FLUSH_AUTO mode, not in FLUSH_EAGER), the Hibernate > > > commit call will first > > > > > implictly cause a flush. The problem is that that > > > flush might throw an > > > > > exception which causes Hibernate's commit > > > implementation to return with the > > > > > exception, without a commit but unfortunately also > > > without a rollback. > > > > > > > > > > The current implementation of > > > HibernateTransactionManager will not cause an > > > > > explicit rollback in that case, as it assumes that > > > the commit has failed and > > > > > caused an implicit rollback. It takes that assumption > > > from JTA: After a > > > > > failed commit, you don't have to invoke rollback > > > anymore; the failed commit > > > > > has already completed the transaction with a rollback. > > > > > > > > > > If I understand correctly, a JDBC driver should > > > behave the same: If a commit > > > > > has failed, rollback does not have to be invoked > > > anymore. Would it actually > > > > > hurt if one still invoked rollback? Would that get > > > ignored with most drivers, > > > > > or would it cause yet another exception, a la > > > "transaction is already rolled > > > > > back" or "no transaction anymore"? > > > > > > > > > > I intend to fix the Hibernate transaction issue like > > > this: First invoke flush > > > > > manually and treat it like data access, i.e. just > > > commit if it succeeded, > > > > > else cause an explicit rollback. Aren't the semantics > > > of Hibernate's commit > > > > > method a bit odd? Shouldn't it cause a rollback > > > itself if the flush failed? > > > > > > > > > > I'm not sure about JDO in that respect. It will also > > > flush changes at commit, > > > > > and there is no chance to cause an explicit flush > > > before. The spec and the > > > > > javadocs are unclear about whether a flushing failure > > > causes a rollback of > > > > > the datastore transaction, but I assume so. At least, > > > it seems that rollback > > > > > can and should not be invoked after an exception on commit. > > > > > > > > > > Has anyone practical experience with these issues? > > > > > > > > > > Juergen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------- > > > >This SF.net email is sponsored by: SF.net Giveback Program. > > > >SourceForge.net hosts over 70,000 Open Source Projects. See the > > > >people who have HELPED US provide better services: Click here: > > > >http://sourceforge.net/supporters.php > > > >_______________________________________________ > > > >hibernate-devel mailing list > [EMAIL PROTECTED] > > > >https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: SF.net Giveback Program. > > > SourceForge.net hosts over 70,000 Open Source Projects. See the > > > people who have HELPED US provide better services: Click here: > > > http://sourceforge.net/supporters.php > > > _______________________________________________ > > > hibernate-devel mailing list [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > SourceForge.net hosts over 70,000 Open Source Projects. See > the people > > who have HELPED US provide better services: Click here: > > http://sourceforge.net/supporters.php > > _______________________________________________ > > hibernate-devel mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net > hosts over 70,000 Open Source Projects. See the people who > have HELPED US > provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
