I agree. The Microsoft JDBC driver was purchased by Microsoft from some other company and is definitly not the best. Do you have links to anything that compares the performance etc of the two drivers?
Eric > -----Original Message----- > From: Sandeep Dath [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 6:21 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Hibernate] Problem with Hibernate and MSSQL JDBC diver > when Rereading columns > > > Rumors apart, I believe jTDS has very recently moved (in the Hibernate > context) from just another driver to an officially supported > driver. At > least that is what I can make out from the supported > databases (and drivers) > page. > > From my point of view, that's saying a lot. My reading of Microsoft's > handling of their JDBC offering is: Let's put in some effort putting a > driver out there that can "get by", thereby not shutting out > the Java crowd. > > Which is a problematic stand. > > Sandeep > > -----Original Message----- > From: Eric Pugh [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 11:06 AM > To: 'Sandeep Dath'; [EMAIL PROTECTED] > Subject: RE: [Hibernate] Problem with Hibernate and MSSQL > JDBC diver when > Rereading columns > > > 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
