> [77] Anatoly Podgoretsky ©   (02.11.11 23:23)
> > Inovet  (02.11.2011 19:57:13)  [73]
>
> Но в логе чужие позывные, и с каждым может быть любое количество связей

Так лог - это уже, так сказать, рабочая таблица, а справочник позывных - другая. Или о чём ты? Ты сказал, что позывной не уникален. Т.е. сегодня ты провёл связь с неким UA1ABC, а завтра под ним кто-то другой уже работает. Я так тебя понял. Возможные случаи, когда у одного человека разные позывные - допустим, при повышении квалификации, при гнографическом перемещении, допустим, может одновременно несколько быть стационарный и какой-нибудь мобильный. И наоборот на одном позывном разные люди - на коллективных станциях, ещё в каких спец случаях.

Что там в лог пишется, как у автора:
порядковый номер
позывной
имя
диапазон
тип модуляции
время начала связи
время окончания связи
оценка
и т.п.

> Эта... А в чём заключается "примитивность" Access с точки
> зрения теории РСУБД?

Примитивность в данном случае понимается как примитивность использования, а не возможностей. Почему именно ACCESS, если его возможности вообще никак не используются? Для этой задачи, если он выбирает ACCESS, ему Delphi совершенно не нужно, всё можно сделать в нём. Как было правильно замечено, тут даже EXCELя за глаза хватило бы.
Отсюда следует вывод, что выбор СУБД не был ничем обоснован. Просто схватил первое, что под руку попалось, даже на каплю не изучив предоставляемые возможности, удобство использования и накладываемые ограничения. Вот как его суперпрограмма будет работать на компе, где нет офиса, а вместе с ним и дровишек?

> [81] Труп Васи Доброго ©   (03.11.11 08:02)
> Вот как его суперпрограмма будет работать на компе, где
> нет офиса, а вместе с ним и дровишек?

Jet есть везде почти.

Пришел утром на работу. Сижу читаю. Приятно, что нас радиолюбителей все же помнят и знают :)
Чуствую что Inovet свой человек - позывные то привел не случайные :)

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

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

> По этому что получается: основная база-лог - вот она как
> есть, так она и есть. Сама по себе. И поверьте мне - уж
> дума передумал. Никуда ее не нормализуешь.


http://www.gunsmoker.ru/2008/10/x-y-z.html
Засим откланиваюсь.

> [83] Alex_C   (03.11.11 09:04)
> Приятно, что нас радиолюбителей все же помнят и знают :)
>
> Чуствую что Inovet свой человек - позывные то привел не
> случайные :)

Есть здесь на форуме и более опытные, а я немного увлекался в юности.:)

> [83] Alex_C   (03.11.11 09:04)
> Вот эти справочники у каждого человека свои.

Это не столь важно. Смысл в том, чтобы в таблице лог (аппаратный журнал) не хранить непосредственные значения, а хранить ссылки на записи в справочныз таьлицах. Это позволит избежать ввода недопустимых значений, в справочниках можно будет хранить дополнительную информацию менять её при необходимости, не затрагивая лог, будет легче построить выборки в разных разрезах, и т.п..

В интерфейсе заполнение справочников можно сделать достаточно удобным - прямо во время заполнения лога, ну и отдельно, конечно, тоже.

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

> Alex_C  (02.11.2011 17:12:57)  [57]

Два поля лишних - частота и город, первое по сути продублировано диапазоном,
а город не особенно нужен, в основном все рано поле будет пустым, заро не
хватает поля QSL

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


Я конечно понимаю, что профи в программировании БД меня сейчас заклюют, но НЕЛЬЗЯ в данном случае так делать. Почему? Потому что из за специфики хобби НЕТ ПОСТОЯННЫХ справочников.
Привожу пример: человек работает только на УКВ. В справочниках он себе оставил только УКВ диапазоны. Но вот его пригласили поработать радиоэкспедиции. Он там работал на КВ. Приехал - хочет внести свои связи в лог чтобы отписать карточки. А в справочнике нет КВ диапазонов. Запретить ему это делать? Нет конечно. Причем данный пример скорее правило, чем исключение.


> http://www.gunsmoker.ru/2008/10/x-y-z.html
> Засим откланиваюсь.


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

>  но НЕЛЬЗЯ в данном случае так делать.


Давай поспорим, что можно? Что проблема данная решается, легко и непринуждённо?


> [awards.mdb] - это если база хранится в папке программы.
>  А как прописать полный путь к файлу?


Я не понял вопрос.

> Два поля лишних - частота и город, первое по сути продублировано
> диапазоном,


100% с Вами согласен. Но:
1. Многие заносят в лог город того с кем сработал.
2. На счет диапазона и частоты - по началу была только частота - естественно из нее можно получить "диапазон" - текстовое "название" частоты. Ввел диапазон вот по какой причине: при выводе отчета по "диапазону" для каждой связи приходилось пересчитывать частоту в диапазон. При использовании не SQL. Сейчас конечно в этом необходимости нет - при выборке можно указывать BETWEEN для частоты.

> Давай поспорим, что можно? Что проблема данная решается,
>  легко и непринуждённо?


Давай :) Более того: если ты победишь, я буду тебе ОЧЕНЬ признателен. Без каких то шуток. Я пока не могу понять - ну как же это можно реализовать, если справочники не постоянны?


> Я не понял вопрос.


У меня справочники находятся в отдельном MDB файле. Вернее я предполагаю так сделать. Хотя если честно сейчас уже не уверен что это правильно :)
Та вот: мне при JOIN нужно к ним обращаться. (в примере где я процедуру описал.) Так вот : я к ним обращаюсь как [имя файла].имя_таблицы. Но у меня не получается прописать полный путь "имя файла".

> [87] Alex_C   (03.11.11 10:30)
> А в справочнике нет КВ диапазонов.


> [85] Inovet ©   (03.11.11 09:48)
> В интерфейсе заполнение справочников можно сделать достаточно
> удобным - прямо во время заполнения лога, ну и отдельно,
> конечно, тоже.

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

Наверное, нет понимания, как это реализовать удобно в интерфейсе? Так есть поле на форме, только в него вводится не непосредственное значение, а некий код, который может быть и кратким обозначением значения. Если пользователь не помнит код, то жмёт кнопку рядом с полем ввода или на клавиатуре горячюю клавишу, - открывается дополнительная форма со списком всех возможных значенй скажем в гриде. По списку можно сделать быструю навигацию по первым введенным символам, можно сделать более сложный поиск - справичник может быть достаточно большой. Там же можно добавить новое значения если такого ещё не было.

В общем всё стандартно.

> [90] Alex_C   (03.11.11 10:41)
> У меня справочники находятся в отдельном MDB файле. Вернее
> я предполагаю так сделать. Хотя если честно сейчас уже не
> уверен что это правильно :)

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

> [91] Inovet ©   (03.11.11 10:44)
> Наверное, нет понимания, как это реализовать удобно в интерфейсе?

Ну и да. Лог отображать в гриде с расшифрофками кодов или без, все поля или сокращённый набор - можно это в настройки вынести, чтобы пользователь сделал как ему удобно. При редактировании/добавлении записи открывать другую форму - модальный диалог, на которой уже всё в деталях раписано и всё что надо можно отредактировать, выбрать из справочников. Это можно и в гриде сделать, но лучше не надо.

> Давай :) Более того: если ты победишь, я буду тебе ОЧЕНЬ
> признателен. Без каких то шуток.


ТЗ в студию. Будет подробное нормальное ТЗ - за выходные накидаю макет БД.

Заодно будет повод с Access поиграться... :)

> Alex_C  (03.11.2011 10:36:29)  [89]

Надо поле Примечание, куда можно заносить любую не нужную информацию.

Частоту не так легко пересчитать.
3.500, 3.600, 3.800
Нужен ИИ или вхождение в диапазон

> Inovet ©   (03.11.11 10:44) [91]

Справочник хорошо, когда множество ссылок на одну запись, но в данном случае как правило будет всего одна ссылка на одну запись. Не нужна трата ресурсов, усложнение запросов и многое другое
А справочники диапазонов воовсе смешно. 3.5 в текстовом виде три байта, а со справочником id+значение, минимум 7 байт и необходимость делать JOIN
Вместо справочника лучше строить combobox или pickup list
Почему бы не сделать справочник дат и времени тогда, чем они то хуже?

> [97] Anatoly Podgoretsky ©   (03.11.11 11:43)
> А справочники диапазонов воовсе смешно. 3.5 в текстовом
> виде три байта, а со справочником id+значение, минимум 7
> байт и необходимость делать JOIN
> Вместо справочника лучше строить combobox или pickup list

Одно другого не исключает. Новых диапазонов не предвидится кроме пары десятков уже имеющихся, всместо сурогатного ID пользоваться натуральным ключом. Кому мешает справочник.

Про лог надо ТЗ - Нужно ли там фиксировать повторные сеансы связи с одним и тем же респондентом. Вроде все должны фиксироваться. Тогда справочник, а интерфейсно сделать так же неотличимым от прямого указания позывновго, + будут бонусы в виде уже оговаривавшихся, хотя может бонусы и нафиг не нужны. И сдаётся мне, что должна где-то быть база позывных не только на бумажных носителях.

Отметку об отправленном полученном QSL в логе на каждый сеанс или в справочнике с позывними или там и там.

> Inovet  (03.11.2011 12:07:38)  [98]

По правилам, все связи должны фиксироваться в обязательном порядке
QSL это подтверждение связи, поэтому она должна быть полем, при том поля
два - об отправке и об получение. Справочник здесь вовсе не у дел.