Установки сервера

• Начальная страница
• Общая информация о сервере базы данных

Сервер хранит настройки в нескольких файлах инициализации, основной из которых по умолчанию называется sfsrv.ini (однако с помощью ключей запуска из командной строки, можно использовать другой файл для загрузки основных настроек). Обычно файлы настроек являются текстовыми файлами в форматах ANSI или UTF-16. Для формата UTF-16 в файле всегда должен присутствовать соответствующий BOM. Файл инициализации имеет структуру дерева и делится на ветки и переменные. Каждая ветка содержит полный путь и записывается в квадратных скобках (см. пример ниже). Каждая переменная записывается в виде <ИмяПеременной>="<Значение переменной>". При этом кавычки разрешается опускать. Файлы могут содержать комментарии. Комментарием является строка, начинающаяся на знак ; (точка с запятой). Многие файлы создаются и обновляются автоматически, поэтому, комментарии, введенные вручную, могут быть утеряны. Также нужно понимать, что изменения в файлах инициализации, обычно не становятся рабочими до остановки и запуска сервера (при остановке сервера все пользователи, имеющие соединение с ним в данный момент, форсированно завершат работу и все их несохраненные данные будут утеряны). Пример обычного файла инициализации:

;Начало ветки Common
[Common]

;Переменные ветки Common
LogType="0"
Path="c:\files\data\"

;Начало ветки Common\Comm
[Common\Comm]

;Переменные ветки Common\Comm
ExecutablePathAndCmdLine="c:\files\data\file.exe "arg 1" "arg 2" 2"
DllPath="c:\files\data\file.dll"

;Начало ветки Update
[Update]
...

Ниже дана информация по всем файлам, связанным с изменением свойств работы сервера:

Основной файл настроек sfsrv.ini

Файл обычно хранится в бинарном каталоге сервера, и содержит основные настройки сервера, путь к файлам проекта, путь к библиотеке базы данных, а также настройки базы данных, которыми пользуется эта библиотека. Если в командной строке не указано иного, сервер загружает файл sfsrv.ini по умолчанию. Файл представляется собой текстовый файл инициализации в формате ANSI или UTF-16. В случае UTF-16, в файле должен присутствовать заголовок BOM. Ниже дается список веток и переменных, которые используются сервером в файле. Если ветка или переменная необходимы, они помечены как таковые, большинство же веток и переменных можно опустить. При установке системы с помощью программы-установщика в файле инициализации сервера могут присутствовать не все ветки и переменные, описанные ниже.

• Ветка Common хранит общие установки сервера.
  • Переменная ServiceName указывает на имя сервиса, используемое данной копией программы сервера. По умолчанию это имя "sfsrv". В случае, когда на одной машине используется более одного сервера базы данных, до регистрации сервиса в системе, необходимо указать другое имя сервиса, так как в системе не может существовать более одного сервиса с одним и тем же именем. Регистрацию и удаление сервиса можно произвести непосредственно из командной строки, нет необходимости использовать программы-установщики. К примеру, чтобы изменить имя сервиса текущей базы данных с sfsrv на sfsrv2, нужно остановить сервер sfsrv.exe stop, отменить регистрацию сервиса sfsrv.exe deinstall, изменить значение этой переменной на sfsrv2 (или добавить переменную, если ее не существовало), зарегистрировать сервис снова sfsrv.exe install и запустить его sfsrv.exe start. Для дополнительной информации, см. статью Ключи запуска сервера из командной строки.
  • Переменная Loglevel задает то, насколько подробной будет информация в логах сервера (обычно это файл sfsrv.log). Значением переменной может быть число от 0 до 2, при этом при 0 логи записываться не будут, 2 в логах будет вестись максимально подробная информация. По умолчанию значение этой переменной равно 1.
  • Переменная LogFile задает имя файла для ведения логов сервером. По умолчанию это sfsrv.log, располагающийся в папке исполняемого файла сервера.
  • Переменная UpdateCataloguesRescanPeriod задает время сканирования каталогов обновлений клиентов _DeploymentBin_ConsoleClient и _DeploymentBin_GUIClient, находящихся в каталоге файлов проекта. Повторное сканирование необходимо для того, чтобы сервер заметил изменения файлов в этом каталоге. Если администратор выложил обновления этих файлов с помощью Студии или вручную, сервер получает из контрольные суммы и передает клиентам при их соединении с сервером, после чего клиент сравнивает их со своими локальными копиями исполняемых файлов и, если значения отличаются, запрашивает на сервере обновление. Переменная задается в секундах и по умолчанию имеет значение 20.
  • Переменная NoExecutableUpdates задает режим, когда исполняемые файлы сервера не будут обновляться при получении обновлений из Студии. Этот режим может быть полезен для старых баз, которые могут по-прежнему требовать обновлений проекта, однако, исполняемые файлы при этом обновлять не нужно. Кроме того, эту переменную необходимо установить разработчику, производящему изменения и компиляцию бинарных файлов сервера, это позволит остановить попытку из замены на старые файлы при каждом соединении Студии с локальным сервером разработчика. Переменная может принимать значения 0 (по умолчанию) и 1.
  • Переменная AcceptCrashLogs задает режим, когда логи отказов и ошибок программы принимаются сервером от клиентов и складываются в подкаталоги каталога CrashLogs, находящегося в папке с бинарными файлами сервера. Для доп. информации, см. Общая информация о сервере базы данных. По умолчанию, эта переменная равна 1 (принимать файлы). Так как на клиентах логи создаются во временной папке компьютера, при отсылке их на сервер, клиент не знает, при соединении с какой базой произошла ошибка. Если данный сервер является старой базой данных, собирать такие логи не имеет смысла, так как они, скорее всего, принадлежат другой базе данных, кроме того, для администраторов удобнее собирать логи в одном месте.
• Ветка Connection (обязательна). Ветка хранит установки, связанные с регистрацией клиента на сервере. Эта ветка обязательно должна присутствовать.
  • Переменная Name задает имя базы данных. Эта информация является справочной.
  • Переменная Description задает краткое описание базы данных. Эта информация является справочной.
  • Переменная Source (обязательна) задает путь к папке с компилированными файлами проекта. Эта переменная обязательно должна присутствовать.
  • Переменная TCPPorts (обязательна) задает TCP/IP порты по которым сервер будет слушать подключения клиентов или Студии. Каждый порт может иметь номер от 1 до 65535. Обычно задается один порт, использование более одного порта может потребоваться в более сложных конфигурациях. Все порты при соединении будут равнозначны. В системе обычно невозможно открыть более одного порта с одним и тем же номером, поэтому для сервера старой базы, работающей на этом же компьютере, необходимо использовать другой порт, не совпадающий с портом рабочей базы. Если при запуске сервер не может открыть все порты для прослушивания, запуск будет завершен с ошибкой. По умолчанию, сервер использует порт 13521, однако использование этого порта строго не рекомендуется, если порт доступен из Интернета.
  • Переменная TCPPassword (обязательна) задает пароль сервера при TCP/IP соединении. Клиент должен использовать такой же пароль, чтобы иметь возможность регистрации на сервере. Внимание: этот пароль не имеет ничего общего с паролем пользователя при входе в программу клиент. Это внутренний пароль при соединении клиента с сервером до того, как пользователь начинает вводить свое имя и пароль.
  • Переменная TCPTimeout задает тайм-аут ожидания данных сервером до того, как сервер будет считать, что его связь с клиентом была разорвана. Если клиент соединяется с сервером с помощью интернета, из-за проблем со связью, может возникнуть ситуация, когда клиент потерял связь с сервером, но сервер в данный момент не знает этого. Часто клиент блокирует какие-либо объекты или создает транзакцию, и серверу необходимо отключить клиента, если он связь с ним утеряна, чтобы освободить объекты и ресурсы системы. Поэтому, при загрузке или отправке пакетов, после определенного времени "молчания" отсутствия новой информации, сервер отключает клиента автоматически. Здесь задается такой период в миллисекундах. По умолчанию, это значение соответствует числу 300000 (5 минут), для локальных сетей рекомендуется устанавливать его в размере 60000 (1 минута).
  • Переменная AllowIPRanges позволяет задать диапазоны IP-адресов, подключения с которых будут разрешены. По умолчанию, сервер разрешает подключения с любых IP-адресов, если же эта переменная задана, сервер будет разрывать входящее подключение, если оно производится не с адреса, входящего в заданный диапазон. В данный момент можно задать только IPv4 диапазоны. Используется следующий формат, при задании диапазона адресов: <Адрес>/<Маска>[+<Адрес 2>/<Маска 2>...] (к примеру, 127.0.0.1/255.255.255.0+192.168.0.0/255.255.0.0).
  • Переменная CompressionMode позволяет задать форсированный режим сжатия пакетов при работе клиентов. Сжатие пакетов увеличивает нагрузку на процессор машины, на которой работает сервер, однако, это увеличение весьма незначительно. Кроме того, для сжатия пакета тратится дополнительное время, поэтому, для подключения по локальной сети, сжатие замедляет получение ответов сервера. Замедление также очень незначительное, поэтому, его влияние можно проигнорировать. В случае если сеть постоянно загружена, либо клиент подключен с сервером с помощью Интернета, сжатие может значительно ускорить работу с сервером, так как пакеты становятся меньше и пересылка их осуществляется быстрее. Даже для локальной сети сжатие может положительно сказаться на общей ее загрузке. Обычно сжатие настраивается на стороне клиента, однако, данная переменная задает форсированный режим сжатия. Переменная может принимать следующие значения:
    • 0 (по умолчанию) -- разрешить сжатие (сжатие будет настраиваться на стороне клиента).
    • 1 -- запретить сжатие (кроме IP адресов, указанных в переменной CompressionRanges).
    • 2 -- форсировать сжатие на любом подключении (кроме IP адресов, указанных в переменной NoCompressionRanges).
  • Переменная CompressionRanges позволяет задать диапазоны IP-адресов, при подключениях с которых сжатие пакетов (см. выше) будет форсировано. В данный момент можно задать только IPv4 диапазоны. Используется следующий формат, при задании диапазона адресов: <Адрес>/<Маска>[+<Адрес 2>/<Маска 2>...] (к примеру, 127.0.0.1/255.255.255.0+192.168.0.0/255.255.0.0).
  • Переменная NoCompressionRanges позволяет задать диапазоны IP-адресов, при подключениях с которых сжатие пакетов (см. выше) будет запрещено. В данный момент можно задать только IPv4 диапазоны. Используется следующий формат, при задании диапазона адресов: <Адрес>/<Маска>[+<Адрес 2>/<Маска 2>...] (к примеру, 127.0.0.1/255.255.255.0+192.168.0.0/255.255.0.0).
• Ветка DBase (обязательна). Ветка хранит установки, связанные с базой данных, с загрузкой библиотеки для работы с базой данных, а также установки самой библиотеки.
  • Переменная SingleUserModeOnUpdates задает режим, когда при обновлении (изменении) структуры базы данных, библиотека будет устанавливать эксклюзивный однопользовательский режим. Изменение структуры обычно производится после обновления из Студии и, если к базе данных подключены внешние программы (к примеру, SQL Server Management Studio), есть вероятность, что обновление будет невозможно выполнить из-за занятости таблицы. Для того, чтобы убедиться, что внешние программы не влияют на обновление, сервер инициирует однопользовательский режим, производит требуемые изменения и возвращает к обычному режиму. Такой подход к обновлениям работает по умолчанию и рекомендуется к использованию. Данная переменная может принимать следующие значения:
    • 0 -- не использовать однопользовательский режим при обновлении (не рекомендуется).
    • 1 (по умолчанию) -- использовать однопользовательский режим при обновлении.
    • 2 (по умолчанию) -- производить попытку перехода в однопользовательский режим при обновлении, если он недоступен, оставлять сообщение в логах сервера, и продолжить выполнять обновление в обычном режиме (не рекомендуется).
  • Переменная EnsureUptimeBeforeStart задает режим ожидания готовности СУБД компьютера сразу после его перезапуска. Переменная имеет значение только если сервер находится на том же компьютере, что и СУБД, к которому он производит подключение. Из-за того, что сразу после запуска компьютера, сервис сервера может быть запущен до запуска ПО СУБД (и даже если ПО СУБД запускается раньше, его готовность к работе может наступить через 1-2 минуты после запуска), может возникнуть ситуация, когда сервер базы данных не сможет подключиться к базе данных, либо подключится к ней, но база данных будет отсутствовать, либо база данных будет найдена, но не будет принимать запросы, так как не будет готова. Это может привести к ошибкам в работе сервера, это представляет особенную проблему при подключении к СУБД в режиме ADO, так как последний представляет очень ограниченную информацию о состоянии СУБД и базы данных в момент подключения. Чтобы избежать проблем при подключении и увеличить устойчивость запуска сервера после перезагрузки машины, переменная задает время ожидания в секундах после запуска машины сервера до того момента, как сервер выполнит попытку подключения к СУБД. По умолчанию это время равно 60 секундам, обычно этого времени достаточно, однако, если база данных очень большая, либо СУБД работает с большим количеством баз данных одновременно, и сервер работает в режиме ADO, можно увеличить это время до 2 и более минут. Не для всех типов СУБД эта переменная актуальна, при работе с СУБД SQLite3, к примеру, ее можно сделать равной нулю без какого-либо риска.
  • Переменная WorkerDll (обязательна) задает относительный или абсолютный путь к библиотеке, которая будет создавать подключения к базе данных. Обычно библиотека находится в той же папке, где располагается исполняемый файл сервера, но она также может находиться в подпапке папки сервера или в другой папке диска. Название файла библиотеки зависит от типа СУБД, к которой она производит подключение. Пример: Dll\MSSQL-ADO\MSSQL_ADO.dll. Большинство переменных ниже зависят от типа библиотеки, для одного типа они могут быть обязательны, для другого типа не иметь значения.
  • Переменная ADOProvider (MSSQL, для ADO подключений) задает наименование поставщика ADO (тип OLE-сервера ADO) при использовании библиотеки работающей с MS SQL с помощью ADO. По умолчанию это значение равно SQLOLEDB.
  • Переменная ODBCConnectionString (для ODBC подключений) задает полную строку подключения к ODBC драйверу. Если эта переменная не задана, библиотека подключения создаст строку самостоятельно из переменных ServerAddress, DatabaseName и т.п., при этом наименование драйвера ODBC будет задано в зависимости от используемой библиотеки подключения. Если Вы не знаете наименование установленного драйвера, для OS Windows, необходимо запустить администратор ODBC (odbcad32.exe) где будет полный список имен драйверов, нужно также понимать, что для 32-битного сервера необходимо запустить 32-битный администратор ODBC, который часто располагается в папке SysWOW64 Windows (32-битные и 64-битные драйверы устанавливаются отдельно!). Ниже заданы умолчания для определенных библиотек:
    • MariaDB-ODBC: DRIVER={MariaDB ODBC 3.0 Driver};SERVER=ServerAddress;USER=ServerLogin;PASSWORD=ServerPassword;DATABASE=DatabaseName;NO_PROMPT=1;PORT=3306;OPTION=67108866.
    • MySQL-ODBC: DRIVER={MySQL ODBC 5.3 Unicode Driver};SERVER=ServerAddress;USER=ServerLogin;PASSWORD=ServerPassword;DATABASE=DatabaseName;NO_PROMPT=1;PORT=3306;OPTION=67109130
    • PostgreSQL-ODBC: DRIVER={PostgreSQL ODBC Driver(UNICODE)};SERVER=ServerAddress;UID=ServerLogin;PASSWORD=ServerPassword;DATABASE=DatabaseName;PORT=5432;
  • Переменная ServerAddress (MSSQL и др., обязательна) задает адрес (или наименование машины) и наименование типа сервера (в режиме ADO), если это необходимо. Переменная записывается в виде <Адрес или имя машины>[\<Тип сервера>]. Адрес или имя машины могут представлять собой как IP-адрес SQL сервера (к примеру, 127.0.0.1), так и сетевое имя компьютера сервера (для локального компьютера можно использовать точку (.)). Тип сервера обычно не указывается, но может представлять наименование Instance MSSQL сервера, если она отличается от умолчания. Для Express версии MSSQL, необходимо указать \SQLExpress. Примеры: .\SQLExpress, Server1, 192.168.0.3 и т.п.
  • Переменная DatabaseName (MSSQL и др., обязательна) задает наименование базы данных, с которой будет происходить работа. Важно: сервер никогда не создает базу данных автоматически, если она отсутствовала в СУБД. Это важно из-за того, что администратор должен точно знать, где находятся файлы базы данных, чтобы они не создались на неверном диске и чтобы иметь быстрый доступ к ним. По умолчанию MSQSL располагает файлы баз данных глубоко в структуре папок диска в общей папке с файлами других базы данных, что не является оптимальным расположением файлов (файлы могут быть утеряны или забыты при переустановке операционной системы на компьютере). Поэтому, при настройке новой базы данных, администратор должен самостоятельно создать и назвать новую базу данных в ПО СУБД и указать в файле инициализации имя существующей БД.
  • Переменная TempDatabaseName (MySQL, MariaDB, PostgreSQL) задает наименование базы данных, используемой для хранения таблиц функций временных таблиц базы данных. Данная база данных всегда очищается при запуске сервера и хранит информацию только в момент выполнения запросов к временным таблицам. Если эта переменная не задана, сервер автоматически создает базу данных с именем, подобным основной базе данных с добавледением суфикса. База данных будет создана в каталоге данных СУБД по умолчанию. См. также переменную SQLiteTempDBFile.
  • Переменная ServerLogin (MSSQL и др., обязательна) задает имя пользователя для подключения к СУБД и базе данных. Обычно это административная учетная запись, для MSSQL часто sa. Учетная запись должна иметь полные права в СУБД для работы с базой данных. Внимание: учетная запись, задающаяся здесь, обычно не имеет отношения к учетным записям компьютера (для некоторых СУБД, это может быть не так).
  • Переменная ServerPassword (MSSQL и др., обязательна) задает пароль пользователя для подключения к СУБД и базе данных для логина, задающегося переменной ServerLogin.
  • Переменная QueryTimeout задает максимальное время исполнения запроса в СУБД в миллисекундах. Если эта переменная не задана, установка максимального времени выполнения запроса не будет изменена (будет использовано значение по умолчанию конкретной СУБД). Данная установка может помочь в случае взаимной блокировки таблиц (ситуация теоретически маловероятна, так как сервер имеет собственную защиту от таких событий, но при исключительной стечении обстоятельств, либо из-за ошибки в СУБД, такое может произойти). После ожидания окончания выполнения запроса в течение указанного времени, запрос останавливается с ошибкой и сервер передает эту ошибку клиенту, тем самым разрешая ситуацию взаимной блокировки. Внимание: установка этой переменной на слишком маленькое значение может сделать невозможным выполнение длительных запросов. Не рекомендуется устанавливать значение переменной ниже 10 минут.
  • Переменная LockTimeout задает максимальное время ожидания блокировки таблицы в СУБД в миллисекундах. Если эта переменная не задана, установка максимального времени ожидания блокировки не будет изменена (обычно по умолчанию, это время не ограничено). Данная установка отличается от QueryTimeout тем, что используется только для того, чтобы избежать взаимной блокировки таблиц при записи (ситуация теоретически маловероятна, так как сервер имеет собственную защиту от таких событий, но при исключительной стечении обстоятельств, либо из-за ошибки в СУБД, такое может произойти), тогда как QueryTimeout может срабатывать также в случаях очень длительных запросов (к примеру, при запросе, оперирующим большим количеством записей, когда СУБД сильно загружена запросами других пользователей). После ожидания блокировки таблицы в течение указанного времени, запрос СУБД останавливается с ошибкой и сервер передает эту ошибку клиенту, тем самым разрешая ситуацию взаимной блокировки. Внимание: установка этой переменной на слишком маленькое значение может вызывать частые ошибки при обработке документов, особенно в момент проведения резервного копирования.
  • Переменная FTS_configuration (PostgreSQL, рекомендуется) задает конфигурацию полнотекстового поиска (для практических целей эта переменная совпадает с языком поиска). По умолчанию, будет использована конфигурация simple. Для русского языка необходимо указать слово russian.
  • Переменная SQLiteDll (SQLite, обязательна) задает относительный или абсолютный путь к библиотеке SQLite3, которая будет выполнять функции СУБД. Обычно библиотека находится в той же папке, где располагается исполняемый файл сервера, но она также может находиться в подпапке папки сервера или в другой папке диска. Обычно библиотека имеет название sqlite3.dll, она доступная для свободного скачивания с официального сайта SQLite. Кроме этой библиотеки, для работы с SQLite не требуется скачивание и установка других файлов. Важно: тип библиотеки (x86 или x64) должен совпадать с типом исполняемого файла сервера. Важно: библиотека должна иметь версию не ниже 3.33.0.
  • Переменная SQLiteCacheSize (SQLite, желательна) задает количество памяти, выделяемой под буфер таблиц при работе SQlite3. Переменная задается в мегабайтах. Чем больше это число, тем быстрее будут происходить повторные запросы к таблицам базы данных. Однако, так как исполняемый файл сервера и библиотека СУБД в случае SQLite3 находятся в одном процессе и делят адресное пространство, может получиться ситуация, когда библиотека SQLite3 использует большую часть памяти для своих нужд и сервер не сможет нормально работать при обслуживании запросов пользователей. Чтобы избежать такой ситуации для больших базы данных, необходимо использовать x64 версию сервера на машине с большим объемом памяти. Минимально возможное значение устанавливается в размере 2 Мб, максимальное возможное значение для x86 версий сервера устанавливается в размере 1400Мб, максимальное значение для x64 версий сервера не задано. Значение по умолчанию рассчитывается по следующему алгоритму:
    • Для x86 версий: 67% от полного размера физической памяти машины, но не больше 1400Мб и не меньше 2Мб.
    • Для x64 версий: 67% от полного размера физической памяти машины, но не меньше 2Мб.
  • Переменная SQLiteHeapLimit (SQLite) задает ограничение на полное использование памяти библиотекой SQLite. Это значение включает размер буфера, заданного в переменной SQLiteCacheSize а также временный буфер запросов, переменные и пр. Обычно это значение не установлено (по умолчанию равно нулю), так как SQLiteCacheSize чаще всего использует львиную долю затраченной памяти. При неверной установке, объемные запросы будут выдавать ошибку нехватки памяти. Значение не рекомендуется к изменению.
  • Переменная SQLiteCleanFloats (SQLite) задает режим граничной очистки (округления) вещественных чисел, получаемых от SQLite. Очистка производится по алгоритму системы (см. Числа, NumberToStr). Так как SQLite работает с числами средней точности Double, результаты вычислений могут накапливать ошибку в младших дробных знаках числа. Такие результаты могут немного отличаться от обычно получаемые от других СУБД, что может быть нежелательно для работы, поэтому по умолчанию эта переменная равна 1, позволяя уменьшить влияние расчетов с такими числами на результат. Переменную рекомендуется оставить включенной, однако, если база данных работает не с финансовой информацией, а с информацией произвольной точности (математические вычисления и пр.), данная переменная может иногда вносить (минимальные) искажения в результаты вычислений, поэтому, в этом случае, ее выгоднее отключить.
  • Переменная SQLiteDatabaseCollationPage (SQLite) задает кодовую страницу, которая будет использоваться при перекодировании текста из UTF-8 в ANSI. По умолчанию это значение равно 1251 для кириллической сборки библиотеки сервера. Подобное перекодирование обычно не производится для строковых данных, поэтому, эта переменная не является очень важной.
  • Переменная DatabaseFile (SQLite, обязательна) задает путь и имя файла базы данных SQLite. Кроме этого файла в том же каталоге, где он располагается, SQLite может создавать временные файлы с добавлением префиксов к расширению (к примеру -shm или -wal (Внимание! Файл <Имя>.<Расширение>-wal не является временным, а представляет собой часть базы данных SQLite, см. ниже)), либо временные файлы с расширением sftempdb. При создании новой базы данных, файл может отсутствовать, SQLite3 создаст его самостоятельно, после чего, при проведении аудита, в файле будет создана полная структура базы данных проекта.
  • Переменная SQLiteTempDBFile (SQLite) задает путь и имя файла базы данных, который будет использоваться для работы с функциями временных таблиц. Обычно система сама определяет имя этого файла на основании имени основной базы данных, и помещает его в тот же самый каталог, что и файл базы данных. Однако, если администратору необходимо, он может поместить этот файл в другой каталог или изменить его название по умолчанию. После остановки работы сервера, файл можно удалить, так как он не содержит каких-либо данных, имеющих значение, при запуске сервера, этот файл автоматически очищается. Файл должен располагаться на быстром носителе, иначе работа с функциями временных таблиц может быть замедлена.
  • Переменная SQLiteSynchronousWriting (SQLite) задает режим буферизации записи данных на диск SQLite (см. описание PRAGMA synchronous в документации SQLite). По умолчанию это значение не устанавливается и используется внутреннее умолчание библиотеки SQLite3.dll. Использование значений меньше 2 строго не рекомендуется. Переменная может принимать следующие значения:
    • 0 -- будет разрешен буфер записи операционной системы при записи. В данном режиме запись данных будет производиться гораздо быстрее, однако, существует очень высокая вероятность потерять данные или испортить базу данных при сбое питания на сервере.
    • 1 -- запись будет вестись в режиме "нормальный" с меньшей нагрузкой на диск и очень небольшой опасностью потерять данные, чем в режиме 2. В режиме записи WAL документация SQLite утверждает, что вероятность потерять данные практически отсутствует.
    • 2 -- запись будет вестись в режиме "полный" с большей нагрузкой на диск, чем в режиме "нормальный". Этот режим медленнее, чем "нормальный", однако, вероятность потерять данные из-за сбоя питания машине сервера отсутствует. Данный режим рекомендуется к использованию.
    • 3 -- запись будет вестись в режиме "дополнительный" с еще большей нагрузкой на диск, чем в режиме "полный". Этот режим может дополнительно повысить безопасность при записи в базу данных.
  • Переменная KeepTraceLogs (SQLite,MariaDB,MySQL) задает режим, когда все запросы к базе данных и время их исполнения будут также фиксироваться в особом логе сервера. Этот режим отключен по умолчанию и может использоваться для отладки разработчиком системы. Так как при работе с SQLite невозможно использование внешнего профайлера, как, примеру, с MSSQL, библиотека сервера может вести собственный лог профайлера, который может потребоваться разработчику для оптимизации или исправления ошибок в запросах.
  • Переменная JournalMode (SQLite) задает режим записи в базу данных SQLite (см. описание PRAGMA journal_mode в документации SQLite). Режим имеет очень важное значение, так как напрямую влияет на скорость записи данных в базу данных. Переменная может принимать следующие значения:
    • DELETE -- журнал записи (дополнительный файл на диске) создается в момент транзактной записи и удаляется по ее окончании. Это самый медленный режим, он не рекомендуется к использованию.
    • TRUNCATE -- журнал записи (дополнительный файл на диске) создается в момент транзактной записи и очищается по ее окончании. Это медленный режим, он не рекомендуется к использованию.
    • PERSIST -- журнал записи (дополнительный файл на диске) создается в момент транзактной записи и его заголовок заполняется нулями по ее окончании. Это сравнительно медленный режим, он может быть использован, если режим WAL по какой-либо причине не подходит.
    • WAL (по умолчанию) -- журнал записи ведется как отдельный файл, данные поступают в него при любой записи и в определенные моменты, данные из него копируются в основной файл базы данных. Этот режим в 3-5 раз быстрее при обработке документов или сложной транзактной записи, чем другие безопасные режимы SQLite. У этого режима, однако, есть две важные особенности: при загрузке базы данных в режиме WAL, ее невозможно в дальнейшем перевести в любой другой режим; файл журнала на диске (обычно имеет расширение с суффиксом -wal), является частью базы данных (при копировании базы данных, в момент, когда сервер отключен, необходимо также скопировать и этот файл). Данный режим рекомендуется к использованию.
    • MEMORY -- журнал записи создается и ведется в системной памяти, если во время транзакции сервер будет остановлен или пропадет питание, информация в базе данных будет испорчена. Режим не рекомендуется к использованию, и может работать, для тестирования базы данных или ее быстрого заполнения с тем, чтобы потом использовать ее в других режимах.
    • OFF -- журнал записи не ведется вообще. Данный режим несовместим с работой системы, так как он не позволяет отменить транзакцию при ошибке внутри нее. С практической точки зрения, этот режим превращает базу данных в файл прямой записи без возможности работы с транзакциями.
  • Переменная MySQL_sql_mode (MariaDB,MySQL) задает умолчания для инициализации переменной sql_mode СУБД MariaDB и MySQL. Используйте документацию соответствующей СУБД для получения информации по возможным значениям переменной sql_mode. Внимание: некорректная установка этой переменной может сделать сервер неработоспособным, есть также вероятность потерять данные! Не изменяйте переменную без того, чтобы внимательно прочитать документацию СУБД. Установка по-умолчанию соответствует строке NO_BACKSLASH_ESCAPES,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION,PIPES_AS_CONCAT,ANSI_QUOTES.
  • Переменная IsMariaDB (MariaDB или MySQL) задает, к какой из СУБД будет осуществлять соединение сервер. "1" -- MariaDB, "0" -- MySQL. Если эта переменная не указана, сервер определит тип сервера из наименования драйвера ODBC. Однако, если для СУБД MariaDB используется драйвер ODBC MySQL (это позволяется), необходимо обязательно указать эту переменную.
• Ветка EventLogs. Ветка хранит установки, связанные с ведением журнала регистрации событий базы данных.
  • Переменная LogsMode задает режим ведения таблицы журнала регистрации событий. Переменная может принимать следующие значения:
    • 0 (по умолчанию) -- таблица журнала регистрации событий ведется в текущей базе данных. Такой способ ведения журнала рекомендован. Если запись в журнал ведется внутри транзакции, она будет отменена в момент отмены транзакции совместно с отменой остальных изменений. Минусом такого подхода является увеличение скорости роста базы данных, так как журнал событий может накопить большое количество строк. В отличие от остальных таблиц базы данных, журнал разрешается очищать внешними средствами, если в этом есть необходимость.
    • 1 -- таблица журнала регистрации событий ведется в другой базе данных. Такой способ ведения журнала может использоваться, если необходимо заботиться о размере базы данных (к примеру, если используется MSSQL Express). Базу данных с журналом можно заархивировать и создать заново в любой момент, кроме того сервер с базой данных может находиться на другой машине. Однако, для такого способа ведения журнала нужно понимать, что если запись в журнал ведется внутри транзакции, она не будет отменена в момент отмены транзакции совместно с отменой остальных изменений. Этот минус не затрагивает базы данных в SQLite, для которых записи в журнал, находящийся в отдельной базе данных, входят в одну транзакцию с записями в основную базу данных.
    • 2 -- таблица журнала регистрации событий ведется в текстовом файле. События поступают в один файл в течение календарного месяца, после чего, создается новый файл. Файлы создаются в каталоге EventLogs каталога файлов проекта. Такой способ ведения журнала не рекомендуется к использованию, так как, как и для способа 1, если запись в журнал ведется внутри транзакции, она не будет отменена в момент отмены транзакции совместно с отменой остальных изменений, но самое важное, сервер в данный момент не поддерживает запросы к текстовому журналу, поэтому функция Query будет недоступна. Файл журнала ведется в формате UTF-16 и в нем могут присутствовать знаки с кодами <32.
    • 3 -- таблица журнала регистрации событий не будет вестись вообще.
  • Переменная ODBCLogsConnectionString (для ODBC подключений) задает полную строку подключения к ODBC драйверу для базы данных, в которой будут храниться логи (если значение перменной LogsMode равно 1). Если эта переменная не задана, библиотека подключения создаст строку самостоятельно из переменных LogsServerAddress, LogsDatabaseName и т.п., при этом наименование драйвера ODBC будет задано в зависимости от используемой библиотеки подключения. Ниже заданы умолчания для определенных библиотек:
    • MariaDB-ODBC: DRIVER={MariaDB ODBC 3.0 Driver};SERVER=LogsServerAddress;USER=LogsServerLogin;PASSWORD=LogsServerPassword;DATABASE=LogsDatabaseName;NO_PROMPT=1;PORT=3306;OPTION=67108865.
    • MySQL-ODBC: DRIVER={MySQL ODBC 5.3 Unicode Driver};SERVER=LogsServerAddress;USER=LogsServerLogin;PASSWORD=LogsServerPassword;DATABASE=LogsDatabaseName;NO_PROMPT=1;PORT=3306;OPTION=67109130
    • PostgreSQL-ODBC: DRIVER={PostgreSQL ODBC Driver(UNICODE)};SERVER=LogsServerAddress;UID=LogsServerLogin;PASSWORD=LogsServerPassword;DATABASE=LogsDatabaseName;PORT=5432;
  • Переменная LogsServerAddress (MSSQL и др.) задает адрес (или наименование машины) и наименование типа сервера (в режиме ADO), для хранения базы данных журнала регистрации событий. Эта переменная используется только, если переменная EventLogs равна 1. Переменная записывается в виде <Адрес или имя машины>[\<Тип сервера>]. Адрес или имя машины могут представлять собой как IP-адрес SQL сервера (к примеру, 127.0.0.1), так и сетевое имя компьютера сервера (для локального компьютера можно использовать точку (.)). Тип сервера обычно не указывается, но может представлять наименование Instance MSSQL сервера, если она отличается от умолчания. Для Express версии MSSQL, необходимо указать \SQLExpress. Примеры: .\SQLExpress, Server1, 192.168.0.3 и т.п.
  • Переменная LogsDatabaseName (MSSQL и др.) задает наименование базы данных журнала регистрации событий. Эта переменная используется только, если переменная EventLogs равна 1. Важно: сервер никогда не создает базу данных автоматически, если она отсутствовала в СУБД. Это важно из-за того, что администратор должен точно знать, где находятся файлы базы данных, чтобы они не создались на неверном диске и чтобы иметь быстрый доступ к ним. По умолчанию MSQSL располагает файлы баз данных глубоко в структуре папок диска в общей папке с файлами других баз данных, что не является оптимальным расположением файлов (файлы могут быть утеряны или забыты при переустановке операционной системы на компьютере). Поэтому, при настройке новой базы данных, администратор должен самостоятельно создать и назвать новую базу данных в ПО СУБД и указать в файле инициализации имя существующей БД.
  • Переменная LogsServerLogin (MSSQL и др.) задает имя пользователя для подключения к СУБД и базе данных журнала регистрации событий. Обычно это административная учетная запись, для MSSQL часто sa. Эта переменная используется только, если переменная EventLogs равна 1. Учетная запись должна иметь полные права в СУБД для работы с базой данных. Внимание: учетная запись, задающаяся здесь, обычно не имеет отношения к учетным записям компьютера (для некоторых СУБД, это может быть не так).
  • Переменная LogsServerPassword (MSSQL и др.) задает пароль пользователя для подключения к СУБД и базе данных журнала регистрации событий для логина, задающегося переменной ServerLogin. Эта переменная используется только, если переменная EventLogs равна 1.
  • Переменная LogsDatabaseFile (SQLite) задает путь и имя файла базы данных журнала регистрации событий SQLite. Эта переменная используется только, если переменная EventLogs равна 1.
  • Переменная UserNameFieldSize задает размер в символах поля UserName таблицы журнала регистрации событий. По умолчанию эта переменная равна нулю (поле имеет неограниченную длину и тип TEXT).
  • Переменная CommentFieldSize задает размер в символах поля Comment таблицы журнала регистрации событий. По умолчанию эта переменная равна нулю (поле имеет неограниченную длину и тип TEXT).
• Ветка BackupServer хранит установки, связанные созданием резервных копий базы данных по расписанию, либо для возможности инициации создания таких копий с помощью функций InitiateBackupCreation и QueryBackupProgress. Ветка содержит произвольное количество подчиненных веток, каждая из которых должна быть названа уникально. Название подчиненных веток должно иметь вид: Task<Уникальное имя протокола копирования> (к примеру, Task132). Каждая из таких веток будет являться протоколом (задачей) резервного копирования. Ниже даны все возможные переменные, которые используются для задания алгоритма задачи резервного копирования.
  • Общие переменные (внутри ветки BackupServer, но вне веток протоколов копирования):
    • Переменная BackupToolCommandline (MariaDB, MySQL, PostgreSQL) задает имя исполняемого файла программы, используемой для инициации резервного копирования. Переменная используется для СУБД, у которых отсутствуют возможности инициации резервного копирования непосредственно из текста SQL, поэтому необходимо использование внешней исполняемой утилиты, входящей в комплект СУБД. Особенности переменной следующие:
      • MariaDB и MySQL: По умолчанию используется утилита mariabackup.exe для MariaDB и mysqldump.exe для MySQL. При задании переменной, в ней задается имя утилиты со всеми параметрами командной строки. Путь к файлу утилиты задавать не обязательно (будет использован путь к бинарным файлам СУБД). Строка, используемая по умолчанию, выглядит следующим образом: mariabackup.exe --backup --target-dir=%1% --databases="%2%" --host=%3% --port=3306 --user=%4% --password=%5% --no-defaults. Важно: резервная копия базы данных, создаваемая утилитой состоит из множества файлов, сервер комбинирует эти файлы в один .tar архив. Файлы, не связанные с базой данных (метаданные, тексты проекта и пр.) копируются обычным образом, как для остальных СУБД.
      • PostgreSQL: По умолчанию используется утилита pg_dump.exe. При задании переменной, в ней задается имя утилиты со всеми параметрами командной строки. Если папка с данными data PostgreSQL находится не в пути по-умолчанию, переменная должна присутствовать, так как иначе сервер не сможет найти положение утилиты pg_dump.exe. Строка, используемая по умолчанию, выглядит следующим образом: pg_dump.exe -Fc --schema=public --file=%1% --host=%3% --port=5432 --username=%4% --no-password %2%. pg_dump.exe не принимает пароль базы данных в командной строке, поэтому сервер передает пароль в переменных окружения.
      • Строка запуска утилиты резервного копирования может содержать следующие макросы:
        • %1% -- Папка, в которую утилита будет производить резервное копирование (система поменяет макрос на путь к временной папке в момент запуска утилиты).
        • %2% -- Заменяется на имя базы данных в момент запуска утилиты.
        • %3% -- Заменяется на адрес или DNS сервера базы данных в момент запуска утилиты.
        • %4% -- Заменяется на имя пользователя базы данных (администратора с правами резервного копирования) в момент запуска утилиты. Важно: здесь указывается имя пользователя СУБД, не имя пользователя OS или сервера.
        • %5% -- Заменяется на пароль пользователя базы данных в момент запуска утилиты.
        • %6% -- Заменяется на имя базы данных в момент запуска утилиты, для MariaDB и MySQL отличается от %2% тем, что не содержит имя базы данных mysql.
  • Переменная TaskName (обязательна) используется для задания короткого уникального имени протокола копирования. По этому имени, задача может быть доступна из функции InitiateBackupCreation.
  • Переменная ExcludedPaths хранит список путей каталога данных проекта, которые необходимо исключить из резервного копирования. Пути всегда относительные, и могут содержать более одного наименования папки. К примеру, _DeploymentBin_ConsoleClient,_DeploymentBin_GUIClient,Temp\Касса. Из резервного копирования, к примеру, можно исключить каталог с картинками, если таковой имеется и он очень объемный. Этот каталог можно включить в резервное копирование раз в день, а каждые 2-4 часа производить копирование без этого каталога. Внимание: из резервного копирования необходимо исключать файлы, которые невозможно открыть на чтение, иначе копирование закончится неудачно, поэтому, если файлы базы данных, хранятся в каталоге файлов проекта, папку с этими файлами необходимо исключить с помощью этой переменной.
  • Переменная BackupTo (обязательна) задает путь в который будет выложен результат резервного копирования (копия). Результатом может быть как папка, так и файл архива (если заданы свойства архиватора). Данный путь может находиться в сети, в этом случае, программа выполнит создание резервной копии базы данных во временной папке текущего компьютера, прежде чем переместить его в место назначения.
  • Переменная TempFolder задает путь к папке с временными файлами. Если эта переменная не задана, используется системная папка временных файлов, однако, при создании резервной копии базы данных, если системная папка располагается на том же носителе, что и файлы базы данных, копирование может быть замедлено и будет увеличивать нагрузку на жесткий диск. В этом случае, выгодно указать папку на другом диске.
  • Переменная MaximalBackupsCount задает максимальное количество старых резервных копий, которые будут храниться в папке результата. Если выполнение резервного копирования закончится удачно и по окончании процесса в папке располагается большее количество копий, чем задано в этой переменной, копии сортируются по времени создания и самые старые лишние копии (папки или файлы) будут удалены. По умолчанию эта переменная равно 10. Количество хранимых копий зависит от размера одной резервной копии и вместимости жесткого диска папки назначения.
  • Переменная Schedule задает расписание, руководствуясь которым, резервное копирование будет происходить автоматически. Без задания расписания, протокол копирования может быть вызван только с помощью функции InitiateBackupCreation, которая, однако, может исполнять и те протоколы (задачи), для которых задано расписание. Расписание представляет собой список времен событий, отделенных запятыми. Каждое время события может быть задано в одном из следующих видов:
    • MMMM -- событие, заданное числом, будет исполняться каждые MMMM минут. К примеру, 30 будет исполняться каждые полчаса.
    • [-][<День недели>:]HH:MM -- событие, состоящее только из чисел, задает день в неделе, час и минуту, когда оно будет инициировано. День недели представляет собой число от 1 до 7. Первым днем считается понедельник, последним воскресенье. Если день недели не задан, событие будет выполняться каждый день в указанный час и минуту. Если при задании события первым символом идет минус (-), дата и время этого события будут исключены из расписания. Таким образом можно исключить создание резервной копии, к примеру, в воскресенье, когда изменения в базе данных не производятся (пример такого расписания: 05:00,-7:05:00). Если событие по каким-то причинам не состоялось в указанное время (возможно в это время выполнялось другое событие резервного копирования), оно может быть инициировано позже, но не более чем на полчаса после своего расписания.
    • [-]D<День месяца>:HH:MM -- событие, начинающееся с буквы D, задает день в месяце, час и минуту, когда оно будет инициировано. Если рабочий месяц не содержит указанного дня (указано число 30, и текущий месяц февраль), оно будет пропущено. Если при задании события первым символом идет минус (-), дата и время этого события будут исключены из расписания. Таким образом можно исключить создание резервной копии, к примеру, в определенные дни месяца, когда копирование будет выполняться по другой задаче в другую папку (пример такого расписания: 7:05:00,-D1:05:00,-D10:05:00,-D20:05:00 -- событие будет выполняться каждое воскресенье в пять утра, за исключением 1, 10 и 20 числа каждого месяца). Если событие по каким-то причинам не состоялось в указанное время (возможно в это время выполнялось другое событие резервного копирования), оно может быть инициировано позже, но не более чем на полчаса после своего расписания.
  • Переменная Archiver задает строку выполнения архиватора. Если эта переменная и переменная ArchiverExtension заданы, результатом работы протокола резервного копирования будут файлы архива, а не папки с файлами-копиями. Можно использовать любой архиватор, работающий из командной строки. Необходимо использовать ключи, которые запретят любые запросы к пользователю, так как на них некому будет отвечать и протокол копирования зависнет в ожидании и никогда не будет выполнен. Пример строки архиватора для 7zip: "C:\Program Files\7-Zip\7z.exe" a "%1%\%3%" -mx4 -sse -y -r "%1%\%2%\*.*" (заметьте, что в строке используются макросы, а использование кавычек обусловлено тем, что путь может содержать пробелы). При создании строки выполнения, можно использовать следующие макросы:
    • %1% -- полный путь к папке, в которой находится папка с файлами для архивации (она может находиться в папке временных файлов или временной папке в папке назначения, но она всегда находится на локальном диске, и не в сети).
    • %2% -- имя папки, в которой располагаются файлы архивации (обычно эта папка входит в архив).
    • %3% -- имя архивного файла в расширением, который требуется создать. Это имя может включать временный суффикс, который будет удален сервером при успешном окончании процесса архивации. Имя архива должно полностью совпадать с заданным в этом макросе, так как серверу необходимо точно знать, какой файл был создан.
  • Переменная ArchiverExtension задает расширение файла архиватора (для 7zip, к примеру, эта переменная должна быть задана как 7z). Если эта переменная и переменная Archiver заданы, результатом работы протокола резервного копирования будут файлы архива, а не папки с файлами-копиями.
  • Переменная ShrinkLogs задает режим, когда после выполнения резервного копирования базы данных, сервер выполнит процедуру резервного копирования и сжатия логов базы данных. Для некоторых типов СУБД (к примеру, SQLite), такая процедура не имеет значения. В этом случае, переменная будет игнорирована. По умолчанию эта переменная не задана. Для MSSQL важно выполнять периодическое сжатие логов базы данных, иначе, через определенное время, логи станут больше по размеру, чем сама база данных, и, если не следить за ними, могут заполнить носитель на котором содержится база данных, и тем самым вызвать остановку работы с базой данных.
• Ветка ProxyServer хранит разрешения для использования серверного соединения, как TCP прокси. Такое прокси соединение можно выполнить на клиенте, использовав функцию UseProxy при соединении. Ветка может содержать до трех переменных:
  • Переменные AdministratorProxy, PowerUserProxy и UserProxy содержат разрешенные диапазоны адресов (на данный момент только IPv4 (планируется к реализации)), разрешающие соединение для пользователей с соответствующими правами. При этом для администраторов будут разрешены соединения, описанные во врсех трех переменных, для опытных пользователей, -- описанные в переменных PowerUserProxy и UserProxy, и для обычных пользователей -- только в переменной UserProxy. Адреса и порты, не описанные в этих переменных, будут запрещены для использования сервером. Любую из переменных можно не указывать. Если не указать ни одной переменной, любые прокси соединения через сервер будут запрещены. Все три переменные имеют один и тот же формат, описанный в следующем пункте.
  • Переменные имеют формат <Разрешенные диапазоны адресов прокси>[:,=]<Разрешенный диапазон портов>. Разрешенные диапазоны адресов имеют такой же формат, как и переменная AllowIPRanges. Разрешенный диапазон портов, имеет следующий формат: <Начальный порт 1>[-<Конечный порт 1>[,<Начальный порт 2>...]]. Примеры содержимого переменных:
    • 0.0.0.0/0.0.0.0:80 -- разрешает соединения на порт 80 на любые адреса, доступные серверу.
    • 192.168.0.0/255.255.0.0=21-22,5000-6000 -- разрешает соединения на порты 21,22 и от 5000 до 6000 на любые адреса, из диапазона 192.168.0.0 - 192.168.255.255. Разделитель порта можно записывать как в виде двоеточия, так и в виде знака равно.
• Ветка UpdateServer устарела и больше не используется.

Сводная таблица настроек и их применимости к разным СУБД

Ветка Ini-файла	Имя установки	Обязательна	Применимость к СУБД	Краткое описание
Common	ServiceName	Нет	-	Указывает на имя сервиса
Common	Loglevel	Нет	-	Задает уровень информации, помещаемой в лог сервера
Common	LogFile	Нет	-	Задает имя файла лога сервера
Common	UpdateCataloguesRescanPeriod	Нет	-	Задает время сканирования каталогов обновлений клиентов
Common	NoExecutableUpdates	Нет	-	Задает режим, когда исполняемые файлы сервера не будут обновляться при получении обновлений из Студии
Common	AcceptCrashLogs	Нет	-	Задает режим, когда логи отказов и ошибок программы принимаются сервером от клиентов в каталог на сервере
Connection	Name	Нет	-	Задает имя базы данных (описательное)
Connection	Description	Нет	-	Задает краткое описание базы данных
Connection	Source	Да	-	Задает путь к папке с компилированными файлами проекта
Connection	TCPPorts	Да	-	Задает TCP/IP порты по которым сервер будет слушать подключения клиентов или Студии
Connection	TCPPassword	Да	-	Задает пароль сервера при TCP/IP соединении
Connection	TCPTimeout	Нет	-	Задает тайм-аут ожидания данных сервером до того, как сервер будет считать, что его связь с клиентом была разорвана
Connection	AllowIPRanges	Нет	-	Задает диапазоны IP-адресов, подключения с которых будут разрешены
Connection	CompressionMode	Нет	-	Задает форсированный режим сжатия пакетов при работе клиентов
Connection	CompressionRanges	Нет	-	Задает диапазоны IP-адресов, при подключениях с которых сжатие пакетов будет форсировано
Connection	NoCompressionRanges	Нет	-	Задает диапазоны IP-адресов, при подключениях с которых сжатие пакетов будет запрещено
DBase	SingleUserModeOnUpdates	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает режим, когда при обновлении (изменении) структуры базы данных, библиотека будет устанавливать эксклюзивный однопользовательский режим. PostgreSQL не имеет возможности эксклюзивного режима, поэтому, перед началом изменения структуры, при работе с PostgreSQL, библиотека будет ожидать, пока в базе не останется других пользователей.
DBase	EnsureUptimeBeforeStart	Нет	-	Задает режим ожидания готовности СУБД компьютера сразу после его перезапуска.
DBase	WorkerDll	Да	-	Задает относительный или абсолютный путь к библиотеке, которая будет создавать подключения к базе данных
DBase	ADOProvider	Нет	MS SQL, подключения по ADO	Задает наименование поставщика ADO
DBase	ODBCConnectionString	Нет	MySQL (MariaDB), PostgreSQL, подключения по ODBC	Задает полную строку подключения к ODBC драйверу
DBase	ServerAddress	Да	MS SQL, MySQL (MariaDB), PostgreSQL	Задает адрес (или наименование машины) и наименование типа сервера (в режиме ADO), если это необходимо
DBase	DatabaseName	Да	MS SQL, MySQL (MariaDB), PostgreSQL	Задает наименование базы данных, с которой будет происходить работа
DBase	TempDatabaseName	Нет	MySQL (MariaDB), PostgreSQL	Задает наименование базы данных, используемой для хранения таблиц функций временных таблиц базы данных. Так как в PostgreSQL невозможна адресация разных баз данных в одном запросе, вместо базы данных, будет создана другая схема (Schema) с указанным именем.
DBase	ServerLogin	Да	MS SQL, MySQL (MariaDB), PostgreSQL	Задает имя пользователя для подключения к СУБД и базе данных
DBase	ServerPassword	Да	MS SQL, MySQL (MariaDB), PostgreSQL	Задает пароль пользователя для подключения к СУБД
DBase	QueryTimeout	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает максимальное время исполнения запроса в СУБД в миллисекундах
DBase	LockTimeout	Нет	PostgreSQL, SQLite3	Задает максимальное время ожидания блокировки таблицы в СУБД в миллисекундах
DBase	FTS_configuration	Нет	PostgreSQL	Задает конфигурацию (язык) полнотекстового поиска
DBase	SQLiteDll	Да	SQLite3	Задает относительный или абсолютный путь к библиотеке SQLite3, которая будет выполнять функции СУБД
DBase	SQLiteCacheSize	Нет	SQLite3	Задает количество памяти, выделяемой под буфер таблиц при работе SQlite3
DBase	SQLiteHeapLimit	Нет	SQLite3	Задает ограничение на полное использование памяти библиотекой SQLite
DBase	SQLiteCleanFloats	Нет	SQLite3	Задает режим граничной очистки (округления) вещественных чисел, получаемых от SQLite
DBase	SQLiteDatabaseCollationPage	Нет	SQLite3	Задает кодовую страницу, которая будет использоваться при перекодировании текста из UTF-8 в ANSI
DBase	DatabaseFile	Да	SQLite3	Задает путь и имя файла базы данных SQLite
DBase	SQLiteTempDBFile	Нет	SQLite3	Задает путь и имя файла базы данных, который будет использоваться для работы с функциями временных таблиц
DBase	SQLiteSynchronousWriting	Нет	SQLite3	Задает режим буферизации записи данных на диск SQLite
DBase	KeepTraceLogs	Нет	SQLite3, MySQL (MariaDB)	Задает режим, когда все запросы к базе данных и время их исполнения будут также фиксироваться в особом логе сервера
DBase	JournalMode	Нет	SQLite3	Задает режим записи в базу данных SQLite
DBase	MySQL_sql_mode	Нет	MySQL (MariaDB)	Задает умолчания для инициализации переменной sql_mode СУБД MariaDB и MySQL
DBase	IsMariaDB	Нет	MySQL (MariaDB)	Задает, к какой из СУБД будет осуществлять соединение сервер
EventLogs	LogsMode	Нет	-	Задает режим ведения таблицы журнала регистрации событий
EventLogs	ODBCLogsConnectionString	Нет	MySQL (MariaDB), PostgreSQL, подключения по ODBC	Задает полную строку подключения к ODBC драйверу для базы данных, в которой будут храниться логи
EventLogs	LogsServerAddress	Да, если логи ведутся в отдельной базе	MS SQL, MySQL (MariaDB), PostgreSQL	Задает адрес (или наименование машины) и наименование типа сервера (в режиме ADO), для хранения базы данных журнала регистрации событий
EventLogs	LogsDatabaseName	Да, если логи ведутся в отдельной базе	MS SQL, MySQL (MariaDB), PostgreSQL	Задает наименование базы данных журнала регистрации событий
EventLogs	LogsServerLogin	Да, если логи ведутся в отдельной базе	MS SQL, MySQL (MariaDB), PostgreSQL	Задает имя пользователя для подключения к СУБД и базе данных журнала регистрации событий.
EventLogs	LogsServerPassword	Да, если логи ведутся в отдельной базе	MS SQL, MySQL (MariaDB), PostgreSQL	Задает пароль пользователя для подключения к СУБД и базе данных журнала регистрации событий
EventLogs	LogsDatabaseFile	Да, если логи ведутся в отдельной базе	SQLite3	Задает путь и имя файла базы данных журнала регистрации событий SQLite
EventLogs	UserNameFieldSize	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает размер в символах поля UserName таблицы журнала регистрации событий
EventLogs	CommentFieldSize	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает размер в символах поля Comment таблицы журнала регистрации событий
BackupServer	BackupToolCommandline	Нет	MySQL (MariaDB), PostgreSQL	Задает имя исполняемого файла программы, используемой для инициации резервного копирования
BackupServer\<Имя задачи>	TaskName	Нет (Да, для задач резервного копирования)	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Используется для задания короткого уникального имени протокола копирования
BackupServer\<Имя задачи>	ExcludedPaths	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Хранит список путей каталога данных проекта, которые необходимо исключить из резервного копирования
BackupServer\<Имя задачи>	BackupTo	Нет (Да, для задач резервного копирования)	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает путь в который будет выложен результат резервного копирования (копия).
BackupServer\<Имя задачи>	TempFolder	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает путь к папке с временными файлами
BackupServer\<Имя задачи>	MaximalBackupsCount	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает максимальное количество старых резервных копий, которые будут храниться в папке результата
BackupServer\<Имя задачи>	Schedule	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает расписание, руководствуясь которым, резервное копирование будет происходить автоматически
BackupServer\<Имя задачи>	Archiver	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает строку с шаблоном исполнения архиватора
BackupServer\<Имя задачи>	ArchiverExtension	Нет	MS SQL, SQLite3, MySQL (MariaDB), PostgreSQL	Задает расширение файла архиватора
BackupServer\<Имя задачи>	ShrinkLogs	Нет	MS SQL	Задает режим, когда после выполнения резервного копирования базы данных, сервер выполнит процедуру резервного копирования и сжатия логов базы данных
ProxyServer	AdministratorProxy, PowerUserProxy, UserProxy	Нет	-	Рарешает диапазоны адресов и портов (в разрезе групп пользователей), для которых можно использовать прокси соединение через сервер (см. функцию UseProxy).

Файлы настроек, располагающиеся в папке LocalConfig папки проекта

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

• Файл loginoptions.ini используется для настроек подключения клиентов к системе. Он представляет собой файл инициализации описанного выше формата (в формате ANSI или UTF-16). В файле присутствуют следующие ветки:
  • Ветка Common используется для задания общих установок входа.
    • Переменная StoreHashesOnly позволяет включать режим, когда пароли, введенные пользователями, не сохраняются в файле учетных записей, вместо паролей будут сохраняться хэши MD5. Это позволяет не открывать пароли пользователей администраторам системы. По умолчанию эта переменная равна нулю.
    • Переменные, связанные с формированием минимальной и максимальной длины паролей, а также их уровнем сложности также планируются для использования в данной ветке.
  • Ветка NTLM задает режим использования аутентификации с помощью NTLM для регистрации пользователей. Не наличия такой ветки, новые учетные записи пользователей могут быть введены только с помощью редактора учетных записей в клиенте или непосредственно с помощью текстового редактора в файл usercreds.ini.
    • Переменная UseNTLM задает режим, когда NTLM будет использован (значение должно быть равно 1). По умолчанию значение переменной равно нулю.
    • Переменная NTLMDomain задает домен или имя компьютера, к которому будут переадресовываться запросы по аутентификации пользователей. Если значение не задано, при запуске, сервер попытается найти это значение автоматически, и будет использовать имя домена, в который включен компьютер на котором быть запущен сервер.
    • Переменная UsersGroups задает группы пользователей (как они заданы в панели управления компьютера или в Active Directory домена), имеющих доступ к серверу. Группы пользователей должны перечисляться через запятые. Если эта переменная не задана, любые пользователи, имеющие учетную запись в домене, или учетные запись в файле usercreds.ini (некоторые учетные записи могут быть не связаны с NTLM и заданы вручную из редактора учетных записей в клиенте). будут иметь возможность работать на сервере. Если переменная задан, только пользователи, принадлежащие указанным группам (или группам последующих двух переменных) смогут регистрироваться на сервере. Рекомендуется задавать эту переменную, так как это повышает безопасность в сети.
    • Переменная PowerUsersGroups задает группы пользователей (как они заданы в панели управления компьютера или в Active Directory домена), которые будут обладать правами ограниченных администраторов (см. Общая информация о сервере базы данных). Группы пользователей должны перечисляться через запятые.
    • Переменная AdministratorsGroups задает группы пользователей (как они заданы в панели управления компьютера или в Active Directory домена), которые будут обладать полными правами администраторов (см. Общая информация о сервере базы данных). Группы пользователей должны перечисляться через запятые. Эту переменную рекомендуется задавать, если администраторов достаточно много, если же в программе работает две один-два администратора, безопаснее, установить свойства их учетных записей, как административные и отвязать их от аутентификации NTLM.
• Файл usercreds.ini создается и ведется сервером автоматически, редактирование его с помощью текстового редактора возможно, но не рекомендуется. При редактировании файла с помощью редактора, сервер должен быть выключен. Файл обычно создается в формате UTF-16 с BOM и представляет собой стандартный файл инициализации, описанный выше. При редактировании учетных записей в визуальном клиенте (см. Общая информация о консольном и визуальном клиентах), сервер получает изменения и сохраняется их в этом файле. Файл также хранит дату и время первого и последнего входа каждого пользователя, поэтому, файл будет обновляться достаточно часто. Наряду с оригинальной версией файла, сервер хранит его предыдущую версию usercreds.bak, которая может пригодиться, если оригинальный файл был испорчен из-за сбоя или по каким-то другим причинам.
• Файл dbaseLocal.ini обычно создается администратором вручную с помощью текстового редактора и может содержать те же переменные, что и файл dbase.ini, хранящийся в корневой папке файлов проекта и создаваемый непосредственно в Студии. Любая переменная локального файла заменяет значение файла, пришедшего с обменом из Студии. Это актуально и может использоваться для клиентов, если необходимо задать для текущей базы данных другое название, отображаемое в заголовке программы и в диалоге входа пользователя, чтобы пользователи не перепутали разные базы данных. Для редактирования этого файла из Студии см. Установки проекта. Локальный файл установок базы данных может содержать следующие переменные:
  • Name -- позволяет задать наименование проекта (в данном случае, может использоваться для задания наименования локальной базы данных).
  • BuildNumber, VersionName -- задает программные свойства проекта, доступные как из диалогов клиента, так и программно.
  • ExcludedFolders -- задает папки, исключенные из обмена при получении обновлений из Студии.

Резервное копирование с помощью сервера базы данных и восстановление резервной копии базы данных

Резервное копирование важный процесс, помогающий избежать утери базы данных, которая могла бы обернуться неделями работы и финансовыми потерями для предприятия. При использовании системы рекомендуется проводить регулярное резервное копирование на дисковый накопитель, физически отличающийся от накопителя, на котором находится база данных. Кроме того, желательно осуществлять резервное копирование на другое устройство в сети. Даже если в Вашей организации используется raid массив или другие защитные технологии, резервное копирование необходимо осуществлять на регулярной основе. См. также статью Общая информация о сервере базы данных.

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

• В файле инициализации можно задать произвольное количество задач для резервного копирования, с разным расписанием или для программного запуска. Каждая задача может осуществлять копию в свой каталог резервного копирования.
• Сервер датирует копии и может хранить определенное количество, удаляя более старые копии по мере появления новых.
• Сервер может осуществлять резервное копирование на сетевые диски. Внимание: в системе Windows при работе сервера базы данных в виде сервиса системы (режим по умолчанию) для доступа сервера на сетевые диски, необходимо настроить вход сервиса с учетной записью отличной от "Локальной системы", так как последняя не будет иметь доступ к сети.
• Сервер следит за корректностью и полнотой резервной копии, если резервное копирование было прервано в результате внезапного выключения сервера или отключения его от сети, в будущем, неверная копия будет автоматически удалена из набора резервных копий.
• В резервную копию попадает не только копия базы данных, но и все файлы проекта сервера, а также отдельная копия базы данных журнала регистрации событий, если последний хранится в базе данных, отличной от основной базы данных.
• Сервер может автоматически архивировать копии базы данных, для их более компактного размещения в каталоге резервных копий в виде одного файла на резервную копию.
• Для СУБД типа MySQL и MariaDB, которые создают резервную копию базы данных как множество файлов и каталогов, сервер автоматически объединяет файлы копии базы данных в один файл в формате tar без использования компрессии.
• Используя возможности сервера, администратор может не опасаться, что сервер не сможет запуститься из-за того, что во время обновления проекта из Студии и перезапуска сервера, он не смог войти в эксклюзивный режим базы данных, так как в этот момент работала внешняя программа резервного копирования. Тем самым исключается необходимость в дополнительных действиях на сервере и повторной инициации обновления.

Инициировать резервное копирование с помощью сервера базы данных можно тремя способами:

• Сервер инициирует процесс копирования по расписанию заданному в установках задачи резервного копирования (см. выше).
• С помощью функций InitiateBackupCreation и QueryBackupProgress можно запускать задачи резервного копирования программно и следить за их выполнением.
• С помощью командной строки исполняемого файла сервера (процесс сервера при этом должен быть запущен) в формате sfsrv.exe "BACKUP <Имя задачи резервного копирования>" можно инициировать резервное копирование и отследить его выполнение (см. статью Ключи запуска сервера из командной строки).

Восстановление резервной копии всегда зависит от конкретного вида СУБД. Обычно алгоритм восстановления резервной копии следующий:

• Остановка сервера базы данных.
• Удаление каталога файлов проекта.
• Копирование каталога файлов проекта из резервной копии.
• Удаление или отключение текущей базы данных.
• Восстановление базы данных из резервной копии базы данных. Для разных СУБД, этот процесс может несколько отличаться:
  • Для MS SQL резервная копия может быть восстановлена с помощью графического интерфейса СУБД.
  • Для SQLite3 резервная копия представляет собой рабочий файл базы данных, который можно скопировать в рабочий каталог.
  • Для PostgreSQL резервная копия по умолчанию представляет собой бинарный сжатый файл, который можно восстановить в рабочую базу данных с помощью утилиты pg_restore.
  • Для MySQL или MariaDB см. статью ниже.
• Запуск сервера.

Резервное копирование и восстановление базы данных для СУБД MariaDB и MySQL

В отличие от MS SQL, где базу данных можно восстановить из резервной копии с помощью графического интерфейса или SQLite3, который создает резервную копию в виде рабочего файла данных, который можно использовать как базу данных сразу после резервного копирования, восстановление базы данных MariaDB и MySQL может быть связано с определенными сложностями.

Для осуществлении резервного копирования online (т.е., при работающих пользователях), необходимо использовать утилиту mariabackup, входящую в состав файлов установки СУБД MariaDB, для MySQL можно использовать совместимую утилиту Xtrabackup, либо потенциально более медленную mysqldump.

По умолчанию подразумевается использование утилит mariabackup или Xtrabackup, а не утилиты mysqldump, так как последняя делает логическую текстовую резервную копию, создание которой может занимать более продолжительное время. В процессе резервного копирования блокируются таблицы и увеличивается активностью диска и длительный процесс копирования для больших баз данных может очень негативно сказаться на работе пользователей. Обычно простое копирование файлов (mariabackup) должно осуществляться быстрее, чем создание файлов путем получения информации из базы данных (mysqldump), однако, дамп, полученный с помощью mysqldump более компактный по размеру (часто в 2.5-3 раза), поэтому, для определенных серверов mysqldump может работать быстрее и меньше увеличивать активность диска.

При использовании утилиты mysqldump вместо mariabackup, в переменной BackupToolCommandline можно указать следующую строку: [Путь к бинарным файлам СУБД\]mysqldump --allow-keywords --complete-insert --hex-blob --host=%3% --user=%4% --password=%5% --port=3306 --single-transaction --databases %6% (макрос %6% тут используется для указания на список баз данных без базы данных mysql, которая не требуется при таком резервном копировании). Так как утилита mysqldump выгружает дамп в стандартный поток вывода (stdout) и перенаправить его в файл при запуске процесса из приложения используя только командную строку невозможно, сервер будет определять необходимость в получении данных из стандартного потока по наименованию утилиты. Если используется другая утилита с выгрузкой в стандартный поток, имя которой не соответствует mysqldump, необходимо запускать ее через какую-либо программу, которая сама перенаправит стандартный поток в файл (макрос %1%).

Дальнейшая информация параграфа относится только к mariabackup.

Резервное копирование рекомендуется осуществлять строго возможностями сервера базы данных (по причинам сложности и капризности резервного копирования данных СУБД), если все-таки оно выполняется сторонней утилитой, для его осуществления с помощью mariabackup должна используется командная строка mariabackup --backup --target-dir=<Папка, в которую происходит копирование> --databases="mysql <Имя базы данных>" --host=<Адрес сервера> --port=<Порт сервера> --user=<Имя администратора сервера> --password=<Пароль администратора> --no-defaults. Обратите внимание: папка резервного копирования должна иметь обратные косые знаки / вместо прямых, даже если рабочей средой является система Windows (к примеру, G:/Temp/Backup/), папка также не должна содержать специальных символов длинного пути (\\?\) или сетевого пути (\\). Также обратите внимание: имя базы данных всегда указывается в нижнем регистре, кроме имени базы данных указывается также база данных mysql, которая хранит информацию по всем метаданным СУБД, иначе резервную копию не удастся восстановить простым способом. Если резервное копирование осуществляется средствами сервера базы данных, командную строку и расположение утилиты он подберет автоматически.

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

• При восстановлении все другие базы данных на сервере СУБД будут удалены. После успешного процесса восстановления в СУБД останутся только две рабочие базы данных: mysql (сервисная база данных) и восстановленная база данных. Это может стать проблемой в случае, если в СУБД используются другие базы данных. Обойти это ограничение не так просто. Но так как восстановление резервной копии -- процесс очень редкий и связанный с катастрофическими событиями, можно, к примеру, восстановить базу данных на другой машине с СУБД, сделать ее резервную копию с помощью утилиты mysqldump, затем восстановить ее в рабочую копию СУБД из полученного текстового дампа. В Интернете есть информация по другим способам восстановления.
• При описанном здесь процессе восстановления невозможно изменить имя восстанавливаемой базы данных. Восстановленная база данных всегда будет иметь такое же имя, как и оригинальная, для которой создавалась резервная копия.
• Восстанавливать базу данных необходимо той же версией СУБД, которая создавала резервную копию.

Общий процесс восстановления резервной копии описан выше в параграфе о резервном копировании, здесь описывается обычный и самый простой процесс восстановления базы данных в СУБД из резервной копии, созданной утилитой mariabackup:

• Остановите СУБД.
• Удалите или переместите папку Data, в которой хранятся все базы данных СУБД. Создайте снова эту папку, с тем, чтобы она не содержала никаких файлов. Сохраните файл my.ini из удаляемого каталога (только для MariaDB, MySQL хранит этот файл в другой папке). Для Windows папка Data для MariaDB обычно находится в каталоге установочных файлов MariaDB (в Program Files), для MySQL в папке ProgramData\MySQL\....
• Распакуйте tar архив, в котором содержатся файлы резервной копии базы данных в формате СУБД. Скажем, содержимое файла было распаковано в папку c:\backup\.
• В каталоге с бинарными файлами СУБД выполните следующую команду mariabackup --prepare --target-dir="c:/backup/" (здесь указан путь, куда мы распаковали tar архив). Этот шаг позволяет подготовить резервную копию к восстановлению.
• В каталоге с бинарными файлами СУБД выполните следующую команду mariabackup --copy-back --target-dir="c:/backup/" (здесь указан путь, куда мы распаковали tar архив). Этот шаг выполняет копирование файлов восстановления в каталог Data СУБД.
• Добавьте сохраненный файл my.ini в заполненный каталог Data (только для MariaDB).
• Добавьте разрешения полного доступа для всех пользователей ко всем файлам и подкаталогам каталога Data. Важно: не пропускайте этот шаг, СУБД активно использует системные разрешения и не будет работать корректно, если сервису не дать разрешения на запись к файлам восстановленного каталога с данными Data. Если Вы знаете, под каким пользователем запускается сервис СУБД, достаточно добавить разрешения только для учетной записи, под которой он работает.
• Запустите СУБД и сервер базы данных. Резервная копия успешно восстановлена.

При восстановлении резервной копии, особенно если это делается в первый раз, можно испортить установку MariaDB и MySQL. Ниже даются возможные случаи, когда СУБД становится неработоспособной и способы исправления аварийной ситуации:

• Q: Сервис СУБД не запускается, однако, СУБД запускается из командной строки. A: Вероятнее всего, сервис не может получить доступ записи в каталог data СУБД. Для исправления, необходимо изменить разрешения на каталоге Data и всех его подкаталогах и файлах, к примеру, добавив полный доступ всем пользователям.
• Q: СУБД запускается, но восстановленные таблицы базы данных недоступны (ошибка: "таблица не существует на данном сервере"). A: Сервисная база данных mysql, в которой содержится информация по метаданным базы данных, не была восстановлена вместе с базой данных. Необходимо восстановить резервную копию еще раз. Если в резервной копии не содержится копии БД mysql, восстановление приобретает нетривиальных характер, и его обсуждение выходит за пределы этой документации. В Интернете есть информация, позволяющая выполнить такую задачу.
• Q: Восстановленная или рабочая база данных содержит повреждения или ошибки, что не позволяет удалить ее из СУБД. A: Для сброса СУБД и удаления всех ее баз данных, необходимо остановить СУБД, удалить каталог Data и запустить утилиту mysql_install_db, находящуюся в каталоге бинарных файлов СУБД. Данная утилита создаст и заполнит каталог Data заново и позволит избежать необходимости переустановки СУБД.

Для дополнительной информации, см. внешнюю статью full-backup-and-restore-with-mariabackup на mariadb.com.