I've been implementing an upgrade for a set of Access databases to replace the Access file database with MySQL linked by ODBC.  Everything seems to be going remarkably smoothly except for the common concept of inserting a record into a table with an auto-increment id column and retrieving the value of the id just created.  Of course on PHP or the like one would just use the

  SELECT LAST_INSERT_ID()

Function  to retrieve the ID. However the MySQL documentation itself says that this doesn't work for certain ODBC applications such as Delphi or Access and suggests using 

  SELECT * FROM tbl WHERE auto IS NULL;

Unfortunately this simply didn't work for me when called from inside the Access application I was working with, and there seems to be several comments around the web that indeed this is unreliable as Access may drop the data connection and reconnect behind the scenes - thus invalidating the call.

As an alternative I decided to use a MySQL function to add a blank record to the table, returning the id which Access would then use to update the record (which fits well with the code-style of the existing application).  Unfortunately this apparently straightforward work-around fails to be simple either as long-standing bugs in MySQL make finding valid code that can both send and return a variable something of a challenge.  Several examples on the web will work within the limited domain of using either just IN or OUT variables but fail to work with both.

My final solution, which works on the MySQL 5.1 and Access 2003 combination I am deploying, is as follows

MySQL procedure

DELIMITER $$

CREATE

    PROCEDURE `alicedata`.`sp_ins_identity`(IN tablename VARCHAR(50))

    BEGIN

    SET @result = 0;

    SET @sqlproc = CONCAT("INSERT INTO ",tablename," () VALUES ();");

    PREPARE s1 FROM @sqlproc;

    EXECUTE s1;

    DEALLOCATE PREPARE s1;

    SELECT LAST_INSERT_ID();

    END$$

This procedure is useful in that it will insert a row and return the id for any table where a row contains all null fields or non-null fields with defaults defined.

Public Function InsertMySQLIdentityRow(DSN As String, Tablename As String) As Integer

On Error GoTo Err_InsertMySQLIdentity



Dim cnnSQL As New ADODB.Connection

Dim cmdSQL As ADODB.Command

Dim pid As Integer

Dim rs

Dim strSQL As String



    ' initialize

    pid = 0



    ' set up ADO connection

    Set cnnSQL = New ADODB.Connection

    cnnSQL.Open DSN

    

    ' execute the procedure - note that assembling by parameter fails to handle IN or OUT correctly

    Set cmdSQL = New ADODB.Command

    cmdSQL.ActiveConnection = cnnSQL

    strSQL = "call sp_ins_identity('" & Tablename & "');"

    Set rs = CreateObject("ADODB.Recordset")

    Set rs = cnnSQL.Execute(strSQL)

    If Not rs.EOF Then

      pid = rs(0)

    End If

    

    ' clean up

    Set rs = Nothing

    Set cmdSQL = Nothing

    cnnSQL.Close

    Set cnnSQL = Nothing

   

Exit_InsertMySQLIdentity:

    InsertMySQLIdentityRow = pid

    Exit Function

Err_InsertMySQLIdentity:

    MsgBox Err.Number & Err.Description

    Resume Exit_InsertMySQLIdentity

End Function

This code is somewhat unusual in that normally, on MSSQL, you would use a parametrized  procedure call, but due to bugs in the MySQL ODBC (or at least incompatibilities with Access) the above seems to be the only way that allows both data to be passed and returned.

It's unusual to find Firefox (3.5) misbehaving - usually it's my default standards-compliant browser - but I recently posted a question to Stackoverflow as a direct result of Firefox behaving very strangely indeed.

I've been developing various bits of eyecandy for one of my clients who owns the Tartanweb website, one of which is a 3D model of a man in Highland Dress who can be interactively rotated and dressed in different tartans, jacket styles and so forth.  The applet was coded up using Wirefusion, and previously we've always displayed it in it's own browser window.

As part of developing a redesign of the site we decided to display the applet in a Lightbox type popup - actually using Kevin Millar's excellent Lightwindow implementation.  I used an embedded iframe for this, so the lightbox popup is displaying a simple web page which consists almost completely of an iframe, within which is the actual web page containing the Wirefusion applet.  So far so good, and the lightbox popped up, initialized and displayed the applet just fine in all versions of IE, Chrome and Safari.  Firefox however refused to work, giving me a javascript error whenever I tried to call any of the exposed functions

Error: document.appletname.send is not a function

Investigation by inserting diagnostic Javascript (being in an iframe it was difficult to get to the raw code generated directly and the page works just fine if not executed via the lightbox) revealed no oddities about the page - there was indeed just one embedded applet with the correct name, Firefox just couldn't see the exposed send function.

Closer investigation of the javascript generated by Wirefusion to load the applet (launcher.js) revealed that this functions by dynamically writing the applet code to the page on load, which suggests a timing bug.  Firefox also behaves strangely in that when the applet page loads the applet appears to initialize twice - a behaviour not seen with other browsers.  To fix this I amended the launcher code to encapsulate the javascript writing out the applet code in a function which returns the code in a string, and used this to set the innerHTML property of a dummy div called from the window.onLoad event.  Which worked - although only in Firefox.  To include IE and Safari I needed to add some browser detect code and write out the applet directly as before for these two.

So decidedly strange, although with the trail of main page -> lightbox -> iframe -> java applet perhaps understandable, it must be an unusual combination.  That it happens with Firefox only is the real surprise and I'll make a note to retest it on each significant Firefox update.