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

Вообще почитай о нормализации БД, это крайне полезно. Заведи правило - не работать с БД, пока не приведёшь её к третьей нормальной форме. Потом это войдёт в привычку, втянешься и пойдёт поедет. Бывало по нескольку дней сидишь, но до пятой формы дотянешь :)

> куда вносятся Позывной, Имя, Город, Район, Страна ... <Еще
> некоторые специфические данные>, дале поля Диапазон и Модуляция


Таблица "Страны" -> таблица "Регионы" -> таблица "Районы"-> таблица "Города".
Связаны "один ко многим".

Таблица "Радиолюбители" (
 ID,
 CityID,
 Codename,
 <Еще некоторые специфические данные>
 Диапазон и Модуляция (вполне возможно, что тоже ссылки на справочные таблицы)
)

> Таблица стран, таблица районов, таблица городов, то есть
> 3 таблицы, а не одна.


Да совершенно верно! Я так и предполагаю. Для каждого варианта запроса (т.к. они могут быть ну очень разные) создавать свою таблицу. Т.е. у меня будет грубо говоря award.mdb, содержащий таблицы для каждого варианта запроса или как вариант таблица одна, но ввести поле указывающее к какому запросу относится эти данные. Здесь понятно.

Теперь к конкретике. Я хочу получить статистику по сработанным районам США и Канады. Создаю таблицу с полями Страна, город, район. Вношу в таблицу данные. Ок!
Теперь нужно получить из таблицы связей и этой таблицы итоговую таблицу статистики с полями Страна, Город, Район, Диапазон1..ДиапазонN. В ячейках Диапазон указывается количество связей/количество отправленных запросов на подтверждение/количество полученных подтверждений.
Вопрос: как правильно сформировать запрос?

> Вопрос: как правильно сформировать запрос?


Тебе сначала нужно нормализовать базу.

> Для каждого варианта запроса (т.к. они могут быть ну очень
> разные) создавать свою таблицу.

Ты сам понял что сказал??? Это как??? Таблицы данных создаются один раз потом этими самыми данными заполняются. После этого строишь любые (какие в голову взбредёт запросы) и получаешь результат. НО для этого сначала (с самого начала) вообще забыть о программировании и идти читать о БД (вообще, а не о конкретной СУБД), потом курить SQL (знакомые буквы?). И только после этого пытаться работать с базами. Иначе получится нечто геммороидальное вроде упомянутого КЛАДРа.

> Alex_C   (01.11.11 10:02) [23]

Не парься. Загрузи свою мегатаблицу в Эксель, тыкни в "Автофильтр" и наслаждайся результатом.

А местные гуру тебе ничем не помогут, дельфи отшибает мозги почище водки, многие, кстати, совмещают.

> потом курить SQL


Именно этим сейчас и занимаюсь: Введение в SQL Грабер Мартин.


> А местные гуру тебе ничем не помогут


Зра ты так! Очень даже помогают!

>  Введение в SQL Грабер Мартин.


Хорошая, годная книга.


> Зра ты так! Очень даже помогают!


Don't feed the trolls.

Сейчас для начала разбирательства с SQL сдела пробную программу. Взял с готовой программы базы.
Возник такой вопрос: как между собой связать таблицы, если они находятся в разных MDB файлах?

Директива IN. Сам нашел :)

> Возник такой вопрос: как между собой связать таблицы, если
> они находятся в разных MDB файлах?


Зачем такое извращение???

> Зачем такое извращение???
почему извращение? само по себе вещь полезная, обычный гетерогенный запрос, еще с BDE...
ну к примеру делал так, т.к. у jet-а ограничение на размер, то держал архивы в отдельных базах... ну и т.к. запрос к архивам может "пересечься", и данные нужны в "одним куском" (скажем сегодня и вчера, а вчера это прошлый месяц и его скинули в архив). и что делать? мастрячить доп рекордсет в памяти и туда перекладывать? вот это извращение, а так один запрос, на все про все.

> почему извращение? само по себе вещь полезная


Само по себе - возможно.
Но, насколько я понял, автор отнюдь не архивирование имел ввиду...  :)

> Зачем такое извращение???


Опять же из-за специфики программы: сама база (она максимум тыс 150 записей) должна храниться допустим на флешке. Пользователь установил программу на ноуте, дома на компе. Базу переносит на флешке и работает с ней из разных мест. Это обязательное условие для программы.

> Опять же из-за специфики программы: сама база (она максимум
> тыс 150 записей) должна храниться допустим на флешке. Пользователь
> установил программу на ноуте, дома на компе. Базу переносит
> на флешке и работает с ней из разных мест. Это обязательное
> условие для программы.
>


Это всё понятно. Нахрена каждую таблицу держать в отдельном mdb?

> Базу переносит на флешке и работает с ней из разных мест.
ну подключайся прямо к ней, зачем посредники?

или не умеешь работать/менять настройки в рантайме, всегда подключаешься в "дизайне", и думаешь что так и надо?

> Зачем такое извращение???
ты был прав.

> Нахрена каждую таблицу держать в отдельном mdb?
скажем так, по другому.
1 у тебя есть таблицы такого размера, что не помещаются в 1 mdb?
2 у тебя есть запросы объединения, данных с например справочниками, лежащих в разных базах?
3 и последнее. 2 пункт, если такое есть, оно логически оправдано?

В корне неверный подход к хранению данных!!!
Поверь моему опыту, при таком таскании наступит "светлый" момент, когда ты поймёшь, что изменял данные на одном компе, а на флешку забыл базу сбросить, а потом менял данные на другом компе. В итоге у тебя будет таки две, а то и три базы с разными данными и придётся как то их объединять. Или откажись от таскания всей базы (зачем оно вообще нужно???) или предусмотри способ сливания двух баз в одну.
Базу лучше никогда не таскать в рабочем режиме, только при первой установке, а потом переносить только изменения. В идеале база вообще должна быть одна и в одном месте. Организуй хранилище и используй клиент-серверную технологию, так будет правильнее.

Опять же оговорюсь - с точки зрения программиста то как организовано хранение БД - не правильно согласен. Но есть объективная реальность увлечения радио, накладывающая свой отпечаток. Поверьте мне - таких программ, какую пишу я уже море, существуют они по 20 лет и в итоге пришли к некой идеологии, непонятной программистам, но удобной радиолюбителям. :)


> Поверь моему опыту, при таком таскании наступит "светлый"
> момент


...и он постоянно наступает. :) Для этого в базе у меня предусмотрено не просто копирование таблиц, а именно слияние.


> зачем оно вообще нужно???


Радиоэкспедиция.


> предусмотри способ сливания двух баз в одну.


Это конечно есть. Я писал выше.


> Нахрена каждую таблицу держать в отдельном mdb?


Приехал с радиоэкспедиции - привез свою базу. Нужно слить все данные в "основную" базу на компе дома.


> Организуй хранилище и используй клиент-серверную технологию


Ридоэкпедиции делаются в такие районы, что не то что интернета, даже электричества не бывает :) Какая тут "технология".

А в итоге я разобрался. SQL - как везде написано, очень простой язык запросов. Проблема немного понять его идеологию. Ниже приведу пример, который думаю поможет начинающим в написании сложных запросов.
Специально для себя все по полочам разложит - по моему так более понятно.
Прошу сильно не пиннать :) А замечания приветствуются!




Небольшие пояснения.
LogTable - имя как раз основной базы, где хранятся связи.
[awards.mdb].Diplom - таблица, где хранятся данные по статистике, которую мы хотим получить.
На сейчас остался один момент - [awards.mdb] - это если база хранится в папке программы. А как прописать полный путь к файлу? По разному пробовал - выдает ошибку.