Как уже упоминалось, чтобы проверить, использует ли ADO, вы, как правило, можете посмотреть в своем коде. Однако, что, вероятно, сбивает вас с толку и не объяснили, так это то, что вы выбираете ADO или DAO ТОЛЬКО в ваших методах кодирования.
Для остальной части приложения (например: ВСТРОЕНО В ОБЪЕКТАХ) вы будете использовать концепцию так называемых связанных таблиц. Эти связанные таблицы обрабатывают все строки подключения и все внутренние операции для вас. Никаких дополнительных усилий со стороны пользователя при разработке приложения не требуется. Для всех этих внутренних объектов вы не выбираете конкретный тип объекта данных (ADO или DAO).
Это означает, что для заполнения данных в формах, данных в отчетах, данных в списках, данных в полях со списками и т. Д. Вы НЕ пишете код и НЕ используете строки подключения. И у вас нет выбора ADO или DAO. Это означает, что когда вы смотрите на поле со списком, поле со списком или форму, вы очень быстро выходите из замешательства, если начинаете искать какой-либо тип строки соединения или спрашиваете, основано ли это поле со списком на ADO или DAO ( подсказка: у вас, как правило, нет выбора в этом вопросе: все эти объекты и то, как они работают, автоматически обрабатываются для вас внутри доступа MS). Это означает, что все, что вам нужно сделать, предоставить данному объекту некоторый SQL, и все готово.
Итак, все эти объекты, как правило, будут работать из ваших связанных таблиц в доступе. После настройки этих связанных таблиц вы создаете формы, отчеты или списки на основе этих связанных таблиц. В результате, как уже упоминалось, вы не будете выбирать (или даже не будете беспокоиться) с DAO или ADO при работе с этими объектами.
Выбор ADO или DAO. Обычно мы вступаем в игру только в том коде, который открывает набор записей или напрямую запрашивает. Большая часть кода в форме может основываться на ссылках на элементы управления или объекты, такие как поле со списком, которые существуют в этой форме. Еще раз выбор ADO или DAO не имеет значения, и вы не можете контролировать этот аспект.
Например, если вы хотите использовать код для настройки значений для поля со списком, вы должны использовать следующий код: (мы предполагаем, что поле со списком представляет собой поле со списком из двух столбцов, 1-й столбец - это id (скрытый), а 2-й - название компании в колонке.
Код VBA для заполнения или настройки поля со списком через sql:
Me.Mycombobox.RowSource = "выберите идентификатор, имя_компании из tblCustomers"
Вот и все!
Заметьте, что нет ни строк подключения, ни наборов записей, вы просто добавили чистый SQL прямо в источник строки поля со списком и все готово.
Теперь, конечно, вышеизложенное предполагает, что у вас есть связанная таблица с именем "tblCustomers". Вы можете просмотреть / просмотреть эти таблицы на вкладке таблиц.
(Кстати, наши поля со списком и списком позволяют более двух столбцов, чтобы скрыть столбцы, вы устанавливаете формат длины равным нулю для этого столбца. Таким образом, вы все равно можете получить доступ к данным в вашем коде, но не иметь этого столбец отображается в списке).
Так что выбор ADO / ADO часто не является проблемой. Обратите внимание, что даже когда вы выбираете ADO или DAO в своем коде, вы, как правило, должны использовать встроенные объекты таблиц, и это снова не будет беспокоить строку подключения, встроенную в код. Здесь есть некоторые исключения, но давайте пока оставим это общее.
Вышесказанное должно прояснить многие ваши вопросы о том, почему вы не можете видеть или рассказать, как форма использует DAO или ADO (ответ - вы не беспокоитесь об этом, а ответы - нет. у вас есть выбор, и ответ таков: все это автоматически обрабатывается для вас с помощью MS access)
2.У меня есть вещи в списке, как я могу использовать метод .GetRows, чтобы поместить набор записей в двумерный массив?
По какой причине вы хотите сделать выше? Существует ОЧЕНЬ небольшая причина для извлечения данных из списка в массив. У вас есть список со списком УЖЕ загружен данными, так зачем тогда тратить время на загрузку этих данных в массив? По какой причине вы бы это сделали?
Вы можете ссылаться на данные в этом списке, но, возможно, вы захотите объяснить, что вы пытаетесь сделать здесь. Нет необходимости извлекать данные из списка, но вы можете использовать код в форме для просмотра значений, выбранных в списке, и делать полезные вещи с этими сделанными выборами. Опять же, для работы с выбранными данными из этого списка вам не нужен массив, вам не нужны строки подключения, и вам не нужно писать целый набор кода, чтобы повторить то, что наши данные каррируют и доступны внутри этой формы (подсказка: данные внутри этого списка доступны для вас как коллекция).
Так что вам не нужен набор записей, вам не нужно писать целый набор кода, а также вам не нужны некоторые строки подключения. И вам не нужно и не нужно извлекать эти данные из этого списка в массив, это просто не требуется и полностью излишне. Просто оставьте то, что вы пытаетесь сделать с этим списком, и мы найдем решение, которое, вероятно, будет состоять всего из нескольких строк кода.
Как уже упоминалось, посмотрите на эту вкладку данных списка и посмотрите на SQL, используемый для заполнения этого списка. Правильно ли работает этот sql, и, кроме того, проверка количества столбцов, указанных в списке, соответствует количеству столбцов, которые есть в вашем SQL, которые установлены для этого списка на вкладке данных. Забавные вещи могут случиться, если количество столбцов не совпадает с настройками количества столбцов в списке.