Comments for I'd rather play golf

Comment on SQL Anywhere 11 Hibernate dialect by Glenn Paulley

Glenn Paulley — Mon, 02 Nov 2009 16:05:27 +0000

Not directly, no. The Hibernate dialects I wrote assume at least version 10 support for intent locks (ie, SELECT .... FOR UPDATE BY LOCK). To use with Version 9, one would have to edit the dialect to support the different Hibernate lockmodes with isolation level 3 locking using table hints.

Comment on SQL Anywhere 11 Hibernate dialect by Dmitry

Dmitry — Mon, 02 Nov 2009 15:56:06 +0000

As i understand, SA 9.0.2 Build #3025 also support addBatch()? Can i use this dialect for ASA9 with new jdbc drivers?

Comment on Cross and outer apply by Wing

Wing — Thu, 29 Oct 2009 17:49:31 +0000

IMO, CROSS APPLY and OUTER APPLY syntax is more intuitive than LATERAL syntax.

Comment on Disk failures in the real world by Glenn Paulley

Glenn Paulley — Tue, 27 Oct 2009 12:40:07 +0000

If you turn on checksums with dbinit -s, then the server will detect corruption upon reading any database page.

If checksums are not enabled, then the server is unable to detect data corruption caused by bit-flipping on the media that goes undetected by the filesystem. In SQL Anywhere 11, checksums are always enabled for some specific metadata pages, whether or not dbinit -s is used. However, invalid data on “ordinary” pages will not get detected by dbvalid unless the altered value is something specifically checked by dbvalid (such as a foreign key value).

Because of the rather poor failure experience we have seen on consumer-grade flash media – compact flash (CF) and SD cards – we strongly recommend that dbinit -s be used when deploying any database file to a Windows Mobile device.

Comment on Disk failures in the real world by Breck Carter

Breck Carter — Tue, 27 Oct 2009 10:46:54 +0000

If I turn on page checksum checking in SQL Anywhere (dbinit -s) am I guaranteed that data corruption will be detected as soon as a corrupted page is read? And that a dbvalid run offers the same guarantee, even if dbinit -s was not specified?

Comment on It’s 11 o’clock – do you know where your data is? by Disk failures in the real world

Disk failures in the real world — Tue, 27 Oct 2009 01:49:57 +0000

[...] Hu [3] believe that the trend towards lower-cost magnetic media results in higher failure rates, a conclusion also reached [7] by Remzi Arpaci-Dusseau and his team at the University of Wisconsin in Madison. To some extent, at least, you do get what [...]

Comment on Differences between jConnect and the iAnywhere JDBC driver – part trois by Glenn Paulley

Glenn Paulley — Fri, 23 Oct 2009 23:02:24 +0000

Hi David, thanks for your question.

The new JDBC driver sajdbc.jar that ships with newer EBFs of Version 11.0.1 – and which will ship as sajdbc4.jar in Version 12, as it offers JDBC 4.0 support – is a Type 2 driver, not a Type 4. I realize that this new driver isn’t the Type 4 driver that some of your development team are asking for, but we think the advantages of the Type 2 driver are considerable, and it’s ease of deployment and JDBC 4.0 support (in Version 12) are quite compelling features over what our existing Type 1 driver supports.

Jason Hinsperger has already posted a summary of the deployment procedure for the new sajdbc.jar driver in existing 11.0.1 installations here. If this is insufficient detail please let me know.

Comment on Differences between jConnect and the iAnywhere JDBC driver – part trois by David Winkler

David Winkler — Fri, 23 Oct 2009 22:13:20 +0000

Glenn, I’ve had robust discussions within my development team regarding the benefits of utilizing the iAnywhere driver with our Java app deployed on a Linux platform, but the developers are not keen to using a driver which is not a pure, type 4 driver. Will the JDBC 4.0 driver in SQL Anywhere 12 also be a type 4, pure Java driver, not jConnect (thus not TDS)? The app in question inserts over 40,000,000 rows/day in 5,000 row batches into a SQL Anywhere 11 DB and, in this instance, I enjoy between a 6-8x performance increase (with much less network traffic as well) using the iAnywhere driver. Also, could you please post a walk-through to configuring and using the new sajdbc.jar without having to configure ODBC on a Linux platform?

Comment on Using RowGenerator by Using RowGenerator - part deux

Using RowGenerator - part deux — Fri, 16 Oct 2009 22:56:05 +0000

[...] posting my recent article on the use of the RowGenerator system table, I received a welcome email from [...]

Comment on Mechanics of options in SQL Anywhere by Glenn Paulley

Glenn Paulley — Fri, 16 Oct 2009 19:00:37 +0000

Database and connection options can be set only using the SET OPTION statement, and so cannot be set in an ODBC DSN.

However, what you could do is establish a login procedure so that, upon connection, the login procedure would issue the appropriate statements to set the specific options for that connection. You probably want to use the SET TEMPORARY OPTION statement so that the setting is modified only for the specific connection, rather than for all new connections for that user.