Управление и отладка SQL-запросов в MS Access

Question

MS Access имеет ограниченные возможности для управления необработанными запросами SQL: редактор довольно плохой, нет подсветки синтаксиса, он переформатирует ваш сырой SQL в длинную строку, и вы не можете вставлять комментарии.

Отладка сложных SQL-запросов также является проблемой: либо вы должны разбить его на множество небольших запросов, которыми становится сложно управлять при изменении схемы, либо вы в конечном итоге получаете гигантский запрос, который является кошмаром для отладки и обновления.

Как вы управляете сложными запросами SQL в MS Access и как их отлаживать?

Редактировать
В настоящее время я в основном использую Notepad ++ для некоторой раскраски синтаксиса и SQL Pretty Printer для разумного переформатирования необработанного SQL из Access.
Использование внешнего репозитория полезно, но при этом всегда существует риск нарушения синхронизации двух версий, и вам все равно придется удалять комментарии, прежде чем пытаться выполнить запрос в Access ...

Answer 1

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

По-прежнему основной PITA.

Answer 2

У меня есть несколько советов, специфичных для SQL в VBA.

Поместите ваш код SQL в строковую переменную. Я делал это:

DoCmd.RunSQL "SELECT ..."

С этим трудно справиться. Сделайте это вместо:

strSQL = "SELECT ..."
DoCmd.RunSQL strSQL

Часто вы не можете исправить запрос, если не видите только то, что выполняется. Для этого перед выполнением выведите свой SQL-запрос в Immediate Window:

strSQL = "SELECT ..."
Debug.Print strSQL
Stop
DoCmd.RunSQL strSQL

Вставьте результат в стандартный построитель запросов Access (вы должны использовать Представление SQL ). Теперь вы можете протестировать окончательную версию, включая переменные с кодом.

Когда вы готовите длинный запрос в виде строки, разбейте ваш код:

strSQL = "SELECT wazzle FROM bamsploot" _
      & vbCrLf & "WHERE plumsnooker = 0"

Впервые я научился использовать vbCrLf, когда хотел предварительно обработать длинные сообщения для пользователя. Позже я обнаружил, что это делает SQL более читабельным при кодировании и улучшает вывод с Debug.Print. (Еще одно преимущество: в конце каждой строки не нужно места. Новый синтаксис строки встраивает это в себя.)

(ПРИМЕЧАНИЕ: вы можете подумать, что это позволит вам добавлять комментарии справа от строк SQL. Приготовьтесь к разочарованию.)

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

Рабочий процесс для устранения серьезных проблем:

VBA Debug.Print >       (capture query during code operation)
  query builder   >     (testing lab to find issues)
     Notepad++      >   (text editor for clean-up and review)
  query builder   >     (checking, troubleshooting) 
VBA

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

Answer 3

Я написал Access SQL Editor - надстройка для Microsoft Access - потому что я пишу довольно много сквозных запросов и более сложный SQL в Access. Преимущество этой надстройки заключается в возможности хранить отформатированный SQL (с комментариями!) В самом приложении Access. Когда запросы копируются в новое приложение Access, форматирование сохраняется. Когда встроенный редактор блокирует ваше форматирование, инструмент покажет ваш исходный запрос и уведомит вас о разнице.

В настоящее время он не отлаживается; если бы было достаточно интереса, я бы продолжил это, но в настоящее время набор функций намеренно остается небольшим.

Пока это не бесплатно, но покупка лицензии очень дешевая. Если вы не можете себе этого позволить, вы можете связаться со мной . Существует бесплатная 14-дневная пробная версия здесь .

После установки вы можете получить к нему доступ через меню надстроек (в Access 2010 это Инструменты базы данных-> Добавить надстройки).

Answer 4

Отладка является более сложной задачей. Если один столбец отключен, это обычно довольно легко исправить. Но я предполагаю, что у вас есть более сложные задачи отладки, которые вам нужно выполнить.

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

Затем я проверяю свое предложение WHERE. Я запускаю множество простых запросов к таблицам и к подзапросам, которые я уже проверил или которым я уже доверяю, и проверяю, что при выполнении более крупного запроса я получаю то, что ожидаю, с WHERE условия на месте. Я дважды проверяю условия JOIN одновременно.

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

Затем я проверяю, правильно ли я группирую данные, чтобы убедиться, что "DISTINCT" и "UNION" без UNION ALL не удаляют необходимые дубликаты.

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

---

Одна вещь, которую я мог бы порекомендовать, когда вы пишете свои запросы, это: Никогда не используйте SELECT * в рабочем коде. Выбор всех столбцов таким способом - кошмар обслуживания, и это приводит к большим проблемам, когда ваша основная программа схемы меняются. Вы должны всегда записывать каждый столбец, если вы пишете код SQL, который вы будете поддерживать в будущем. Я сэкономил много времени и усилий, просто избавившись от "SELECT *" в моих проектах.

Недостатком этого является то, что эти дополнительные столбцы не будут автоматически появляться в запросах, которые относятся к запросам "SELECT *". Но вы все равно должны знать, как ваши запросы связаны друг с другом, и если вам нужны дополнительные столбцы, вы можете вернуться и добавить их.

---

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

Answer 5

Если вы выполняете действительно сложные запросы в MS Access, я бы подумал о том, чтобы хранить хранилище этих запросов где-то за пределами самой базы данных Access ... например, в файле .sql, который затем можно редактировать в редакторе. как Intype, который обеспечит подсветку синтаксиса. Вам потребуется обновить запросы в обоих местах, но в итоге вам может пригодиться «официальное» место для него, которое отформатировано и правильно выделено.

Или, если это вообще возможно, переключиться на SQL Server 2005 Express Edition, который также является бесплатным и предоставит вам необходимые функции через SQL Management Studio (также бесплатно).

Answer 6

Расширяя это предложение от Smandoli:

NO:   DoCmd.RunSQL ("SELECT ...")
YES:  strSQL = "SELECT ..."
      DoCmd.RunSQL (strSQL)

Если вы хотите сохранить код SQL во внешнем файле, для редактирования с помощью вашего любимого текстового редактора (с окраской синтаксиса и всем этим), вы можете сделать что-то вроде этого псевдокода:

// On initialization:
global strSQL
f = open("strSQL.sql")
strSQL = read_all(f)
close(f)

// To to the select:
DoCmd.RunSQL(strSQL)

Это может быть немного неуклюжим - может быть, очень неуклюжим - но это позволяет избежать проблем согласованности edit-copy-paste.

Очевидно, что это напрямую не относится к отладке SQL, но управление кодом в удобочитаемом виде является частью проблемы.

Answer 7

Вы говорите здесь о том, что MS-Access называет «запросами», а SQL - «представлениями» или о «сквозных» запросах MS-Access, которые являются запросами SQL? Кто-то может легко потеряться! Мое решение следующее

1. бесплатное управление SQL Server Студия Экспресс, где я буду разработать и проверить мои запросы
2. таблица запросов на клиенте сторона, с одним полем для запроса имя (id_Query) и еще одно (queryText, тип памятки) для сам запрос.

У меня есть небольшая функция getSQLQuery в моем коде VBA, которая будет использоваться, когда мне нужно выполнить запрос (возвращающий набор записей или нет):

Dim myQuery as string, _
    rsADO as ADODB.recorset

rsADO = new ADODB.recordset
myQuery = getSQLQuery(myId_Query)

'if my query retunrs a recordset'
set rsADO = myADOConnection.Execute myQuery
'or, if no recordset is to be returned'
myADOConnection.Execute myQuery

Для представлений их даже можно хранить на стороне сервера и ссылаться на них со стороны клиента.

set rsADO = myADOConnection.execute "dbo.myViewName"

Answer 8

Аналогично рекурсивному, Я использую внешний редактор для написания своих запросов. Я использую Notepad ++ с расширением Light Explorer для поддержки нескольких скриптов одновременно и Notepad2 для одноразовых скриптов. (Я неравнодушен к редакторам на базе Scintilla.)

Другим вариантом является использование бесплатной SQL Server Management Studio Express, которая поставляется с SQL Server Express. (РЕДАКТИРОВАТЬ: Извините, EdgarVerona , я не заметил, что вы уже упоминали об этом!) Обычно я использую его для написания запросов SQL вместо использования Access, потому что я обычно использую ODBC для ссылки в любом случае к SQL Server. Помните, что различия в синтаксисе T-SQL, используемого SQL Server, и Jet SQL, используемого Access MDB, иногда бывают существенными.

Answer 9

Ну, насколько мне известно, есть 2 варианта:

• Блокнот ++ с плагином t-sql для бедного человека. Я знаю, что уже есть упоминание о SQL Pretty Printer, но я его не использовал .. поэтому мой рабочий процесс ... я создаю запрос в Access .. я копирую вставьте его в Блокнот ++ ... я отформатирую это .. я работаю над этим ... вернемся к Access..только выдайте..это в некоторых случаях пробелы в этом случае: [Forms]! [AForm]. [Ctrl] и они становятся [формами]! [AForm]. [Ctrl] но я привык и меня это не беспокоит ..
• SoftTree SQL Assistant (http://www.softtreetech.com/sqlassist/index.htm) приносит почти все, что вы хотели в редакторе SQL ... я немного поработал в прошлом (пробная версия), но его цена немного жесткая

Answer 10

Полагаю, я не пишу сложный SQL, потому что большую часть времени у меня нет проблем с редактором Access SQL. Это связано с тем, что по большей части я использую QBE для написания SQL-кода и погружаюсь только в представление SQL-кода, чтобы выполнять вещи, которые QBE не поддерживает (например, неуравненные соединения, некоторые формы подзапросов, UNION и т. Д.). .). Это не значит, что у меня нет SQL-кода, с которым очень сложно работать, но это в основном потому, что оно написано НЕПРАВИЛЬНО ПЛОХО, а это ошибка my , а не ошибка Access. У меня есть ужасный, ужасный сохраненный QueryDef в приложении, которое работает с 1997 года и имеет SQL, который составляет 11 934 символа. И, да, это неприятно устранять. И почти любое редактирование, которое я делаю, нарушает что-то Но это потому, что ЭТО ПЛОХОЙ SQL.

Почему я не хочу писать свои SQL вручную, как правило. Для всего, кроме самого тривиального SQL, мне кажется, что это больше проблем, чем стоит.

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