Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Реляционный доступ к БД ADO на основе ADOQuery  (Прочитано 15915 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Samouch
Гость
« : 27-02-2006 14:05 » 

Помогите! Пожалуйста! Описываю проблему: есть БД в Acces, в ней две таблицы (примеры упрощаю) 1-Prepod, 2-Disciplina. В таблице Prepod поле Фамилия и поле УК явл. уникальным ключом. Во второй таблице поле Disciplina и УК явл. внешним ключом на таблицу Фамилия. Бросил я на форму компоненты  DBgrid и ADOQuery. В ADOQuery.SQL прописываю инструкцию которая делает запрос в БД, в результате возвращается набор данных который является соединением двух таблиц. Это отображается в DBGrid, т.е. два связанных поля с двух таблиц. ПРОБЛЕМА:  запускаю: пытаюсь отредактировать записи поля второй таблицы в DBGrid, а он не дает, мол уникальный ключ не может определить. Почему когда с DBGrid связываешь набор данных из одной таблицы редактирование возможно, а когда соединяешь таблицы в одну-проблемы? Как ее обойти?  Не понял
Записан
Oldy
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 27-02-2006 17:36 » 

Точно не помню, но кажется что из ADOQuery это сделать нельзя (ограничения на Life query). Может быть лучше редактировать переменные в дополнительной форме и делать Update?
Записан

С уважением, Oldy.
Samouch
Гость
« Ответ #2 : 27-02-2006 18:25 » 

Ограничение там действительно есть. По литературе "редактируемый набор данных можно получить в случае если не применяется соединение таблиц". Неужели выход только: печатать дополнительный код. Мне бы хотелось дополнительно использовать компонент DBCtrlGrid, его уникальность в том что можно организовать удобный интерфейс для выбора значения логического поля, т.е. DBCheckBox. А если создать дополнительную форму необходимо  как-то отобразить связь между двумя таблицами, а это и есть дополнительный код, который хотелось бы избежать.
Записан
Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 03-03-2006 15:25 » 

Чушь, все должно прекрасно работать!!
Сам работал с АДО-компонентами и Акцессом. Редактировал запросы на основе нескольких таблиц и в стандартном ГРИДе.
Ошибка возможно в самой постановке запроса или БД.
Афтар, приведи пожалуйста структуру таблиц этих и сам запрос SQL - будет признательно тебе общество, да и ответ получится детальней!!
Записан

Ёжики, это не только ценные шкурки...
Samouch
Гость
« Ответ #4 : 03-03-2006 20:38 » 

Люди я нашел свою ошибку. Сравнивал с одним примером и понял что проблема в проектировании БД. Оказывается во второй таблице в обязательном порядке необходимо было создать какое-либо ключевое поле. Эта таблица была последней в связях, и я решил там ключ не создавать. А когда создал, все проблемы отпали. Хотя с другой стороны не понимаю зачем в книгах пишут что "редактируемый набор данных можно получить в случае если не применяется соединение таблиц". Тем не менее это уже не важно проблема решена.
С уважением, Samouch
Записан
Samouch
Гость
« Ответ #5 : 03-03-2006 20:43 » new

Запрос все таки напечатаю, вдруг кому-то пригодиться:

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('select Фамилия, Дисциплина');
ADOQuery1.SQL.Add('from Преподаватели inner join Дисциплины on Преподаватели.Ук_преп = Дисциплины.Ук_дисциплины');
ADOQuery1.Active:=true;
 
« Последнее редактирование: 20-12-2007 16:12 от Алексей1153++ » Записан
Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 07-03-2006 15:44 » 

Ну-у, запрос-то вряд-ли пригодиться. Обычная выборка, вот если -бы хитрая была!!
Помню, трахались над задачей - все понятно как должно быть, а просто не решалось. Тут администратору БД пожаловались, а он в SQL-е по долгу службы рубить должон. Он и выдал заковыристый запрос. Тогда все встало на свои места.
П.С. Проблема была просто в том, что у тебя не было однозначной идентификации данных в случае перекрестного запроса.
Записан

Ёжики, это не только ценные шкурки...
Samouch
Гость
« Ответ #7 : 08-03-2006 12:21 » 

Igel писал: Ну-у, запрос-то вряд-ли пригодиться. Обычная выборка, вот если -бы хитрая была!!

Я упростил пример (имею ввиду таблицы и запрос) в своем вопросе, чтобы не отвлекать внимание от  темы-вопроса. Да и название таблиц и полей привел такие чтоб легче было понять, но они аналогичны по связям в упрощенном варианте настоящим таблицам, с которыми надо работать.
С уважением, Samouch.
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines