ambiguous field name between table

Обновляемые view, триггеры и rows affected

Обнаружены проблемы с обновляемыми view, имеющими before update триггеры. Когда одна (1) запись обновляется, сообщается что три (3) записи было обновлено.

Статус — исправлено, Firebird 1.0 не будет содержать этой ошибки

Ошибка при росте файла сортировки более 2Гб

Статус — исправление ошибки тестируется, будет включено в Firebird 1.0

Изменение Forced Writes при открытой БД выдает ошибку (только на Win32)

Статус — исправление ошибки тестируется, будет включено в Firebird 1.0

Проблема с 64-битными целыми числами, диалектом 1 и SELECT FIRST

SELECT FIRST(?Param1) Field1, Field2, . , FROM TABLE1
выдает ошибку

message :
«Dynamic SQL error.
SQL error code = -804
Data type unknown.
Client SQL dialect 1 does not support reference
to 64-bit numeric datatype.»

Статус — исправлено, будет включено в Firebird 1.0

Проблема с RECREATE PROCEDURE

Статус — исправление ожидается в Firebird 1.0

Проблема с gbak при restore и длинными именами объектов

При restore имена объектов, имеющие длину 32 символа, обрезаются до 31 символа.

Статус — исправлено в RC2

Излишние сообщения о UDF в interbase.log

Статус — исправлено в RC2, такие сообщения выводятся только в отладочной версии.

У snapshot для Win32 неверный номер FILEVERSION

Если Вы загрузили snapshot RC1 для Windows, рекомендуем Вам загрузить самую последнюю версию.

FILEVERSION это скрытый ресурс, хранимый как integer. Он не виден в File | Properties для ibserver.exe. Однако он используется инсталляционными скриптами для определения номера версии исполняемых и dll файлов. Оригинальный релиз Win32 RC1 содержит FILEVERSION равный 7.2. Если эти файлы оставить на диске, то инсталляторы новых версий Firebird или Interbase могут сработать неправильно (т.е. не переписать ibserver.exe и другие файлы).

Если вы используете старый RC1 (дата правильного snapshot должна быть 19-NOV-01 01:00:00. У неправильных файлов дата равна или меньше 13-NOV-01.), то рекомендуется вручную удалить файлы *.exe, *.dll и gds32.dll перед установкой новой версии, или не удаляя переписать их файлами из более свежего snapshot.

Дистрибутив с инсталлятором для Win32 использует самые последние версии исполняемых файлов, и не имеет подобной проблемы.

Если вы устанавливаете файлы из snapshot, то поставте RC1a snapshot. В нем находятся правильные файлы.
RC1a выпущен 26 ноября, и содержит файлы билда 612.

Статус — исправлено в RC2

Я думал, что по умолчанию у создаваемых баз данных ForcedWrites = ON.

Статус — исправлено в RC2. Т.е. вновь создаваемые БД имеют FW = ON.

У меня раньше работал запрос, а теперь он возвращает ошибку:

SQL error code = -204
Ambiguous field name between table/view TOKEN and table/view

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

Это один из основных пунктов при миграции на новые версии Firebird.

КДВ: привожу пример неоднозначной выборки над employee.gdb:

поле phone_no есть как в delartment, так и в sales. Поэтому Firebird на такой запрос будет «ругаться», требуя указать алиасы полей явно. Не ленитесь, поскольку такое требование указано и в стандарте (т.е. подобное поведение Firebird — это не самодеятельность).

Статус — расширено в RC2 (в диалекте 1 подобный запрос отработает, а в диалекте 3 — выдаст ошибку).

Именно поэтому драйвер EasySoft ODBC работает с RC1 криво?

Увы, да. Драйвер использует запросы с неуточнением имен полей. В RC2 это будет исправлено.

Статус — исправлено в RC2.

Я слышал про баг связанный с DELETE и новым оператором FIRST

Да, есть такое. Замечательный способ удалить все данные в таблице. Пример:

delete from table where col in (select col first 5 from table);

не удалит только 5 строк, а удалит все записи. Потому что подзапрос выполняется для КАЖДОЙ записи внешнего запроса. Собственно, указывать FIRST в подобных случаях нельзя, однако сообщение об ошибке пока не выдается.

Статус — не решено . Не исправлено в RC2.

Когда я использую комментарий — в скрипте или ISQL я получаю сообщение:

-SQL error code = -104
-Token unknown — line N, char X

Да, есть такая ошибка в ISQL. Вполне возможно, что она уже исправлена в самых последних билдах Firebird.

Статус — исправлено в RC2.

Билды для Linux поддерживают файлы больше 2Gb (64bit I/O), или нет?

Пока нет. Код добавлен в дерево исходных текстов, но пока полностью под Linux не тестировался. В настоящее время файлы базы данных более 2Гб поддерживаются только на Win32 и Darwin (Mac OS X). Так что пока для баз больше 2Гб используйте многофайловые БД.

Когда код будет окончательно протестирован, будут доступны отдельные дистрибутивы. Так будет потому, что сама операционная система должна поддерживать работу с большими файлами, а это есть только в Linux kernel 2.4, да и то работает пока не совсем надежно или однозначно.

Статус — исправлено в RC2.

В Release Notes маловато информации о неисправленных багах. Где я могу найти побольше?

Такая информация есть на http://www.ibphoenix.com/FirebirdBugsOpen.html. Этот же файл есть каталоге doc инсталляции и исходных текстах. При наличии доступа в internet клик на номере бага отправит вас на соответствующее описание на SourceForge.

В Release Notes упоминается FBUDF.DLL. Не могу найти ее.

Действительно. Этот момент был упущен при создании дистрибутива. Файл будет доступен в самое ближайшее время.

Порядок триггеров (position) игнорируется в RC1

КДВ: RC1 начался с билда 1.0.0.555. Там этот баг был. В билде 1.0.0.608RC1 он уже исправлен.

Да, если в вашей базе данных порядок триггеров важен, то в данной версии он игнорируется.

Статус — исправлено в RC2.

Запрос работал в Beta 2, но теперь не работает в RC1:

SELECT X.CUST_NO, ABS(SUM(X.TOTAL_VALUE))
FROM SALES X
GROUP BY X.CUST_NO;

InterBase никогда не позволял группировать по вычисляемым выражениям или пользовательским функциям (UDF). В Firebird эта возможность добавлена, однако она имеет ряд побочных эффектов, поэтому пока была выключена.

Статус — исправлено в RC2, будет включено в Firebird 1.0.

GBAK не может сохранить значения генераторов с именами, содержащими пробелы

Да, баг есть, причем достаточно старый, и возможно относится ко всем версиям Interbase 6.0. Уже исправлен в билдах Firebird 1.0.0.608 и выше.

I have a SQL query to link many tables using the word «using» and one of the tables occurs in each element, error:

Ambiguous field name between an alias and a field in the select list with the name. ID_DEPARTMENT

how to change the query correctly? Request link: https://pastebin.com/t2rqMAut

this is a query to initialize the schedule items, each item belongs to its own Department, so i need to add the departments table every time. Database schema: Database schema

I attach the database file example current version of Firebird: 2.5.7

3 Answers 3

The problem is that you repeatedly join the table departments without aliasing it. When you then reference departments.id_department in the select list, Firebird doesn’t know which of the four instances of departments it needs to use.

You either need to change your query so you only reference departments once, or if for some reason you need it (I don’t think you do, as demonstrated by the answer of scaisEdge), you need to explicitly alias each occurrence of departments and then qualify the column name with the right alias.

You have several ambiguous columns, the first occurred if for the nested join from departments , teachersanddepartments and teachers .

But each time you use the same column name coming for different tables. You have the same problems, so I have disambiguated the columns for teachersanddepartments , subjects , classrooms , groups :

And due to the fact you are using INNER JOIN the () for the JOIN seems unnecessary and redundant too.

With nested joins, you join the table departments 3 times; without () nested join you need one join only:

and as suggested by Mark Rotteveel in a proper answer this could be the reason for your error

есть sql запрос на связь многих таблиц используя using и одна из таблиц встречается в каждом элементе, ошибка:

Ambiguous field name between an alias and a field in the select list with name. ID_DEPARTMENT

как правильно изменить запрос? Ссылка на запрос https://pastebin.com/t2rqMAut

2 2
• 7 янв 2018 2018-01-07 15:49:12
• Anton Zybekov

2 ответа

Похоже поле ID_DEPARTMENT встречается в четырех разных таблицах. Нужно везде заменить using на явное равенство, поставить у всех таблиц уникальные алиасы и писать имена полей обязательно с ними.

• 15 янв 2018 2018-01-15 12:17:13
• Eugene

Точно работающий вариант — заменить using на обычное соединение по равенству.