TL;DR: Legacy scripts and calculations which depend on values in container fields may break when those fields are converted to external storage.
A rare circumstance, but worth filing away, maybe it'll help someone with future troubleshooting: I was working on a legacy database yesterday, converting the numerous container fields to external storage to slim down the database file. Today I got a call from the users that a simple feature, which allowed the users to toggle a flag field on a record by clicking a graphical button which displayed an "X" or check mark image, didn't work anymore. Well, it turned out the previous developer did something very... er... unusual. The button which the user clicked was actually a container field, ButtonImage_r. The way he tracked the status of the record was by checking what image was in ButtonImage_r as follows. At program open, a global container field with 2 repetitions, g_buttonImages_r, was populated with an "X" image and a checkmark image respectively. Then, when the button was clicked, the script did this: If [ ButtonImage_r = GetRepetition(g_buttonImages_r,1) ] Set Field [ ButtonImage_r, GetRepetition(g_buttonImages_r,2) ] Else If [ ButtonImage_r = GetRepetition(g_buttonImages_r,2) ] Set Field [ ButtonImage_r, GetRepetition(g_buttonImages_r,1) ] End If Similarly, there was a calculated field that displayed either "successful" or "unsuccessful" depending on whether the image in ButtonImage_r matched either repetition of g_buttonImages. This worked fine for a long time, until yesterday, when I set ButtonImage_r to external storage, and the whole thing stopped working. Neither "Else If" would match, and nothing happened. Resetting ButtonImage_r to be stored internally solved the problem immediately. So, although I've never before seen a calculation that depended on the data in a container field, should you run across one, FileMaker does not consider internal and external storage to be precisely equal for that purpose. Sometimes I love looking through these legacy databases created by my clients' inventive, creative staff members. It's an amusing reminder of the old adage that "a little knowledge is a dangerous thing."