R: Query performs differently in SQL Query Analyzer [SOLVED]

The Microsoft JDBC driver for SQLServer is ***very*** buggy.   We've got a better experience using jTDS in our projects, too.   Fabrizio Da: Clinton Begin [mailto:[EMAIL PROTECTED] Inviato: mercoledì 25 maggio 2005 6.29A: ibatis-user-java@incubator.apache.orgOggetto: Re: Query performs di

R: [New Feature] SQL Map Interface Binding -for your review

I think this is a very **cool** new feature, but I would vote for it only if it's use is optional, or completely automated.   One of the reasons I like iBATIS is its simplicity; this solution complicates a bit the overall design, and it's a bit more hard to understand for a newbie. As Aitor

R: sqlmapclients

per client will this not be slow. And is there a limit.. Steve.. -Original Message- From: Fabrizio Gianneschi [mailto:[EMAIL PROTECTED] Sent: Fri 5/20/2005 12:00 PM To: ibatis-user-java@incubator.apache.org Subject: R: sqlmapclients Since each SqlMapClient instance is related to a sing

R: sqlmapclients

Since each SqlMapClient instance is related to a single database, but can support many client requests (see cfg file), I think you'd not have to provide an instance for each client, until they use the same db. Fabrizio -Messaggio originale- Da: James, Steven [mailto:[EMAIL PROTECTED] Inv

R: A really bad N+1 solution

That's nothing ridicule in solving a problem, Mark.   That's why we're payed for. :) Da: Mark Bennett [mailto:[EMAIL PROTECTED] Inviato: giovedì 19 maggio 2005 20.28A: ibatis-user-java@incubator.apache.orgOggetto: A really bad N+1 solution For your enjoyment here is how I solved the N+1 p

R: Please Help in arguing for iBatis SqlMaps

Kaushik Ashodiya wrote: >Please give me more reasons so that I can convince them. > >Their argument: >1. For small project SqlMap is adding unnecessary complexity. I evaluated iBATIS expecially on small-medium projects. It reduces the "ordinary-JDBC" Java code by ~62% http://www.jugsardegna.org/v

R: R: PaginatedList & 'google like' results

com.ibatis.common.util.PaginatedList. > > My ListWrapper implements java.util.List and contains: > - isFirstPage/isLastPage/isMiddlePage, getPageIndex, getPageSize > methods, so my JSP is 'compatible' with the previous aproach using > PaginatedList. > - getRowCount, getPa

R: Multiple Data Sources

I think you should configure (and use) two separate SqlMap instances, with their own xml configuration files. Fabrizio -Messaggio originale- Da: Rafiq, Adnan [mailto:[EMAIL PROTECTED] Inviato: venerdì 18 marzo 2005 17.58 A: 'ibatis-user-java@incubator.apache.org' Oggetto: Multiple Data So

R: PaginatedList & 'google like' results

I'm used to execute two queries (count + select) for each stament in this kind of situations. The code is hidden in the DAOs, so the business/web layers are not aware of the strategy. The following is the generic method I use: private List executePagedQuery(Object params, int offset,

R: How many field can insert

The limit is imposed by the database or the JDBC driver, on the length of the entire query string. I remember an old query on SQLServer that didn't work due a big dynamic SQL IN clause. F -Messaggio originale- Da: Larry Meadors [mailto:[EMAIL PROTECTED] Inviato: giovedi 17 febbraio 2005 1

R: Dao unit testing?

I worked on dbUnit about two years ago, on a project where we evaluated a whole Agile stack (junit, canoo, dbunit, cruise control...), so my opinion reflects the state of the art on these days. I appreciated the overall philosophy and the theory of "4 databases" behind it. I remember that we had a

R: What is N+1

The reason is explained well in the SQLMaps documentation: "Lazy Loading vs. Joins (1:1) It’s important to note that using a join is not always better. If you are in a situation where it is rare to access the related object [-the Child-] then it might actually be faster to avoid the join and the u

R: New article in ONJava.com

It's time for a book, now!   ;)   Fab -Messaggio originale-Da: Michael Klaene [mailto:[EMAIL PROTECTED]Inviato: giovedì 3 febbraio 2005 19.29A: ibatis-user-java@incubator.apache.org; [EMAIL PROTECTED]Oggetto: Re: New article in ONJava.com Funny, I didn't realize I was th

Feedback

that work on this great project. Fabrizio Gianneschi Italy

R: R: How to reuse a query?

it... Regards, Fabrizio On Mon, 20 Dec 2004 16:06:51 +0100, Fabrizio Gianneschi <[EMAIL PROTECTED]> wrote: > Regarding the SQL COUNT problem, I think the following could be an > enhancement for a new iBATIS release... > > -create a new queryForPaginatedList method that receiv

R: How to reuse a query?

pager tags (in the JSPs) could know how many objects they've to expect at maximum. I'd like to know your opinion... actually we're forced to do workarounds to solve the PaginatedList count problem. Regards, Fabrizio Gianneschi -Messaggio originale- Da: Brandon Goodin [mailto

R: How to reuse a query?

Thanks a lot Brandon and Philippe, your help was very useful: exactly what I was looking for. Fabrizio -Messaggio originale- Da: Brandon Goodin [mailto:[EMAIL PROTECTED] Inviato: venerdi 17 dicembre 2004 21.21 A: Fabrizio Gianneschi Cc: iBATIS mailing list Oggetto: Re: How to reuse a

How to reuse a query?

Hello, first of all, hello everybody since I'm new on this list even I'm using iBATIS sice a couple of months. I'm looking for a smart trick to avoid duplicating the sql statements when using SELECT COUNT. For paginating needs, I've to execute two separate statements, the first one to count the

test

test