Error: ‘jQuery.event.special[…].teardown’ is null or not an object

Apparently, when the page is left, jQuery tries to remove event listeners. When this happens, the jQuery.event.special[type].teardown is null or undefined in a line of the jQuery source. This appears to be a dialog error, or caused by the dialog somehow. The jQuery error is found on line 1948 using the latest release, 1.2.6. (For me this is line 1955 but my jQuery has been a little modified).

I added the following to the if on line 1948 – || !jQuery.event.special[type].teardown. This fixes the jQuery error on line 1948.

if ( !jQuery.event.special[type] || jQuery.event.special[type]
=== false ) {


if ( !jQuery.event.special[type] || !jQuery.event.special[type].teardown
|| jQuery.event.special[type] === false ) {

This makes it so if the teardown function is undefined, an error won’t occur.

I am fairly certain that this fix doesn’t break anything else, but no guarantees. I didn’t spend a lot of time going into what elem.removeEventListener or elem.detatchEvent does because it looks like the eventListeners are not very consequential. Maybe a little bit more overhead. All I know is when I added the extra if, things worked great from that point on. And what I call a jQuery error could very well be an IE error, a user error (me, of course), etc. I happen to love jQuery.

Coldfusion cfqueryparam of type decimal, cf_sql_decimal, requires the scale argument

I learned the hard way that if you don’t include the scale attribute in the cf_sql_decimal cfqueryparam tag, then your decimal gets rounded to the nearest whole number. IF this isn’t what is intended, this can really bite. Make sure you specify the scale with the scale argument to make you cfqueryparam as accurate as intended.

<cfqueryparam cfsqltype="cf_sql_decimal" scale="8" value="#decimalvar# />

WRONG (Unless whole numbers desired):

<cfqueryparam cfsqltype="cf_sql_decimal" value="#decimalvar# />

Export using Access into SQL Server or some other database

Summary – In Access, select your table and then do File->Export->ODBC Option (The last one)

I was missing the mysql table dumps that you can do from phpmysqladmin when my task at hand was to import an access table of postal codes (with their corresponding lat/long coordinates) into a SQL Server database. I decided to go nuts and attempt the task blitzkrieg style with no googling or research first. After only a minute or two looking at save and export options I found the following gem:

File->Export->ODBC Option (The last one)

If your access database is on the same machine as your SQL Server just blast through the ODBC setup menu choosing localhost, and then choose the default database as the database where you want the exported table to appear.

Or if you want to the exported table to appear in a remote sql server database (or any kind of ODBC compatible database I suppose), I think you can specify the ip or host name for that database. Then you choose a table name for your exported table and the thing will appear in your default database!

Fortunately, a few weeks ago I had needed to figure out how to set up an ODBC connection on a server box. Info: ODBC sources are like middlemen for apps to connect to a database. Set these guys up in Admin Tools->ODBC in windows if you are using about any language to access a database. So if the language requires a database connection and there aren’t any built in andd fast easy functions, you can set up connections using ODBC functions.