Что является лучшей практикой: сложные операторы SQL или манипуляции с набором записей в Access VBA? - PullRequest
1 голос
/ 10 марта 2010

Я занимаюсь разработкой VBA и обнаружил, что создание SQL-кода - это достаточно эффективный способ сделать все (выбор и обновление). Но я дошел до этой стадии, когда мои операторы SQL содержат сложные переключатели и условия WHERE, где у меня есть другой выбор для обновления соответствующих записей. Поэтому я создаю этот SQL и просто запускаю его через «CurrentDb.Execute strSQL», и он все делает нормально.

Вопрос в том, зачем мне объявлять ADODB.connections и т. Д., Устанавливать наборы записей, проходить через них и манипулировать данными по одному?

Ответы [ 3 ]

2 голосов
/ 10 марта 2010

зачем мне объявлять ADODB.connections и т. Д., Устанавливать наборы записей, проходить через них и манипулировать данными по одному?

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

Если бы вы использовали базу данных SQL Server в качестве бэкэнда, это имело бы значение.

В любом случае, если ваш SQL становится слишком сложным для понимания (вам нужно будет прочитать его позже !, не так ли?), Тогда вы действительно можете разбить его на более мелкие цепочки и функции.

0 голосов
/ 15 марта 2010

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

Если требования известны, и SQL работает, то нет никакой реальной причины для преобразования.

0 голосов
/ 11 марта 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...