Как правильнее огрганизовать взаимодействие с базой из интерфейса

← →
Rostislav Rotaru © (2005-01-13 11:28) [0]

Здравствуйте. Пишется склад. В процессе работы, касаемо расходных документов, возник следующий вопрос: как правильнее написать модуль.
Есть таблицы MSSQL: t_products, t_documents, t_documents_details.
Соответственно, таблицы товаров, шапки документов, и позиции в документе. В t_documents_details хранится ссылка на id из t_products.
Есть форма. Я разделил ее на три части. Верхняя - шапка, слева - Список товаров с остатками (хранимая процедура sp_products), справа - сам документ (sp_documents_details). Пока сделал так: При выборе товара со списка слева, через AdoCommand делаю insert into t_documents_details.... ссылку на товар + остальное. Потом, делаю requery для sp_documents_details, чтобы обновить список позиций в документе. Во время обновления, через locate нахожу вновь добавленную позицию.
Вопрос: Правилен ли такой подход к организации этой части, и если нет, то какие еще могут быть варианты, учитывая большое количество документов (около 350-400 в день)и товаров в них (30-50).
Спасибо.

← →
jiny (2005-01-13 11:32) [1]

У меня тоже пишется складская программа, может вышлешь скриншоты по программе, обсудим в форуме механизм взаимодействия, поделимся идеями, я тебе вышлю свои скриншоты

← →
Sergey13 © (2005-01-13 11:38) [2]

Ну например можно
1. при составлении нового документа писать не сразу в t_documents_details, а в ее аналог в памяти (типа RxMemoryData). После окончания ввода - одним махом записать в таблицу.
2. можно пользоваться не запросами напрямую, а через Insert/Append датасета. Съэкономишь на реквери.
3. =1+2 8-)

← →
Ega23 © (2005-01-13 11:39) [3]

Мне нравится Master-Detail системы DBGrid"ов.

← →
Rostislav Rotaru © (2005-01-13 11:46) [4]

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

Интересен подход Sergey13 © (13.01.05 11:38) [2]
Попробую.

jiny (13.01.05 11:32) [1]
Скриншоты могу выслать... куда?

← →
jiny (2005-01-13 12:00) [5]

zhas-trz@tarazinfo.kz

← →
Rostislav Rotaru © (2005-01-13 12:05) [6]

Sergey13 © (13.01.05 11:38) [2]
В принципе это соответствует последним рекоммендациям "не держать постоянно открытый набор данных". Не будет никаких камней потом?

← →
Sergey13 © (2005-01-13 12:14) [7]

2[6] Rostislav Rotaru © (13.01.05 12:05)
Я не знаю, где ты черпаешь свои рекомендации, но предполагаю, что камни есть везде. Но это не значит, что их нельзя обойти.

Подсказка. Программ-Складов работает немеряно - это самая, ИМХО, многочисленная армия программ (кроме калькулятора ессно 8-). Значит сделать можно все. 8-)

← →
Rostislav Rotaru © (2005-01-13 12:21) [8]

Sergey13 © (13.01.05 12:14) [7]
Естественно сделать можно все. Но хотелось бы чтобы все работало с наименьшими затратами ресурсов, быстро и стабильно. Поэтому спросил...
Я не имел ввиду камни при программировании, а потом, в процессе работы системы.

jiny (13.01.05 11:32) [1]
Выслал...

← →
Sergey13 © (2005-01-13 12:25) [9]

2[8] Rostislav Rotaru © (13.01.05 12:21)
>Я не имел ввиду камни при программировании, а потом, в процессе работы системы.
Что для тебя камни например? Каким из трех "моих" советов ты решил воспользоваться?

2[10] Rostislav Rotaru © (13.01.05 12:27)
>Первая
При этом может возникнуть только один (имхо) камень - за время составления документа остаток товара изменится и станет меньше передаваемого количества. Т.е. при записывании в БД 34 (например) значения из 50 возникнет ошибка. Твоя задача адекватно отреагировать на это - дать юзеру возможность заменить/исключить товар из документа. Т.е. не потерять весь документ.

Это не проблема. Есть кнопка "Провести", и она в журнале документов. Спасибо.

← →
jiny (2005-01-13 13:53) [13]

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

Как правильнее огрганизовать взаимодействие с базой из интерфейса Найти похожие ветки