Если, как и я, вы разрабатывали и поддерживали решения FileMaker в течение многих лет, и даже если вы новичок в этой платформе, вы, несомненно, знаете, когда (а когда нет) вносить изменения в схему для приложений, используемых в рабочей среде. . При внесении этих изменений FileMaker заблокирует таблицу и предотвратит создание новых записей.

В недавней беседе мы с Дэнни Маком обсуждали, как поддерживать целостность данных для очень сложного приложения, в котором мы знали, что администраторы базы данных будут часто находиться в управлении базой данных. Большой вопрос заключался в том, как (или можем ли мы) защитить целостность данных при внесении изменений в схему? Более очевидный выбор — убедиться, что ваши скрипты проверяют и управляют любыми ошибками, с которыми они сталкиваются, включая ошибки, возникающие, если таблица заблокирована, но не все разработчики используют такой обширный перехват ошибок. По мере того, как наша дискуссия продолжалась, повторяющаяся тема была; «Можем ли мы что-то еще сделать в таких случаях?» Затем Дэнни поделился идеей, с которой его познакомил Кевин Франк, но я не слышал ее раньше; что фактор, способствующий блокировке таблицы FileMaker, связан с тем, как FileMaker управляет полями, которые автоматически вводят серийный номер. Это была новая идея для меня. Поля, для которых задан автоматический ввод серийных номеров, используются постоянно и по разным причинам. Мне было очень любопытно узнать больше.

Пост Кевина на эту тему читайте здесь: Живая разработка + «Новая запись».

Автоматический ввод серийного номера вместо получения (UUID)

Каждый раз, когда в FileMaker создается новая таблица, первым атрибутом, который я обычно создавал, было поле идентификатора с параметром автоматического ввода, установленным для ввода серийного номера. Этот идентификатор будет служить уникальным идентификатором записи.

FileMaker Pro 18 (и FileMaker Pro 17) автоматически создаст для вас поле первичного ключа с помощью функции Get (UUID) при создании новой таблицы.

Единственным исключением из этого правила было то, что данные в определенной таблице нужно было объединить или синхронизировать с зеркалом этой таблицы в другом файле. Например; отдел продаж, работающий на местах, и где каждый член команды собирает контактную информацию в локальной копии приложения в FileMaker Go. В таком случае серийного номера недостаточно в качестве уникального идентификатора, поскольку копия приложения каждого члена команды будет создавать записи с увеличивающимся номером. Когда данные объединяются в одну таблицу, записи теряют уникальность; представляет большую проблему.

FileMaker предоставил разработчикам еще один способ создания уникального идентификатора, который решил эти проблемы, когда они представили функцию Get (UUID) в FileMaker Pro 12 и Get (UUIDNumber) в FileMaker Pro 17.

Функция Get (UUID) и функции Get (UUIDNumber) возвращают универсальный уникальный идентификатор (UUID), который решает проблему уникальности.

Пожалуй, я остановлюсь здесь ненадолго. Я использовал пример с первичным ключом, потому что это одно из наиболее распространенных применений автоматического ввода серийного номера, но это не единственное использование в любом случае. Поля с автоматическим вводом серийного номера постоянно используются по разным причинам (номера счетов, номера деталей, номера чеков и т. д. и т. д.). Настроить поле для управления этими вещами настолько просто, что большинство разработчиков даже не задумываются об этом.

Блокировка таблицы

Я думаю, что стоит уделить немного времени обзору того, что происходит, когда таблица блокируется FileMaker, и, возможно, лучше всего начать с того, чтобы узнать, какие конкретные действия блокируют таблицу. Следующие действия заблокируют таблицу в FileMaker:

  1. Создание нового поля
  2. Дублирование поля
  3. Изменение параметров поля
  4. Изменение формулы поля вычисления

Это действительно важно; когда таблица заблокирована, ни пользователь, ни сценарий не могут создавать новые записи в заблокированной таблице. Если пользователь попытается создать новую запись вручную, в то время как разработчик базы данных выполняет одно из вышеуказанных действий, FileMaker отобразит диалоговое окно, предупреждающее пользователя о возникновении ошибки.

Это произойдет, если, скажем, пользователь нажмет кнопку «Новая запись» в области состояния, но что произойдет, если запись будет создана во время процесса по сценарию? И чтобы еще больше усложнить ситуацию, что, если разработчик добавил шаг сценария Set Error Capture [On]? В зависимости от того, где добавлен шаг Set Error Capture, FileMaker может не отображать диалоговое окно. Это действительно важно, и здесь могут возникнуть проблемы с целостностью данных. Несмотря на то, что записи не могут быть созданы, пока блокировка не будет снята, существующие записи все же могут быть обновлены. Очень распространенной практикой является использование шага «Установить поле» (или нескольких шагов «Установить поле») сразу после шага сценария «Новая запись/запрос» для установки значений в различные поля в новой записи. Однако, если таблица заблокирована и для такого случая нет обработки ошибок, сценарий может обновить неправильную запись, и пользователь никогда не узнает об этом. И действительно, это такие типы ошибок, которые могут очень долго оставаться скрытыми, если вообще известны. Это никогда не бывает хорошо с любыми данными, но подумайте о том, что в этом случае финансовые данные будут перезаписаны. Потенциально это может привести к плачевным последствиям. Возможно, я воспользуюсь моментом и просто опубликую дружескую социальную рекламу. Вы всегда должны ловить ошибки и управлять ими. Вы также должны использовать шаг Set Error Capture с осторожностью и намеренно. Было бы ошибкой просто добавить этот шаг в начало вашего скрипта, если только это не требуется для того, для чего вы программируете.

Как только FileMaker заблокирует таблицу, эта блокировка останется в силе, пока диалоговое окно «Управление базой данных» не будет закрыто и изменения не будут зафиксированы или отменены.

Тестирование теорий

Я решил, что следующее, что мне нужно, — это провести небольшое тестирование, чтобы увидеть, как таблица с сериализованными полями будет обрабатывать блокировку таблицы по сравнению с таблицей без сериализованных полей. Я создал простой файл с двумя таблицами. В одной таблице поле идентификатора было настроено на автоматический ввод серийного номера, а в другой таблице поле идентификатора было настроено на автоматический ввод уникального идентификатора с помощью функции «Получить» (UUID). В обеих таблицах также были служебные поля для отслеживания того, кто создал и изменил запись, пара текстовых полей для имени и фамилии и простое поле для вычисления, объединяющее имена. Я разместил этот файл на сервере FileMaker.

После размещения файла пришло время протестировать и понаблюдать. Я открыл размещенный файл в двух разных копиях FileMaker Pro Advanced. В одном экземпляре я открыл диалоговое окно «Управление базой данных» для таблицы с полем автоматического ввода серийного номера. Затем я открыл поле расчета, как будто собирался изменить формулу, и просто оставил ее там. В другой копии я перешел к макету на основе таблицы с серийным полем и попытался отредактировать значение поля в текстовом поле. Как и ожидалось, это не удалось, и FileMaker выдал мне диалоговое окно с предупреждением, показанное выше. Как только я закрыл диалоговое окно «Управление базой данных», я снова смог внести изменения.

На следующем проходе в одной копии я открыл диалоговое окно «Управление базой данных» для таблицы без автоматического ввода серийного номера и сделал то же самое. Я открыл поле расчета и начал его модифицировать. Затем я открыл другую копию и перешел к макету на основе таблицы без серийного поля и попытался отредактировать значение поля в текстовом поле. На этот раз ошибки не было. Я смог изменить запись и сохранить изменения. Нет проблем.

Я нахожу это действительно интересным. Означает ли это, что я просто никогда не должен использовать автоматический ввод серийных значений? Я так не думаю. Я действительно думаю, что это то, что нужно учитывать в зависимости от того, что вы разрабатываете. Я уверен, что есть некоторые умные люди, работающие с FileMaker, которые могут ответить на вопрос о том, почему FileMaker работает именно так. Я постараюсь найти время с инженером FileMaker на DevCon в этом году и посмотреть, смогу ли я пролить свет на это. Итак, следите за обновлениями. Я, пожалуй, последую за этим.

Альтернативная стратегия

Тем временем, предполагая, что вы хотите изучить стратегию, позволяющую избежать добавления серийных значений с автоматическим вводом, вы можете создать служебную таблицу, содержащую одну запись с полем для каждого поля с автоматическим вводом, которое вам требуется (или хранить запись для каждого необходимого сериализованного поля). Затем вы можете выбрать любое значение для начала, и вы будете управлять значениями в этой таблице и полях с помощью сценария. Это означает, что вам нужно либо предоставить настраиваемый интерфейс с кнопкой для новой записи, либо использовать настраиваемые меню (мое предпочтение). Например, решение для выставления счетов может иметь скрипт New Invoice, подобный этому.

Как показано в строке 7 в приведенном выше сценарии, сценарий «Новый счет-фактура» вызовет показанный здесь сценарий «Получить серийное значение и обновить».

Как и в случае любого скриптового процесса, существуют соображения. Например, вполне вероятно, что нескольким пользователям может понадобиться серийное значение одновременно, что может создать проблему блокировки записи и не позволит правильно управлять серийными значениями. Чтобы справиться с этим, я поместил сбор необходимого значения (и обновление поля для выдачи следующего значения) в Цикл, который просто проверяет наличие ошибок. Как только процесс сможет собрать и установить то, что необходимо, без ошибок, сценарий зафиксирует эти изменения и передаст необходимое значение обратно вызывающему сценарию.

Резюме

Я всегда немного осторожен, говоря, что любой конкретный способ сделать что-то является «правильным». Как и в случае любых усилий по разработке, при выборе подхода необходимо учитывать множество факторов. В зависимости от приложения, которое вы создаете, могут быть случаи, когда лучше не использовать сериализованные поля в пользу Get (UUID) и управлять необходимыми серийными значениями с помощью сценария и служебной таблицы, как показано. Независимо от того, какой подход вы используете, вы всегда должны отслеживать ошибки и управлять ими, чтобы гарантировать, что целостность ваших данных не будет нарушена; либо из-за сбоя пользовательского процесса, либо из-за администраторов базы данных, которым необходимо быстро вносить изменения, изменяя схему в живых файлах.

Первоначально опубликовано на https://www.codence.com 16 июля 2019 г.