Форум программистов, компьютерный форум, киберфорум
Наши страницы
Delphi: Базы данных
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.95/21: Рейтинг темы: голосов - 21, средняя оценка - 4.95
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
1

Delphi + MS Access

03.02.2012, 21:30. Просмотров 3784. Ответов 28
Метки нет (Все метки)

Доброго времени суток, уважаемые форумчане.
Появилась идея, но нет мыслей для ее реализации.
Суть в следующем. Пишется программа для учета в сервисном центре. Оболочка пишется на делфи, база данных - ms access.
Есть таблица, в которую будут вносится сведения о принятых комплектующих.
У каждой записи будет уникальный номер (поля ID с типом - счетчик).
Для идентификации неудобно использовать это поле - мало информативности.
Было решено добавить новое поле, которое тоже будет иметь уникальное значение. Поле будет числового типа. Формат поля будет - "год""номер недели""хх", где хх - 01, 02 и так далее.
Как сделать так, чтобы эти самые хх каждую неделю начинали счет с нуля..
Натолкните, пожалуйста, на мысль..
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
03.02.2012, 21:30
Ответы с готовыми решениями:

SQL-запрос в Delphi и в Access один и тот же, но в Delphi не работает
ри обращение к базе в Access я использую код: with ADOQueryMain do begin...

Delphi и Access
как сделать так чтобы в одной форме загружались несколько таблиц созданные в...

БД Access и Delphi
Здравствуйте. Подскажите пожалуйста можно ли местами поменять строки в БД...

БД MS Access в Delphi
Эту задание я не понимаю как осушествить программу на форму есть готовый...

Delphi и БД Access
Всем доброго времени суток! Кто может подсказать? Выполняю обращение к...

28
xxbesoxx
Эксперт Pascal/Delphi
1017 / 534 / 110
Регистрация: 13.02.2009
Сообщений: 3,077
04.02.2012, 00:53 2
Цитата Сообщение от SevereK20 Посмотреть сообщение
Доброго времени суток, уважаемые форумчане.
Появилась идея, но нет мыслей для ее реализации.
Суть в следующем. Пишется программа для учета в сервисном центре. Оболочка пишется на делфи, база данных - ms access.
Есть таблица, в которую будут вносится сведения о принятых комплектующих.
У каждой записи будет уникальный номер (поля ID с типом - счетчик).
Для идентификации неудобно использовать это поле - мало информативности.
Было решено добавить новое поле, которое тоже будет иметь уникальное значение. Поле будет числового типа. Формат поля будет - "год""номер недели""хх", где хх - 01, 02 и так далее.
Как сделать так, чтобы эти самые хх каждую неделю начинали счет с нуля..
Натолкните, пожалуйста, на мысль..
Не как, поля ID с типом - счетчик если не хочешь что било видно можно Visible -False
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 00:58  [ТС] 3
xxbesoxx, Отличный ответ. Тип поля можно поменять при желании обойтись без дополнительного.
Пускай ID будет числовым типом.
0
xxbesoxx
Эксперт Pascal/Delphi
1017 / 534 / 110
Регистрация: 13.02.2009
Сообщений: 3,077
04.02.2012, 01:19 4
Цитата Сообщение от SevereK20 Посмотреть сообщение
xxbesoxx, Отличный ответ. Тип поля можно поменять при желании обойтись без дополнительного.
Пускай ID будет числовым типом.
Через Delphi используешь ADOConnection1, DBGrid1, ADOTable1, ADOTable1 потом на ADOTable1 добавляешь все поля и потом отдаешь Viseble -False

Тип поля можно поменять при желании = Можно , Но лучи вы сначала определитесь какой тип поля нужно ! ну как тебя сказать начинаите работа и увидишь если что то проблема пишите суда мы поможем если увидим что ты развиваешся
0
Миниатюры
Delphi + MS Access  
MsGuns
535 / 535 / 57
Регистрация: 04.04.2011
Сообщений: 2,002
04.02.2012, 01:22 5
Вы не с того начинаете. Прежде чем приступать к созданию таблиц и определению колонок, нужно
1) Хотя бы в общих чертах описать ЗАДАЧУи ЦЕЛЬ, которую Вы преследуете своей программой (у профи это называется "постановка задачи"
2) Описать объекты реальной жизни (документы, события, предметы), информация о которых будет накапливаться в БД, причем как можно подробнее
3) Увязать объекты между собой, определив логические связи между ними (зависимости или на языке профи - "констрэйнты"
4) На основании собранной и систематизированной информации составить модель базы данных, представив объекты и связи между ними графически (акцес предоставляет для этого инструменты)
5) Убрать повторения, заменив их ссылками на справочники (на жаргоне профи - нормализовать базу)

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

И помните, что пренебрежение перечисленными делами ведет к 100% гарантии коренной переделки не только базы, но и программ при первых же попытках эксплуатации в реальных условиях.
А это, поверье, куда "трудоемчее" и "глюкоопаснее"
0
xxbesoxx
Эксперт Pascal/Delphi
1017 / 534 / 110
Регистрация: 13.02.2009
Сообщений: 3,077
04.02.2012, 01:27 6
Цитата Сообщение от MsGuns Посмотреть сообщение
Вы не с того начинаете. Прежде чем приступать к созданию таблиц и определению колонок, нужно
1) Хотя бы в общих чертах описать ЗАДАЧУи ЦЕЛЬ, которую Вы преследуете своей программой (у профи это называется "постановка задачи"
2) Описать объекты реальной жизни (документы, события, предметы), информация о которых будет накапливаться в БД, причем как можно подробнее
3) Увязать объекты между собой, определив логические связи между ними (зависимости или на языке профи - "констрэйнты"
4) На основании собранной и систематизированной информации составить модель базы данных, представив объекты и связи между ними графически (акцес предоставляет для этого инструменты)
5) Убрать повторения, заменив их ссылками на справочники (на жаргоне профи - нормализовать базу)

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

И помните, что пренебрежение перечисленными делами ведет к 100% гарантии коренной переделки не только базы, но и программ при первых же попытках эксплуатации в реальных условиях.
А это, поверье, куда "трудоемчее" и "глюкоопаснее"
всё правильно
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 01:30  [ТС] 7
xxbesoxx, да Вы шутите
Я же прошу подкинуть идею, а не реализацию идеи. Я в курсе что такое ADO и компоненты ADO.
На данный момент мне в голову пришла следующая идея.
Решил не мудрить с дополнительными полями, а присвоил ID тип числовой - длинное целое.
Год... насчет года никаких проблем, насчет номера недели - тоже самое. Проблема с номером заказа. Так как каждую неделю нумерация заказов должна начинаться заново.
На данный момент решение этой проблемы представляю следующим образом -
Создать отдельную таблицу с двумя полями - CurrentWeek и CurrentNumber
Перед каждым запросом на добавление проверять текущую неделю с CurrentWeek и если они <>, то присваивать CurrentWeek новое значение и обнулять CurrentNumber. Если значения не отличаются - номером заказа служит CurrentNumber+1, и в CurrentNumber после запроса заносится увеличенное на 1 значение. Этот способ работает, но его громозкость очевидна...
Вот и спрашиваю про другие идеи. Натолкните на мысль, с реализацией я сам справлюсь.

Добавлено через 2 минуты
MsGuns, я в курсе.. в базе уже порядка 15 таблиц, почти все из которых связаны друг с другом и привидены к "нормальным формам".
0
MsGuns
535 / 535 / 57
Регистрация: 04.04.2011
Сообщений: 2,002
04.02.2012, 01:35 8
Вот это:
Delphi
1
Было решено добавить новое поле, которое тоже будет иметь уникальное значение. Поле будет числового типа. Формат поля будет - "год""номер недели""хх", где хх - 01, 02 и так далее.
в топку !
Вот видите, Вы уже 15 таблиц создали, полдома построили, а вместо фундамента - лужи и грязь.
По теме почитайте Создание нового месяца..... и подумайте
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 01:36  [ТС] 9
MsGuns, почитайте предыдущий пост. Я быстро понял абсурдность этой идеи...за ссылку спасибо, изучаю
0
MsGuns
535 / 535 / 57
Регистрация: 04.04.2011
Сообщений: 2,002
04.02.2012, 01:42 10
Да, кстати, в ADO использовать только
- TADOConnection: для установления соединения (логин), централизации интерфейса с БД, управления транзакциями,
- TADODataSet: для отбора записей из БД для отображения либо обработки данных на клиенте,
- TADOCommand: для изменений в таблицах, прогоне монолитных блоков запросов (скриптов)

Все остальное, включая специально созданный для чайников-локальщиков TADOTable - в топку !

Добавлено через 55 секунд
Delphi
1
почитайте предыдущий пост
Есть грех - пропустил
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 01:45  [ТС] 11
MsGuns, по ссылке - не это совсем.
Попробую более подробно изъясниться. Есть таблица - Заказы.
При принятии нового заказа в нее добавлются записи, каждая из которых имеется уникальный ID.
Задача - сделать поле ID не тупо счетчиком, а несущим в себе определенную информацию, а именно - год и неделю приема изделия + номерзаказа в этой недели.
Т.е. сейчас 12 год и 5 неделя года - получается - 120501, 120502, 120503 и так далее...
в 6 месяце - 120601, 120602 и так далее... поле будет ключевым. Совпадений не будет, точнее появятся только в 2112 году. Основной вопрос - продумать автоматическое обнуление номера заказа каждую неделю.
P.s. использую ADOQuery для выборки.
0
xxbesoxx
Эксперт Pascal/Delphi
1017 / 534 / 110
Регистрация: 13.02.2009
Сообщений: 3,077
04.02.2012, 01:48 12
Цитата Сообщение от SevereK20 Посмотреть сообщение
xxbesoxx, да Вы шутите
Я же прошу подкинуть идею, а не реализацию идеи. Я в курсе что такое ADO и компоненты ADO.
На данный момент мне в голову пришла следующая идея.
Решил не мудрить с дополнительными полями, а присвоил ID тип числовой - длинное целое.
Год... насчет года никаких проблем, насчет номера недели - тоже самое. Проблема с номером заказа. Так как каждую неделю нумерация заказов должна начинаться заново.
На данный момент решение этой проблемы представляю следующим образом -
Создать отдельную таблицу с двумя полями - CurrentWeek и CurrentNumber
Перед каждым запросом на добавление проверять текущую неделю с CurrentWeek и если они <>, то присваивать CurrentWeek новое значение и обнулять CurrentNumber. Если значения не отличаются - номером заказа служит CurrentNumber+1, и в CurrentNumber после запроса заносится увеличенное на 1 значение. Этот способ работает, но его громозкость очевидна...
Вот и спрашиваю про другие идеи. Натолкните на мысль, с реализацией я сам справлюсь.

Добавлено через 2 минуты
MsGuns, я в курсе.. в базе уже порядка 15 таблиц, почти все из которых связаны друг с другом и привидены к "нормальным формам".
Ну что тебя сказать ! Жизнь учит все своего ошибке .... делайте так как вы считаете правильно и увидите как бистро и хорошо будет работать ваши будущие программа
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 01:52  [ТС] 13
xxbesoxx, Вы по существу что-нибудь сказать можете? Предложить другую, более шуструю реализацию?
0
MsGuns
535 / 535 / 57
Регистрация: 04.04.2011
Сообщений: 2,002
04.02.2012, 02:09 14
Очевидно, что у Вас не прописана в модели достаточный образом сущность "Заказ". Не видя Вашей БД, могу предположить, что под "заказами" Вы имеете в виду таблицу с спецификацией заказа, в которой по одному реальному заказу имеется столько записей, сколько в нем строк-позиций. Если так, то Вы совершили генеральную ошибку при моделировании базы. Сущность "заказ" должна быть предтавлена как минимум двумя таблицами - заголовком заказа, в котором имеются дата, номер, указатель на заказчика, сроки исполнения, флажки (срочный, обязательный, актуальный и т.д.), приоритетность, прочая специфика... И таблица - состав заказа, содержащая данные о товарах (услугах), цене, кол-ве, бухгалтерских атрибутов и т.д. Вторая таблица должна быть связана с первой отношением один-ко-многим по ключу-идентификатору.

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

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

Добавлено через 3 минуты
В общем, Вам наверное не мешало бы посмотреть промышленные продукты чтобы определить КАК НАДО. 1С подойдет вполне ИМХО. В жизни такие знания приходят, как правило, с опытом

Добавлено через 1 минуту
Схему базы покажите - сразу станет понятнее и лечге
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 02:10  [ТС] 15
MsGuns, Нет. 1 заказу соответствует одно изделие. нумерация идти будет в любом случае автоматически, а не пользователями.

Цитата Сообщение от MsGuns Посмотреть сообщение
Но опять же при многопользовательской работе это чревато конфликтами. Почему бы не формировать (в режиме авто, еснно) номер непосредственно при добавлении записи в таблицу, предваряя инсерту запрос на получение номер - все естественно в контексте одной транзакции.
Подробнее, пожалуйста, напишите.
0
MsGuns
535 / 535 / 57
Регистрация: 04.04.2011
Сообщений: 2,002
04.02.2012, 02:47 16
Delphi
1
1 заказу соответствует одно изделие.
Неверно по определению !

Delphi
1
нумерация идти будет в любом случае автоматически, а не пользователями.
Аналогично

Оба эти тезиса говорят (кричат !!!) о недоскональном (это если очень деликатно сказать ) знании Вами предмета.

Delphi
1
Подробнее, пожалуйста, напишите
Все очень просто:
Оператор А начинает вводить новый заказ, жмет "Добавить" и программы вычисляет ей порядковый номер (например, дело происходит в понедельник в 8.00) - №1. А вводит два поля и тут ей звонит подруга, А отвлекается. При этом новая запись в базу еще не добавлена.
Оператор Б тоже начинает вводить новый (другой) заказ, повторяя действия А - ей, как нетрудно увидеть, также выдается №1. Б оказывается прилежнее и вводит все данные, отправив новый заказ в базу. При это в таблицу будут добавлена запись с номером №1.
Оператор А закончила базар с подругой и доввела свой заказ, при этом не подозревая ни о какой каверзе. Ее запись будет записана также с №1 ! Либо (если Вы объявите поле как уникальный индекс, что само по себе уже криминал, т.к. в реальной жизни вполне может быть два заказа с одним и тем же номером) получает исключение ! После чего недоумевает и бежит к Вам как к программисту с воплем "Почему программа не берет ее заказ ?"

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

Добавлено через 9 минут
Пора спать, поэтому закругляюсь.
Добрый Вам совет - оставьте в покое Вашу базу и сосредоточьтесь на "теории" - внимательно изучите все использующиеся реальные бумажные документы, поговорите с теми, кто эти заказы составляет (заключает) - постройте в своей голове четкую полную систему.Поймите ЧТО Вам нужно сделать.
После этого посмотрите реально работающие системы в Вашей или соседней фирме (пусть даже не по Вашей задаче - это несущественно - номера есть у любых документов). Если нет возможности - скачайте демо любой промышленной ERP (1c не самый плохой образчик, поверьте)

Без этого - все, что Вы попытаетесь сделать - работать нормально НЕ БУДЕТ. Вы потеряете время и, что много хуже, уверенность в себе.
Поверьте человеку с многолетним опытом проектирования, разработки, внедрения и сопровождения сложных учетно-расчетных систем

Добавлено через 12 минут
Напоследок немного о "заказах".
Не знаю особенностей Вашего бизнеса, но думается, что он подчиняется общим тенденциям, а они таковы, что в реальной жизни все быстро меняется. Поэтому в процессе выполнения заказа, а иногда даже и до того, может поменяться:
- спецификация (состав предметов или услуг),
- количество,
- цена (расценка),
- сроки
и т.д.
При этом часть заказа может быть оставлена в силе по взаимной договоренности (например о цене), а часть - изменена. Просто изменить цену в плоской базе - однозначно нарушить достоверность информации ! А это значит, что "база" должна позаботиться о сохранении динамики, т.е. как старых, так и новых движений (изготовление, поставка и т.д.). Что, как Вы догадываетесь, ведет к "обрастанию" базы (и приложения соответственно) новыми таблицами и интерфейсами (формами,функционалом) пользователя. Но в данном случае эти "добавки" вовсе не лишние, более того, без них Ваша система будет мертва, как новый красивый дом без инженерных коммуникаций.

Добавлено через 1 минуту
Я к тому, что к документу-заказу появятся корректировки, поправки, дополнения и т.д. Они все должны быть отражены в базе как документы (тоже с номерами ессно).
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 12:15  [ТС] 17
MsGuns, Ваше предложение? Оставить автоинкремент?
Насчет добавления заказа...Зачем раньше времени спешить? Сперва заполняются все поля, а уже по нажатию кнопочки Добавить заказ происходят все запросы к базе, в т.ч. присваивание заказу номера и так далее.
0
MsGuns
535 / 535 / 57
Регистрация: 04.04.2011
Сообщений: 2,002
04.02.2012, 13:32 18
Delphi
1
Ваше предложение? Оставить автоинкремент?
Мдя, столько много букав набрал, пытаясь объяснить, а все впустую, похоже
0
SevereK20
0 / 0 / 1
Регистрация: 24.10.2010
Сообщений: 38
04.02.2012, 13:45  [ТС] 19
MsGuns,
Вы написали про эпикфайл ситуацию в случае, если 2 оператора одновременно добавят новую запись. Я написал, что это нереально, т.к. добавление записи ведется в момент нажатия кнопки Добавить, а не перед началом заполнения данных по новому заказу. Весь вопрос сводится к тому, как лучше продумать счет заказов, где его хранить и как обнулять.
0
melomaniak
12 / 12 / 2
Регистрация: 30.10.2011
Сообщений: 59
04.02.2012, 14:09 20
SevereK20, щас будет много букав, запаситесь терпением.
Начну сначала, что такое первичный ключ? это по определению уникальное поле, которое однозначно идентифицирует запись в базе данных, первичные ключи бывают естественные и искусственные, я щас не собираюсь спорить каким пользоваться лучше (по моему мнению искусственным) но вы хотите сделать естественный ключ, то есть у вас дата добавления заказа является идентификатором записи, причём она же ещё и должна быть автоинкрементом. Реализовать подобное достаточно просто, но только в самом приложении, в базе, если только хранимой процедурой или триггером каким-нибудь, я не пробовал так издеваться.

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

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

Ну и чисто по опыту скажу, что разрабатывая программу, даже если знаете, что ей будут пользоваться два человека, то всё равно разрабатывать её необходимо так, как будто ей будут пользоваться тысячи людей.
0
04.02.2012, 14:09
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
04.02.2012, 14:09

Delphi+access
Здравствуйте! подскажите, пожалуйста, может у кого-нибудь имеются ссылки на...

Delphi 7 и БД Access
Здравствуйте. Такой вопрос. Как программно добавить в DBComboBox поле из...

БД Access + Delphi
Здравствуйте помогите реализовать так что бы при нажатий кнопки отрывалась...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru