On Jun 7, 2:27 pm, Jeremy Evans <[email protected]> wrote: > On Jun 2, 4:10 pm, Jeremy Evans <[email protected]> wrote: > > > On Jun 2, 3:12 pm, Wei <[email protected]> wrote: > > > > Thanks for the quick response. > > > We are on the same page. I understand how cps.setNull() is chosen. > > > > So how comfortable are you to make this change? :) > > > I'll give it a few days here to see if anyone here objects, but if > > not, it can go in. If there are problems with it on other databases, > > it's easy to revert the commit and make the changes to just the > > sqlserver jdbc subadapter. > > Nobody's objected to this, so it can go in. However, can you let me > know if the following works: > > cps.setNull(i, nil) > > I'm not sure if the problem is in setNull vs. setString, or nil vs. > JavaSQL::Types::NULL, or both. I'm guessing it's with nil vs. > JavaSQL::Types::NULL, though, and I'd prefer using setNull instead of > setString as it sounds more accurate. But if someone actually has > experience with JDBC in this area and can give me a definitive answer, > I'd be grateful.
I just pushed a couple commits that switch to using setString(i, nil) by default, but using setNull(i, JavaSQL::Types::NULL) on PostgreSQL, since if you use setString(i, nil) for an integer field PostgreSQL gives you an exception. It's possible other JDBC adapters require the same check. I tested sqlserver, jtds, postgresql, mysql, and h2 and nil is apparently handled correctly on all of those (for prepared statements, which use the same set_ps_arg method as stored procedures). Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
