Почему вот так


и вот так


работает, а при попытке указать полный путь к файлу БД нет?

потому что
http://msdn.microsoft.com/en-us/library/bb177907(v=office.12).aspx

Вот зачем ты в разные базы рассовываешь всё? Делай в одной. Лучше сделай экспорт импорт для обмена хоть в текстовом формате.

> а при попытке указать полный путь к файлу БД нет?
там наверняка двоеточие есть...

а вообще это карма. не слушаешь, что тебе говорят о подобной логике... :)

> разные базы рассовываешь всё? Делай в одной.


Почему все в разные? у меня всего их 2 :) БД будет. И кстати по ТЗ только так и получается.


> потому что


Tnx!

> [5] Alex_C   (07.11.11 13:43)
> И кстати по ТЗ только так и получается.

Зеачит ТЗ переделать.

> Вот зачем ты в разные базы рассовываешь всё?


Вот знаешь убедил ты меня :) Хочу теперь все что можно в одну БД засунуть.
Однако появилась такая проблема: пользователь хочет завести себе новую отдельную БД (за чем это надо - уже в соседней ветке объяснял.) Вопрос: как при создании этой БД скопировать в нее "справочные" таблицы?

Вот моя мысль какая: я создал некую template.mdb - где есть готовые справочные таблицы. Потом создаю новую БД и в нее копирую все справочные таблицы. Вот такой вариант нормально?

> Alex_C  (10.11.2011 09:51:07)  [7]

замучаешься ты с разными базами. Особенно с запросами.

> [7] Alex_C   (10.11.11 09:51)
> Вот моя мысль какая: я создал некую template.mdb - где есть
> готовые справочные таблицы. Потом создаю новую БД и в нее
> копирую все справочные таблицы. Вот такой вариант нормально?

Нормально. Только зачем копировать: поставляй базу с некоторыми заполненными справочниками и пусть пользователь с ней дальше работает. А я бы сделал ещё экспорт импорт в какой-нибудь универсальный формат, в текстовый CSV например, или XML. Но это на потом можешь оставить, если понадобится такое.

> поставляй базу с некоторыми заполненными справочниками


Я не правильно написал. Имелось ввиду что я заранее сам создал БД со справочными таблицами и с этой БД я программу и буду поставлять пользователю. Вот и при создании новой БД из "исходной БД" буду копировать справочные таблицы.


> замучаешься ты с разными базами. Особенно с запросами.


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

Большое спасибо всем за советы - очень помогают!

Кстати: как я понял в SQL нет (?) оператора, позволяющего копировать таблицы? Или плохо искал? Интересует 2 варианта: копирование только структуры и копирование вместе с данными.

> [10] Alex_C   (10.11.11 11:06)
> Имелось ввиду что я заранее сам создал БД со справочными
> таблицами и с этой БД я программу и буду поставлять пользователю.
> Вот и при создании новой БД из "исходной БД" буду копировать
> справочные таблицы.

Я понял. Я говорю - зачем копировать записи из одной базы в другую, когда можно эту template.mdb скопировать как файл в Base1.mdb Petya.mdb Vasya.mdb, программе при запуске выбрать нужную или в коммандной строке указать, и сформировать строку подключения. Про экспор импорт уже дважды писал. И не храни их в "Program files", есть для этого профили пользователя и вних папки для данных.

> [10] Alex_C   (10.11.11 11:06)
> БД рабочая - будет одна. Просто пользователь сможет выбирать,
> от куда ее брать.

Это не понятно. Что значит одна, но брать её из другой.

> [11] Alex_C   (10.11.11 11:13)
> Кстати: как я понял в SQL нет (?) оператора, позволяющего
> копировать таблицы?

Потому что при правильном проектировании копировать таблицы не нужно. А при правильном есть

> при правильном проектировании


Есть такая задача: в одной БД несколько таблиц лога.
Вот задача: в этой же БД создать новую пустую таблицу. SELECT - это копирование. А вот пока до создания - не понял как.


> Это не понятно. Что значит одна, но брать её из другой.


Не понял меня: пользователь должен в случае необходимости выбирать ФАИЛ (именно фаил!!!) БД! А вот потом уже именно с ней и работать.

> до создания


Ну не делать же CREATE TABLE? Или все время делать?

> [16] Alex_C   (10.11.11 13:18)
> Ну не делать же CREATE TABLE? Или все время делать?

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

> Я не понял хачем надо несколько логов


Поясню. Хем едет в экспедицию. Есть ноут и моя программа. Он по каким то соображениям хочет сделать новую отдельную БД (фаил!!!) у себя на флешке, чтоб потом ее сихронизировать с основным логом.
База - не проблем - просто копирование из template. Теперь он хочет завести новую таблицу. Я вот пока чего не нашел: как сделать новую таблицу (пустую) с нужными полями? В БД "образец" таблицы есть - все что нужно - скопировать структуру таблицы в новую. Вот как то так)))

> [18] Alex_C   (10.11.11 14:06)
> Теперь он хочет завести новую таблицу.

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

Я пытаюсь объяснить, что изменение структуры БД должно быть только при изменениях функциональности, иначе это ошибка проектирования. Поэтому и команды нет такой на клонирование таблиц.

Что до описанной ситуации. Пусть работает с пустой базой, дома импортирует в основную, сама задача импорта может оказаться не такой уж и простой, точно сложнее простого копирования. Соответсвующий функционал должен быть предусмотрен в программе.

И все же вопрос открыт: как скопировать одну таблицу в другую при условии при копировании создать таблицу?

SELECT INTO

> SELECT INTO


Я это еще не пробовал - пока и так переделок хватает - извини за еще раз тупой вопрос - даже если таблицы нет это сработает?

Попробовал. Не работает


если NewTable  не существует.

> [22] Alex_C   (10.11.11 18:29)
> даже если таблицы нет это сработает?

Про jet не знаю, а вообще да.

> [23] Alex_C   (10.11.11 18:37)
> INSERT INTO

Это не то, читай внимательно.

Бесперспективно..

> Бесперспективно..


Очень глубокая мысль :)


> вообще да.


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


открываю таблицу в Access'е - Конструктор - а поля у меня индексными не становятся?

не знаю почему не становятся... может показанное не выполняешь, может ошиьбку игнорируеш, а может смотришь не там/не то, хотя оно становится...
но!
индекс по
> Call, DateQSO, TimeQSO, Mode, BandADIF, State, County, Country
такой куче полей, ИМХО, бесполезен.

> не знаю почему не становятся...


Комманда отрабатывает - если не верно указать - то ругается. Смотрю в самом Access'е в конструкторе таблиц.


> Call, DateQSO, TimeQSO, Mode, BandADIF, State, County, Country


Кстати вот тоже момент который мне интересен - по всем данным полям мне нужна и выборка и сортировка. А почему тогда не стоит их в индекс заносить?

> [29] Alex_C   (11.11.11 14:40)
> по всем данным полям мне нужна и выборка и сортировка

Значит разные индексы делай. Так как сделано у тебя оптимизатор сможет использовать индекс только при сортировке


а вот для например


уже не сможет. Поэтому делай индексы по последовательностям полей наиболее часто встречающиеся в сортировке. Лишние делать тоже ни к чему.

Ещё. Зачем отдельно DateQSO, TimeQSO - надо бы одним полем, если действительно не нада отслеживать отдельно время от даты.

> [27] Alex_C   (11.11.11 11:13)
> В общем сделал проще - да бы ручками не описывать всю структуру
> таблицы сдал программку, которая это за меня делает.

Ну так что, в Jet не работает?

Спасибо за разъяснение!
Появился следующий момент - мне нужно узнать, есть ли такая страна в логе и если да, то на текущем диапазоне и с текущей модуляцией сработана и подтверждена ли.
Есть несколько вариантов  реализации. Самый простой




Однако другой вариант - делать отдельно запросы


Далее такой же запрос по модуляции и подтверждению.
Вопрос: как более правильно сделать?

> Alex_C  (11.11.2011 11:13:27)  [27]

Если ошибки не выдает, то тогда индекс просто безумный и не нужный такой
индекс

Интересно, что скажет начальник транспортного цеха?

> не нужный такой


С этим разобрался - сделал 3 отдельных индекса по Country, Call, State

> [32] Alex_C   (11.11.11 15:57)
> Появился следующий момент - мне нужно узнать, есть ли такая
> страна в логе и если да, то на текущем диапазоне и с текущей
> модуляцией сработана и подтверждена ли.



Вот не слушешь ты советы по нормализации и применению справочников... Ну кто страну хранит в логе её названием. Ладно там про диапазоны и модуляции тебя убедили отказаться от справочноиков, а зря.
Читай вот хотя бы про страны
http://ru.wikipedia.org/wiki/%CE%E1%F9%E5%F0%EE%F1%F1%E8%E9%F1%EA%E8%E9_%EA%EB%E0%F1%F1%E8%F4%E8%EA%E0%F2%EE%F0_%F1%F2%F0%E0%ED_%EC%E8%F0%E0

> Alex_C  (11.11.2011 16:44:35)  [35]

Заработало? Тогда слишком сложный индекс

> Inovet  (11.11.2011 17:04:36)  [36]

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

> [38] Anatoly Podgoretsky ©   (11.11.11 17:41)
> Просто будут потери места и производительности.

Я повторять не буду как сделать без потери. С хранением кода страны в логе и справочником стран мира ты, надеюсь, согласен?

И таки автор плодит логи в одной базе.

> [32] Alex_C   (11.11.11 15:57)

Ну и параметры в запросе можно использовать. Это здесь не критично, а на будущее.

> Ну кто страну хранит в логе её названием.


"Название" страны - это максимум 4(!!!) буквы! Название России - R, США - W, Германии - DL. Согласить, куда как проще и быстрее в хранить в логе само название, чем ссылку на это название. А вот все остальные данные как раз по стране (а их там много) хранятся в отдельном справочнике. Так что тут как раз все весьма верно.


> q.SQL.Text := 'SELECT COUNT(*) FROM log WHERE Country =
> ''Ямайка''';
> q.Open()
> if q.Fields[0].AsInteger > 1 then
> begin
>  q.SQL.Text := 'SELECT BandADIF, Mode WHERE Country = ''Ямайка''
> AND BandADIF = 3.5 AND Mode = 'SSB''
>  // тут показываем
> end


Да я как раз так и предполагал. Думаю будет самый быстрый вариант. Хотя тут есть некоторый нюанс - но сегодня все испробую и потом про него напишу уже более подробно.


> убедили отказаться от справочноиков


Почему же? По диапазонам и модуляциям справочники остались. Только они не по ссылкам, а по названиям полей (не уверен , что правильно выразился.)
Допустим в логе модуляция SSB, в справочнике
SSB - PHONE ... там еще некоторые данные. Учитывая какие эти справочники маленькие, так самое простое получается.


> не слушешь


Зря. Очень даже слушаю.

> [41] Alex_C   (14.11.11 10:02)
> "Название" страны - это максимум 4(!!!) буквы! Название
> России - R, США - W, Германии - DL. Согласить, куда как
> проще и быстрее в хранить в логе само название, чем ссылку
> на это название.

Так это и есть ссылка на справочник. Осталось добавить внешний ключ и будет автоматическая проверка и прочие возможности.

Ну и уже хранить лучше общепринятые сокращения см справичник по ссылке выше. 2 или 3 символьный код, или, если хочется R W DL, то так закодировать, но это уже не относится к целостности данных.

РОССИЯ Российская Федерация RU RUS 643
СОЕДИНЕННЫЕ ШТАТЫ Соединенные Штаты Америки US USA 840
ГЕРМАНИЯ Федеративная Республика Германия DE DEU 276

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

> [41] Alex_C   (14.11.11 10:02)
> Только они не по ссылкам, а по названиям полей (не уверен
> , что правильно выразился.)
> Допустим в логе модуляция SSB, в справочнике
> SSB - PHONE ... там еще некоторые данные.

Это те же ссылки, принципиальной разницы нет - число там или строка.

Если ещё не советовали, то рекомендуется пользоваться TADODataset для возвращающих набор запросов и TADOCommand для остальных вместо TADOQuery, и сосвем никогда не пользоваться TADOTable.

> TADODataset для возвращающих набор запросов и TADOCommand


Да только их и использую - это уже понял. :)

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




И все было нормально, но теперь RecNo = -1 не только у первой записи, но и у последней. Это почему так? Это поле вроде как и не нужно - в зависимости от сортировки оно естественно тоже меняется, но иногда оно полезно!

> И все было нормально, но теперь RecNo = -1 не только у первой
> записи

А что раньше у "первой" записи всегда было RecNo = -1?
Ну некоторые предпочитают считать от 0, некоторые от 1. Но не знаю таких, которые считают от "-1"! :)

P.S. Забудь также про RecNo.

> А что раньше у "первой" записи всегда было RecNo = -1?


Я пользовался VolgaTable, и чтоб номер записи у последней записи высвечивался верно, приходилось вот так изголяться.

Подошел сейчас к одной из ответственных задач в своей программе - работа Thread + ADO. По идее я так понимаю особых проблем быть не должно.

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

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


Однако не верно
http://www.delphimaster.net/view/2-1277129198
в [3] объяснено почему!