Why does this crash?

[jda]

>
>>  I'm doing a query where I create and then destroy a sortmethod
>>  on-the-fly. It worked before, but now crashes (V4RB, b11, OS X):
>>
>>       s = s + " ORDER BY authorEditorSortMethod,date" //create the query
>>
>>       fld =
>>  myDatabase.myReferences.createField("authorEditorSortMethod",
>>  kv_TypeVarChar, 504, "English", "if
>>                (length(authors)=0, if
>>  (length(editors)=0,title,editors),authors)") //create a method in
>>  case a field is
>>                 empty
>>
>>
>>     myCursor = myDatabase.SQLSelect(s, kServer, kReadOnly) //OK
>>
>>     if fld<> nil then
>>       myDatabase.myReferences.deleteField(fld) //destroy the
>>  temporary method -- crashes!
>>     end if
>>
>>  Obviously (?) Valentina has locked the new method. But why? Once the
>>  SQL query is done does the cursor have to know about the method used
>>  to sort the results?
>
>I think it crashes because you try delete field (BaseObject method) from
>table, while you still have cursor that use that field.
>
>I think it is obviously wrong idea.
>You need at first destroy cursor
>
>     myCursor = nil
>

I guess that makes sense, but it still doesn't work. I added this 
code at the *end* of dealing with myCursor:


   myCursor = nil
   if fld <> nil then
     myDatabase.myReferences.deleteField(fld) //destroy the temporary 
sort method AFTER myCursor is niled
   end if

and it still crashed. Here's the relevant portion of the crash log:

Thread 4 Crashed:
  #0   0x00e62204 in 0xe62204
  #1   0x00e7a000 in 0xe7a000
  #2   0x00e76c58 in 0xe76c58
  #3   0x00e70088 in 0xe70088
  #4   0x00e7a730 in 0xe7a730
  #5   0x00e76574 in 0xe76574
  #6   0x00e769b8 in 0xe769b8
  #7   0x00e76764 in 0xe76764
  #8   0x00ec7a88 in 0xec7a88
  #9   0x00e3fe78 in 0xe3fe78
  #10  0x00e75788 in 0xe75788
  #11  0x00e897d8 in 0xe897d8
  #12  0x00e08cec in 
BaseObject_DeleteField__FP16REALobjectStructP16REALobjectStruc
  #13  0x00233338 in 0x233338
  #14  0x006fc458 in 0x6fc458
  #15  0x00b1b66c in 0xb1b66c
  #16  0x9023b180 in CooperativeThread
  #17  0x90020d48 in _pthread_body