Blog

Here's what we had to start with:

    1 [Inline:
    2     -Database    ='web_carts',
    3     -Table       ='web',
    4     'cust_id'    =$cust_id,
    5     'store_id'   =$store_id,
    6     'order_source' = 'Web Created',
    7     'ip_address' =(Client_IP),
    8     -Add]
    9     [Var: 'cart_temp-k-id' = (KeyField_Value)]
   10     [Var: 'cart_id' = (Integer: (Field: 'serial'))]
   11     [$cart_id->(SetFormat: -Padding=$ordernum_length, 
   12         -PadChar='0')]
   13     [Var: 'cart_id' = $ordernum_prefix+'-'+$cart_id+'-'+
   14         $ordernum_suffix]
   15 
   16 [/Inline]
   17 
   18 [Inline:
   19     -Database ='web_carts',
   20     -Table    ='web',
   21     -KeyValue =$cart_temp-k-id,
   22     'cart_id' =$cart_id,
   23     'status' = 'unchecked',
   24     -Update]
   25 [/Inline]
   26 
   27 [Var: 'cart_count' = 0]

Looks like there were some problems coming from this inline, specifically the client mentioned that this page in particular was the one creating the errors.  The error was that there was no session ID being passed to the FileMaker database when the add action was being performed.

Looking at the code, we had no logging or error reporting set up here.  Since the site was live I was reluctant to restart lasso in console mode because I didn't want the users to experience a problem with the site.  I looked into the lasso site admin and saw a lot of these errors:

FILEMAKER_PRO_CONNECTOR error 32 after send()

What was this?  Looks like it was time to add some debugging to the mix.  Although at the recent Lasso Conference in Chicago Ke Carlton showed us a new debug class for lasso called L-Deug I didn't have time to install it.

I quickly added some log_critical statements to the mix like this:

    1 [Inline:
    2     -Database    ='web_carts',
    3     -Table       ='web',
    4     'cust_id'    =$cust_id,
    5     'store_id'   =$store_id,
    6     'order_source' = 'Web Created',
    7     'ip_address' =(Client_IP),
    8     -Add]
    9 [log_critical:'first inline' + error_currenterror]
   10     [Var: 'cart_temp-k-id' = (KeyField_Value)]
   11     [log_critical:'cart_temp-k-id' + (KeyField_Value)]
   12     [Var: 'cart_id' = (Integer: (Field: 'serial'))]
   13     [$cart_id->(SetFormat: -Padding=$ordernum_length, 
   14         -PadChar='0')]
   15     [Var: 'cart_id' = $ordernum_prefix+'-'+$cart_id+'-'+
   16         $ordernum_suffix]
   17 
   18 [/Inline]
   19 
   20 [Inline:
   21     -Database ='web_carts',
   22     -Table    ='web',
   23     -keyfield = 'serial',
   24     -KeyValue =$cart_temp-k-id,
   25     'cart_id' =$cart_id,
   26     'status' = 'unchecked',
   27     -Update]
   28     [log_critical:'action inline' + 
   29         action_statement]
   30     [log_critical:'second inline' + error_currenterror 
   31         ', ' error_code]
   32 [/Inline]
   33 
   34 [Var: 'cart_count' = 0]

 also taking a minute to add in a quick -keyfield="serial", that I found.

Suddenly I was starting to get a lot more information.  Lasso was telling me that FileMaker was throwing a "record not found" error on the update action ( the add action was working fine) I looked up the error on Brian Dunning's FileMaker site.  The next step was outputting the action statement and I was seeing an unusually high number of the internal ID from recordID.

I knew something was up.

During this time I got on the phone with Kirk Bowman of MightyData, we have been working on a lot of projects lately and I knew he would know what the problem was.  Sure enough he did.

Turns out that client had been running a script using HackerSafe to pound their site at night and they were not letting the site determine between the HackerSafe bot and the regular users, HackerSafe had been incrementing the FileMaker records several thousand every night.  The high RecordID's we were seeing was indicative of this.

Having pinpointed the error Kirk took over from here. He had the client export the data then save a copy of the FileMaker  6 file as a clone, which resets the internal recordID and then reimport the data.  A calculation field was created real quick to check that the fix worked and the RecordID on the first record was 1.  Problem fixed.

We fired up the new file in FileMaker server 5.5, hooked up FileMaker Unlimited to it and restarted Lasso Service just to make sure.

The logs proved us out, no errors and the client reported the problem was taken care of.

So when you get this error:

FILEMAKER_PRO_CONNECTOR error 32 after send()

Check and make sure that your FileMaker database is not out of RecordIDs or has not wrapped and started reusing them.