2010-12-31 3 views
1

Когда я пытаюсь запустить этот запрос в Access через интерфейс ODBC в базу данных MySQL, я получаю сообщение «Выражение слишком сложное в выражении запроса». Существенная вещь, которую я пытаюсь сделать, это перевести сокращенные имена языков в их полноэкранные английские коллеги. Мне было любопытно, есть ли какой-то способ «обмануть» доступ к мысли, что выражение меньше с дополнительными запросами, или если кто-то еще лучше понял, как решить эту проблему. Я подумал о создании временной таблицы и о присоединении к ней, но это не поддерживается в Access SQL.Expression Too Complex In Access 2007

Как и в случае с FYI, запрос работал нормально, пока я не добавил большую длинную цепочку IFF. Я протестировал запрос на меньшую цепочку IFF для трех языков, и это не было проблемой, поэтому проблема определенно связана с огромной цепочкой IFF (она составляет 26 дюймов). Кроме того, я мог бы отказаться от некоторых параметров (например, объединить разные формы китайского или португальского языков)

В качестве теста я смог получить SQL-запрос для работы после его обработки до 14 IFF() но это далеко от 26 языков, которые я хотел бы представлять.

SELECT TOP 5 Count(*) AS [Number of visits by language], IIf(login.lang="ar","Arabic",IIf(login.lang="bg","Bulgarian",IIf(login.lang="zh_CN","Chinese (Simplified Han)",IIf(login.lang="zh_TW","Chinese (Traditional Han)",IIf(login.lang="cs","Czech",IIf(login.lang="da","Danish",IIf(login.lang="de","German",IIf(login.lang="en_US","United States English",IIf(login.lang="en_GB","British English",IIf(login.lang="es","Spanish",IIf(login.lang="fr","French",IIf(login.lang="el","Greek",IIf(login.lang="it","Italian",IIf(login.lang="ko","Korean",IIf(login.lang="hu","Hungarian",IIf(login.lang="nl","Dutch",IIf(login.lang="pl","Polish",IIf(login.lang="pt_PT","European Portuguese",IIf(login.lang="pt_BR","Brazilian Portuguese",IIf(login.lang="ru","Russian",IIf(login.lang="sk","Slovak",IIf(login.lang="sl","Slovenian","IIf(login.lang="fi","Finnish",IIf(login.lang="sv","Swedish",IIf(login.lang="tr","Turkish","Unknown")))))))))))))))))))))))))) AS [Language] 
FROM login, reservations, reservation_users, schedules 
WHERE (reservations.start_date Between DATEDIFF('s','1970-01-01 00:00:00',[Starting Date in the Following Format YYYY/MM/DD]) And DATEDIFF('s','1970-01-01 00:00:00',[Ending Date in the Following Format YYYY/MM/DD])) And reservations.is_blackout=0 And reservation_users.memberid=login.memberid And reservation_users.resid=reservations.resid And reservation_users.invited=0 And reservations.scheduleid=schedules.scheduleid And scheduletitle=[Schedule Title] 
GROUP BY login.lang 
ORDER BY Count(*) DESC; 

@ Michael Todd

Я полностью согласен. Список языков должен был быть таблицей в базе данных, а login.lang должен был быть FK в этой таблице. К сожалению, это не то, как была написана база данных, и это не мое изменение. Языки помещаются в поле login.lang с помощью PHP, работающего поверх базы данных.

+2

Почему бы просто не использовать таблицу поиска с языковыми значениями, а затем присоединиться к ней в вашем запросе? Это не обязательно временная таблица (на самом деле она, вероятно, должна быть постоянной). –

+1

Я полностью согласен с Майклом Тоддом. Очень просто настроить таблицу с сокращением языка и полным именем. – Fionnuala

ответ

1

Я думал о создании временной таблицы и создании соединения на ней, но это не поддерживается в Access SQL.

Вы пытались создать таблицу языков в Access и присоединять ее к таблицам MySQL?

+0

Просто сегодня, и да, что сработало отлично :) У меня не было изменения исходной базы данных. – Jazzepi

1

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

Спасибо, Shibin

IIf(login.lang="ar","Arabic",IIf(login.lang="bg","Bulgarian",IIf(login.lang="zh_CN","Chinese (Simplified Han)",IIf(login.lang="zh_TW","Chinese (Traditional Han)",IIf(login.lang="cs","Czech",IIf(login.lang="da","Danish",IIf(login.lang="de","German",IIf(login.lang="en_US","United States English",IIf(login.lang="en_GB","British English",IIf(login.lang="es","Spanish",IIf(login.lang="fr","French",IIf(login.lang="el","Greek",IIf(login.lang="it","Italian",""))))))))))))) as l1, 

IIf(login.lang="ko","Korean",IIf(login.lang="hu","Hungarian",IIf(login.lang="nl","Dutch",IIf(login.lang="pl","Polish",IIf(login.lang="pt_PT","European Portuguese",IIf(login.lang="pt_BR","Brazilian Portuguese",IIf(login.lang="ru","Russian",IIf(login.lang="sk","Slovak",IIf(login.lang="sl","Slovenian","IIf(login.lang="fi","Finnish",IIf(login.lang="sv","Swedish",IIf(login.lang="tr","Turkish","Unknown")))))))))))) as l2, 

IIf(l1="",l2,l1) AS [Language] 
+0

Это ужасное предложение - это хранение данных в вашем SQL-заявлении. -1 –

+1

@ David-W-Fenton: Это зависит от ситуации, у меня была ситуация, когда я был ограничен созданием новой таблицы из-за чрезвычайно сложных условий IIf и других причин. Я дал это предложение, так как в вопросе также упоминается «Я полностью согласен. Список языков должен был быть таблицей в базе данных, а login.lang должен был быть FK в эту таблицу. К сожалению, это не так, база данных была написана, и это не мое изменение ». Прочитайте вопрос полностью, прежде чем судить о чем-то «ужасном» – shibin

+0

Я не вижу причин, по которым исходная база данных должна быть изменена.Количество строк в таблице поиска недостаточно, чтобы вызвать проблему с производительностью, и, конечно же, по сравнению с кодированием значений поиска в SQL, это не могло быть медленнее. –

-1

Если вы не можете использовать таблицу поиска, создать пользовательскую функцию VB, так что вместо 26 заявлений IIF, то есть один вызов функции.