Где учитывается диалект

We use cookies. Read the Privacy and Cookie Policy

Где учитывается диалект

Концепция диалекта различает способ поддержки типов данных и возможности языка, доступные в базах данных с ODS-9 (диалект 1) и ODS-10 и выше (диалект 3). Сам сервер не имеет "диалекта" - диалект базы данных сохраняется как атрибут базы данных. Он является интерфейсом клиента, который определяет, какой набор возможностей запрашивается у базы данных. При некоторых условиях, если вы как разработчик приложений или пользователь инструментов администратора используете его неправильно, вы получите ошибочные данные, сохраняемые в базе, что может привести к некорректной работе приложений и базы данных.

Здесь удобно обратиться к экземпляру клиентского соединения, выполненного с помощью библиотеки API или пользовательского драйвера языка, такого как JayBird (Java), ODBC или провайдер .NET, как "клиент диалекта 1" или "клиент диалекта 3". Это означает, что интерфейс клиента будет установлен для получения возможностей диалекта 1 или 3.

Что можно отбросить

Следующий список иллюстрирует некоторые отличия диалекта 1 от диалекта 3.

* Диалекты 1 и 3 хранят большие масштабируемые числа по-разному. В диалекте 3 все типы с фиксированной точкой (NUMERIC и DECIMAL), имеющие точность больше 10, являются 64-битовыми целыми с описанием, которое включает некоторые атрибуты для определения точности и масштаба. В диалекте 1 числа с фиксированной точкой хранятся как 16- или 32-битовые целые, а числа с точностью, превышающей 10, преобразуются для хранения в 64-битовый тип числа с плавающей точкой DOUBLE PRECISION. Ваши данные, вероятно, вызовут ошибку переполнения, если клиент диалекта 3 выдаст запрос на сохранение числа в базе данных диалекта 1, или сгенерируют ошибочный результат, когда клиент диалекта 1 выдаст запрос на операции с числами в базе данных диалекта 3.

* Генераторы в диалекте 3 являются 64-битовыми целыми, в то время как в диалекте 1 генераторы - 32-битовые целые.

* Арифметические операции в диалекте 3 были взяты из стандарта SQL-92, в то время как диалект 1 использует нестандартные правила. Например, деление целого на целое в диалекте 3 возвращает усеченное целое, в то время как в диалекте оно вернет число с плавающей точкой двойной точности. Если ваше приложение сохраняет результат выражения, включающего подобную арифметическую операцию, "ошибочные" результаты будут сохранены без возбуждения исключения.

* Оба диалекта имеют тип данных даты и времени с именем DATE, но это разные типы. В диалекте 1 тип DATE эквивалентен типу TIMESTAMP диалекта 3, а в диалекте 3 DATE является типом, хранящим только дату; этот тип не поддерживается в диалекте 1.

* Диалект 3 поддерживает тип TIME (время дня), который отсутствует в диалекте 1.

* В базах данных диалекта 3 Firebird поддерживает соглашения ANSI SQL по идентификаторам с разделителями, которые заключаются в двойные кавычки; такие

идентификаторы не могут использоваться в диалекте 1. Несоответствие диалектов клиента и базы данных приведет к исключениям и некорректной работе.

* Диалект 3 имеет больше зарезервированных ключевых слов, чем диалект 1. Существующие базы данных диалекта 1, которые используют новые ключевые слова в качестве идентификаторов, не будут работать с клиентом диалекта 3.

* Диалекты 1 и 3 ведут себя по-разному в случае неявного преобразования типов. Это может стать проблемой, если вы хотите конвертировать существующую базу данных в диалект 3 и изменять использующие ее приложения.

Диалект 2

Не существует такого предмета, как "база данных диалекта 2". Диалект 2 является клиентской установкой, которую вы можете использовать для проверки переходных требований типов данных при конвертировании базы данных диалекта 1 в диалект 3. Inprise Corporation (теперь Borland) разработала документ "Migration Guide" (Руководство по миграции) для InterBase 6.0 в 2000 году, где подробно описаны действия по конвертированию баз данных диалекта 1 в диалект 3. Этот документ в формате PDF доступен на некоторых сайтах сообщества Firebird.