Clarion 5.5EE пропатченый
template Clarion
Есть база, в ней поле idd численное, на поле сделан Ключ с автонумерацией
Когда отрабатывает процедура Update_Имя-таблицы, поле idd заполняется автоматом.
Когда добавляю запись через add(имя-таблицы), то нужно в ручную указывать этот номер?! а какой был последний????
.............есть еще вариант задвоить запись.......
Автономерация ключей и ручное добавление записи
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
-
Гость
-
Гость
-
Гость
Будет. Только SET(FILE:Key); PREVIOUS(FILE)Так работать не будет?
Но этот код правильно будет работать ТОЛЬКО если
в данном ключе одно ключевое поле.
Вариант-же, который был предложен изначально -
универсальный. Хотя и требует дополнительных
инициализаций.
К тому-же твой код может быть неверно обработан
ODBC- и SQL-драйверами. Точнее - SQL-сервером.
=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Написал: ClaList(2)
-
Гость
А причем здесь автонумерация? Все то те самое относится к случаю, когда дваВ стандарте при входе в форму сразу создаётся запись, так её
может юзверь c другой рабочей станции тоже захватить, пока первый пытается что то ввести в форме, второй уже изменил/удалил или ещё что нибудь с ней сделал.
чела одновременно редактируют/удаляют одну и ту же запись.
Спорный вариант. В нормальной базе не должно быть записей с отсутствующимиИли, вообще простейший вариант - при входе в форму
редактирования записи проверять наличие данных в обязательных
полях. Например, при входе в анкету клиента - наличие ФИО.
данными в обязательных к заполнению полях.
В этом случае нельзя будет создав запись родителя до сохранения в базеКроме этого, существуют шаблоны, в которых реализована старая
логика создания новой записи. Когда добавление записи и,
соответственно, автонумерация производится при завершении
ввода данных в форме.
(автонумерации) вешать на него дочерние записи.
WBR, Nick Tsigouro. MailTo:Nick@arsis.ru
(Добавление)
В этом случае нельзя будет создав запись родителя до сохранения в базе (автонумерации) вешать на него дочерние записи.
Nick, а ты полагаешь, что можно создавать дочерние записи до принятия
решения (записи) о необходимости родительской? Ну вы и даете!
--
С уважением,
SAN mailto:vgsan@yandex.ru
(Добавление)
Это не я. Пользователи обычно сначала хотят отсканировать бирки товаров, а
потом заполнить шапку накладной. Юзер в прошлой жизни брал чистый бланк
(новую родительскую запись) и начинал его заполнять так, как ему удобно.
Также хочет работать и на компе. И это его законное право. Решение о
необходимости создания новой родительской записи было принято в тот момент,
когда он нажал кнопку "Новая накладная". Можно, конечно, не пускать его в
табличную часть, пока он не заполнит всю шапку и не скажет
"Зарегистрировать", только ведь он "Фи-и..." будет на такое решение
говорить.
WBR, Nick Tsigouro
(Добавление)
А вот это я тоже не понял, есть форма редактирования накладной, там есть
табличная часть,
вводи позиции накладной когда хочешь и сколько хочешь, шапку инициализирую
тоже когда хочешь,
нажал Ok кнопку, сохранилась накладная целиком, или я чего то не понимаю?
Как уже говорилось, накладная и позиции до нажатия на Ok, формируются на
клиенте, в базу попадают только по Ok.
Andrew Myalin
(Добавление)
Есть и такое решение, и у него есть свои проблемы.
1. Его трудно распространить на произвольное количество уровней потомков.
2. Если занесение товара в накладную отражается только во временных таблицах
на одном клиенте, то возможно, что единственный экземпляр дефицита попадет в
две накладные.
3. Бывают "накладные", которые в одиночку не набьешь. Скажем, несколько
тысяч позиций.
WBR, Nick Tsigouro
(Добавление)
У меня есть вопрос: почему даже в SQL приходится пользоваться методами 20-летней
давности?
Мое имхо при добавлении записей:
При входе в (любую) форму начинаем транзакцию,
добавляем эту (родительскую) запись в базу, как только юзер начинает добавлять к
ней детей.
По OK делаем COMMIT, по Cancel - ROLLBACK. Прога упала - драйвер сам откатит.
Внутри транзакции целостность ID, автонумеруемых полей, неосиротевших детей
поддерживается самим SQL-ем.
Что-то здесь не так?
--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone: +380 572 177977
WEB: http://enigmasoft.com.ua
e-mail: clalist@enigmasoft.com.ua
ICQ: 12253836
(Добавление)
Тут все не так, Если Вы будете начинать транзакцию по входу в форму,
Вы получите однопользовательскую систему, почему, думаю объяснять не
нужно?
--
С уважением,
Олег mailto:clarion@hotbox.ru
(Добавление)
Бес попутал.
Insert все-таки не select for update, когда можно не зависеть от других юзеров,
меняющих другие записи.
Хотя мне казалось (или просто очень хотелось, чтоб так было), что при начале
транзакции, в которой есть только insert-ы сервер может независимо от таких же
insert-овых транзакций вычислять все автонумеруемые поля и делать в конце концов
commit, пока это не затрагивает уже находящиеся в базе записи (нет ни update, ни
delete).
--
Best regards,
Maxim Yemelyanov
(Добавление)
Мое глубокое убеждение, что "кларионовский" метод работы с
формой(делать запись в момент открытия формы на INSERT) бред еще тот.
Этим самым делается целая толпа ненужных операций, в том числе по
убиванию этой записи если добавлять передумали. А что делать если в
форму зашли и отрубилось электричество, получаем мусор в БД? Вообщем
мое ИМХО - так делать не стоит.
--
С уважением,
Олег mailto:clarion@hotbox.ru
(Добавление)
Мое глубокое убеждение, что "кларионовский" метод работы с
формой(делать запись в момент открытия формы на INSERT) бред еще тот.
Ну, так уж и "кларионовский"...
Этим самым делается целая толпа ненужных операций, в том числе по
убиванию этой записи если добавлять передумали. А что делать если в
форму зашли и отрубилось электричество, получаем мусор в БД? Вообщем
мое ИМХО - так делать не стоит.
Дык, нет других альтернатив... Даже набивание во временные очереди
(файлы) по сути к тому же алгоритму и сведутся. Разница лишь в том,
что при потоковом заливании на сервер можно всю накладную завернуть
в транзакцию, а при позаписном - нельзя. Зато при позаписной можно
вводить одну факуру с разных станций.
А повисание мусора... Не должно быть его. Вернее, мусор (незаполненые
полностью накладные) будут видны в клиенте и доступны для удаления.
Как минимум - в служебном режиме просмотра по PK.
Так что, как ни крути, а делать в любом случае нужно следующее:
1. Создать заголовок (получить ID)
2. Добавить детей.
Ни избавиться от любого пункта нельзя, ни переставить их местами.
С уважением,
Владимир Смелик vovs@bigfoot.com
(Добавление)
Перебор, заливать все скопом титул и фактуру - имхо низя, особенно
когда тебе нужно резервировать товар...
А повисание мусора... Не должно быть его. Вернее, мусор (незаполненые
полностью накладные) будут видны в клиенте и доступны для удаления.
Как минимум - в служебном режиме просмотра по PK.
Ага, а кто это удалять все будет? Мне клиенты за такое решение башку
оторвут в лучшем случае, в худшем найдут другого исполнителя. Да и мне
недосуг кататься к каждому чьтобы грохнуть мусор в БД...
Так что, как ни крути, а делать в любом случае нужно следующее:
1. Создать заголовок (получить ID)
2. Добавить детей.
О, вот это точно. Тока нафига получать ID в момент открытия формы,
если это можно сделать в момент добавления первой позиции фактуры?
--
С уважением,
Олег mailto:clarion@hotbox.ru
[s](Добавление)
NT> Спорный вариант. В нормальной базе не должно быть записей с отсутствующими
NT> данными в обязательных к заполнению полях.
А кто сказал, что в НОРМАЛЬНОЙ базе будут такие записи?
Речь идет ТОЛЬКО о добавляемых записях.
А в такой записи, после ее автодобавления заполнены только
ключевые поля автонумеруемых ключей.
Например, в той-же анкете при добавлении будет заполнено
только поле индекса а все остальные поля, в том числе
и ФИО, будут пустые.
=============================
С уважением, Олег А. Руденко
[s](Добавление)
В tps, обойдя валидатор записи, ты это запихнуть сумеешь, а на сиквел нет.
WBR, Nick Tsigouro
[s](Добавление)
Здравствуйте, Андрей!
Как уже говорилось, накладная и позиции до нажатия на Ok, формируются на
клиенте, в базу попадают только по Ok.
Теперь понятно. Т.е. у тебя дочерние записи вначале вводятся в буфере, а
затем в рамках транзакции сбрасываются в базу. Тут возникает два вопроса.
Первое. Мы не сможем оперативно контролировать остатки товаров в процессе
набора накладных. Второе. Если накладная большая (например, оптовая
торговля), то не будут ли возникать дополнительные тормоза при попытки
записи с нескольких станций одновременно? Или это уже особенности работы с
SQL?
С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Существует шаблон SuperInvoice, реализующий одновременное добавление
родительской и дчерних записей ,
который я широко использую..
У мя некоторые накладные на отпуск товара содержат по 2000 позиций и
тормозов не наблюдается.
C5B ABC Oracle
Роман Ломасов <velomot@sucden.ru>
[s](Добавление)
ВЧ> Тут возникает два вопроса. Первое. Мы не сможем оперативно
ВЧ> контролировать остатки товаров в процессе набора накладных.
В данном случае двойной конроль, при вводе(на клиенте), и при сохранении
(ХП).
Второе.
ВЧ> Если накладная большая (например, оптовая торговля), то не будут ли
ВЧ> возникать дополнительные тормоза при попытки записи с нескольких
ВЧ> станций одновременно? Или это уже особенности работы с SQL?
Никаких тормозов.
P.S.
интересно другое (ABC, Legasy), на эту же тему, есть большая накладная,
набили её процентов так на 80,
юзверь понял, что ошибси в набивки, вместо пива молоко принял, жмёт Cancel,
тут возникает вопрос,
как в этом случае происходит откат позиций, одной DELETE командой или на
каждую запись по две команды:
получить позицию
удалить позицию
что то типа
Код: Выделить всё
LOOP
NEXT
DELETE
END
Циклом. Только в легаси нужно исправить шаблон кнопки OK и заменить DELETE
на RIDelete.
WBR, Nick Tsigouro
(Добавление)
Здравствуйте, Олег!
всего то RIDelete...Мое глубокое убеждение, что "кларионовский" метод работы с
формой(делать запись в момент открытия формы на INSERT) бред еще тот.
Этим самым делается целая толпа ненужных операций, в том числе по
убиванию этой записи если добавлять передумали.
Незавершенную работу...А что делать если в
форму зашли и отрубилось электричество, получаем мусор в БД?
Как я понял, диспут на тему автонумерации постепенно сошел на вопрос, нужноВообщем
мое ИМХО - так делать не стоит.
ли редактировать новую накладную (или что-то подобное, имеющее дочерние
таблицы) напрямую в БД или предварительно в буфере, с последующей массовой
записью в БД. Причем те, кто работает с файлами, высказываются за первый
вариант, а работающие с SQL - за второй. И, похоже, все остались при своем
мнении.
Была в свое время такая банковская система Symbols. Может и сейчас есть.
Старая, импортная. Под оракулом. Там, насколько помню, тоже редактирование
проводок велось в буфере, а затем кучей записывалось и пачке (проводки
включались в пачки) присваивался системный номер.
Может в этом все дело - файлы или SQL?
С уважением,
Вячеслав Черников
(Добавление)
Для Вас да, а для сети и для сервера? А если в этой сети народу подВЧ> всего то RIDelete...
сотню и больше?
Отнюдь, скорее дело в подходе и привычке.ВЧ> Может в этом все дело - файлы или SQL?
Я за целостность БД и отсутствие в ней мусора.
И не хочу закладываться на дядю, который будет это все поддерживать,
система должна работать сама по себе по максимуму.
Я уже не говорю про функциональную часть.
К примеру у меня есть поле - номер документа - и оно уникально! получается при
входе в форму на INSERT я должен положить туда какое то значение,
так? Потом отказываюсь и получаю дырку в нумерации документов, так?
Бухгалтер голову оторвет и будет прав!!!
Плюс толпа полей, с пометкой об обязательном заполнении, с ними как?
--
С уважением,
Олег mailto:clarion@hotbox.ru
(Добавление)
Андрей, ты не прав!AM> Clarion автонумерация допустима только для однопользовательских систем
Для обхода этой проблемы есть несколько довольно простыхAM> Set(FilePrimaryKey)
AM> Previous(File)
AM> LastRef = CHOOSE(ERRORCODE()=0,File:PrimaryKeyField + 1,1)
AM> Для многопользовательских систем требуется использовать совершенно другие
AM> механизмы автонумерации.
AM> В стандарте при входе в форму сразу создаётся запись, так её может юзверь c
AM> другой рабочей станции тоже захватить, пока первый пытается что то ввести в
AM> форме, второй уже изменил/удалил или ещё что нибудь с ней сделал.
решений. Самый простой - поставить фильтр в бровзе на пустые
записи. Тогда новая запись не будет видна на других станциях,
пока создавший ее оператор не завершит ввод.
На ряду с этим я еще использую логические блокировки редактируемых
записей. Как - уже описывал в этой рассылке.
Или, вообще простейший вариант - при входе в форму
редактирования записи проверять наличие данных в обязательных
полях. Например, при входе в анкету клиента - наличие ФИО.
При входе в бланк документа - наличие индекса клиента.
И т.д.
Кроме этого, существуют шаблоны, в которых реализована старая
логика создания новой записи. Когда добавление записи и,
соответственно, автонумерация производится при завершении
ввода данных в форме.
=============================
С уважением, Олег А. Руденко
(Добавление)
Лучше иметь отдельный файл для нумерации всехДля многопользовательских систем требуется использовать совершенно другие
механизмы автонумерации.
других файлов тада не будет проблем при переходе к
многопользовательскому режиму . А у Мялина я бы спросил
как у него реализованы библиотеки с ODBC . Там постраничный режим или
файловый и если постраничный ,
то как реализован поиск ?
Что-то я не могу поверить , что у ODBC нет собственных средств для этого
дела .
А если нет , то как можно использовать sql для поиска ?
или все-таки sqlfetch с начала выборки и до нужного места ?
Vasiliev B <soft2@mail.redcom.ru>
(Добавление)
Открыть скроллируемый курсор и гонять его вверх/вниз просто, но мне данный
механизм не очень понравился, держим открытый курсор на время работы
процедуры, так и на ограничение количества открытых курсоров легко выйти.
Мне нравится другой способ получения данных: есть запрос к БД, открыл
курсор, получил результат, закрыл курсор.
Два режима загрузки Browse:
1. Закружаем всё.
2. Загружаем не более определённого количества, при этом в справочном поле
отображается сколько в Browse и сколько реально по запросу в БД, если
пользователь не находит нужного документа в Browse, он усекает условие
выборки с помощью доп фильтров или локатора (тоже несколько вариантов
работы).
Само же локаторное поле осуществляет быстрый поиск уже в полученной выборке
на клиенте.
Исчезли зависания Browse при запросах (первый Fetch тормозит), которые
возвращают дикие количества записей,
как бы юзверь не был тупой, мы ограничиваем его (п.2 - Загружаем не более
определённого количества).
Сервак не уходит в аут (загрузка 100%), да и конечные юзвери очень
довольны - а это самое главное.
Andrew Myalin
(Добавление)
Дык вариант два это как ?
Если выборка большая то грузим в очередь только часть ?
а остальное висит и ждет когда мы долистаем очередь
до конца и начинает подгружаться построчно или обнуляем очередь и загружаем
оставшийся кусок ?
Vasiliev B
(Добавление)
Грузим в очередь не более определённого количества записей.
Если соответствующий документ не найден, то урезаем выборку фильтрами
и повторяем запрос.
Дык, глянь другие аналогичные продукты.
Постраничная загрузка и сумашедшие WHERE конструкции при скроллингах,
выводят сервак в аут, кстати, этот же механизм велосипедисты реализовали и в
ADO Browse.
Может быть есть ещё решения, может быть более универсальные, постраничная
Browse это точно не универсальный способ получения данных, но как я уже
говорил клиенты довольны и это главное.
P.S.
Клиент хочет посмотреть документ, а ему вываливают 10000000.... документов.
Покури, т к первый Fetch, независимо постраничная Browse нет, получишь
только после сформированной ПОЛНОЙ выборки на сервере по данному условию
(хотя на клиента придёт PROP:Items записей из этой выборки, сервак парился
формировал выборку, а клиент взял только малюсенький процент от неё -
неэффективное использование ресурсов сервера), ну а потом дорогой ищи свой
документ, только не запарься, стоит ему нажать PageDown, жаль такого
клиента.
Andrew Myalin
(Добавление)
Я сейчас далёк от баз, поэтому глупый вопрос:
чем отличается использования BUFFER() от "Грузим в очередь"?
Сергей - chusha@mail333.com ; chusha@hotbox.ru
(Добавление)
BUFFER - внутренняя буферизация, если можно так сказать, в C5 - GPFилась, в
C55 - непредсказуемо себя ведёт,
В C6 и смотреть не хочу.
Говорил и говорю, закоментарте вызов BUFFER в ABFILE.CLW
Andrew Myalin
(Добавление)
Хм... А чем, извини, этот вариант отличается отVB> Лучше иметь отдельный файл для нумерации всех
VB> других файлов тада не будет проблем при переходе к
VB> многопользовательскому режиму.
стандартного в плане обсуждаемой проблемы?
Имхо, ничем! Кроме дополнительных неудобств и
возможностей сбоя.
Просто надо грамотно использовать стандартный вариант
и проблем никаких не будет. По крайней мере, я еще
НИ РАЗУ не сталкивался с подобной проблемой в своих
программах!
=============================
С уважением, Олег А. Руденко
(Добавление)
Не могу обьяснить поскольку под "стандартным"
понимаю вариант в template , а я про это ничего не знаю.
Кроме того я не знаю как вот это запустить
PWRecordset15.Find
и тем более это
PWRecordset21.Seek
Vasiliev B
(Добавление)
Браво! Хоть кто-то громко!AM> Clarion автонумерация допустима только для однопользовательских систем
А как ты делаешь или предлагаешь делать? Хотя-бы в общем виде!AM> Set(FilePrimaryKey)
AM> Previous(File)
AM> LastRef = CHOOSE(ERRORCODE()=0,File:PrimaryKeyField + 1,1)
AM> Для многопользовательских систем требуется использовать совершенно другие
AM> механизмы автонумерации.
--
С уважением,
SAN mailto:vgsan@yandex.ru
(Добавление)
Всё зависит от поставленной задачи и от самого сервера, для MSSQL identity,S> А как ты делаешь или предлагаешь делать? Хотя-бы в общем виде!
для Oracle Sequences.
В MAV реализован универсальный способ, который работает на всех серверах:
Есть табличка автонумерации в которой есть два поля:
TableRef - условный номер таблицы, настраивается в словаре через File User
Option
NextRef - следующее значение для поля первичного ключа
Этот способ универсален ещё тем, что если Вы хотите сделать распределённую
БД и организовать репликации между серверами,
и причём разными серверами (склад - Oracle, офис - MSSQL), то чтобы не было
Duplicate при реплицировании, в предложенный механизм автонумерации вводится
правило формирования поля первичного ключа следующее:
IDфилиала * 10^10 + NextRef
где:
IDфилиала для офиса = 1
IDфилиала для склада = 2
и т д
Andrew Myalin
(Добавление)
Что-то я недопонимаю, зачем все это городить, если в
многопользовательском случае все равно будут грабли (наверняка). Почему
нельзя переложить все это на сервер. Например:
Есть табличка с полем Identity
Код: Выделить всё
CREATE TABLE IdentityTest (
Id Int IDENTITY (1, 1) NOT NULL ,
Name char(100) NOT NULL
)
IDENTITY
Ну так и пишем:
Код: Выделить всё
IF NOT Access:IdentityTest.Insert()
IdentityTest{prop:sql} = 'SELECT @@IDENTITY'
Next(IdentityTest)
IF NULL(IDE:Id)
message('Разрыв соединения')
ELSE
message('Сервер присвоил IDENTITY = '&IDE:Id)
END
END
одновременно добавляющих записи, то все будет ништяк.
Павел Яковенко
(Добавление)
про IDENTITY я говорил тоже применительно к MSSQL серверу.
Я же предложил универсальное средство, и про какие же граби Вы говорите,
с 1996 года проект бАльшой крутится, а граблей всё не видать,
документооборот дикий, рабочих станций немеренно,
где искать то грабли, в идее или в руках
хочу много!!!PNY> Если внутри одного соединения не работают несколько потоков,
PNY> одновременно добавляющих записи, то все будет ништяк.
Andrew Myalin
(Добавление)
Я использую для этого триггер после Insert
и средствами ODBC API ловлю в кларионе ID
--
С уважением,
Дмитрий Осипов mailto:Dima_Osipov@km.ru
(Добавление)
О! Люди, просветите начинающего SQL-шика. Почему после insert, а не до? Я вот
генерирую ID до insert, при этом никаких проблем с много-
поточностью/задачностью. А вдруг я неправ, и надо после insert?
--
Best regards,
Maxim Yemelyanov
(Добавление)
Дык, речь вроде об Identity шла.
А со сгенеренным ID - по барабану.
--
С уважением,
Дмитрий Осипов
(Добавление)
А что такое Identity (речь об оракле?). Это генератор значений
автоинкрементируемых полей, или что-то другое?
--
Best regards,
Maxim Yemelyanov
(Добавление)
Я вообще говорил про механизм, когда добавляется запись, а потом
делается PREVIOUS() по файлу - тут будут грабли в многопользовательском
режиме. Если только не обрамлять все это в одну транзакцию. Но тогда
будут проблемы с RI кодом в шаблонах.
А что касается вашего способа, то в случае работы с БД только через ваши
классы (за исключением доступа только по чтению) никаких граблей не
должно возникнуть. Действительно, механизм красивый и универсальный.
Единственно, использовать его в стандартных шаблонах, по-моему,
нереально.
Павел Яковенко
(Добавление)
Стандартно, вообще-то, не совсем так. Сначала PREVIOUS() - находим
максимальный имеющийся ключ, потом инкрементируем ключ и пытаемся добавить
запись. Если кто-то занимается тем-же, то у всех кроме одного будет
DuplicateKey. И они начнут этот процесс сначала. Пока не прорвутся, или не
исчерпают лимит попыток. А теперь внятно, плиз. Какие тут грабли? (Про
инициализацию других уникальных ключей временно забудем - это другая
проблема).
WBR, Nick Tsigouro
(Добавление)
Имелось в виду, видимо, проблема с доступностью добавленной записи для
других станций - в то время, когда на станции-инициаторе добавления
записи юзер ушастый и пушистый сидит в форме в полной уверенности, что
его текущую запись никто не тронет пока он не закончит ввод в форме.
А в это время его корефан-западлист, сидящий за соседним столом -
возьми и удали эту почти пустую запись... И куда первому
ушастому-пушистому писать по нажатию Ok ?...
Но не все так плохо. Достаточно просто иметь флажок в записи -
показывать ее другим усерам или нет... Пока флаг взведен (а взводиться
он должен при добавлении автоинкремента и сбрасываться при PUT-е) -
никто другой не увидет эту запись, следовательно не сможет
напакостить (случай клинических хряцкеров, лезущих гразными лапами в
таблицы при помощи TopScan/Clarview/DbfView/ServceManager и прочего мы не
рассматриваем).
Механизм этот работает вполне нормально при достаточно интенсивном
вводе новых данных (за базар отвечаю - ибо сам делал).
Единственое что не сделано - не написан распределенный шаблончик,
реализующий эту фичу в формах и браузерах
--
Best regards,
Vadym mailto:vadim@softcreator.com
ICQ: 82308757
(Добавление)
Здравствуйте, Вадим!
Мне еще больше нравится вариант созданную запись показывать, а при попытке
входа с другой станции автоматом переводить в "только просмотр". Если
пытается удалить, то, разумеется, отлуп. На автора записи это не
рапространяется. Правда, при таком варианте записи должны содержать подпись
создания (последней модификации) и должны отслеживаться ИД открытых записей.
Впрочем, это уже отдельный разговор на тему открытия окна один раз и т.п.
А вообще говоря, я нифига не понял, из-за чего возник данный тред
.Вариант, который предложил Андрей, обычно используется в так называемых
программах-конструкторах (1С точно, один знакомый на днях похожее говорил по
алеф). Можно и так, там свои плюсы и минусы. Без конкретной нужды все-же
лучше пользовать стандартный подход. ИМХО, конечно.
С уважением,
Вячеслав Черников
(Добавление)
Решений конечно много, но на мой взгляд, пока юзверь не нажал в форме
редактирования на добавление Ok кнопку,
данных в БД быть не должно, нажатием на Ok кнопку юзверь подтверждает, что
хочет создать документ в БД, а так получается, независимо от его согласия
документ болванка создаётся при входе в форму.
Вот ещё аргумент - вошёл в форму, машинка бах и зависла, болванка осталась в
БД.
Это опять же чисто моё мнение.
Andrew Myalin
(Добавление)
В общем случае согласен с этим.
Только опять глупый вопрос...
Насколько я понял из всего сказанного, у тебя делается так:
когда пользователь начинает создавать документ, то в некой таблице, общей для всех документов
и пользователей, создаётся некий ИД документа. Если пользователь подтверждает запись
документа в базу (OK), то документ записывается в базу с этим ИД и в этой таблице
идентификаторов этот же ИД остаётся. Если пользователь передумал, то из таблицы ИД-шек
связанный с этим документом ИД удаляется и сответственно база не "дёргается".
Т.е. ты используешь "стандартный" вариант 1:многим, только изменение "многих" у тебя происходит
пакетом, в одной транзакции, в отличии от кларионовского варианта, когда создание ИД для каждой
таблицы происходит отдельно в начале попытки добавления записи.
Я правильно понимаю твою идею?
p.s.
Я просто пытаюсь понять, чем вариант с "выносной" таблицей ИД-шек лучше, чем использование
флага "редактируется" для записи в изменяемой таблице (или того же HOLD).
Кстати, а почему стандартные возможности (HOLD) не применяются для захвата записи?
Сергей - chusha@mail333.com ; chusha@hotbox.ru
(Добавление)
нет нет и нет, ID для документа инициализируется в транзакции сохранения
документа,
из таблицы автонумерации мы получаем значение ID для документа,
предварительно захватив соответствующую запись в таблице автонумерации:
в таблице автонумерации для каждой таблицы хранится следующее значение для
поля первичного ключа
Начали транзакцию
! увеличили на 1 и заблокировали доступ к записи из других соединений
! UPDATE блокирует запись для доступа из других соединений
update autonumber_table set nextref=nextref+1 where tableref=УсловныйНомер
таблицы
! получили новый ID для документа
select nextref-1 from autonumber_table where tableref=УсловныйНомер таблицы
Добавляем документ
! Этого наверняка многоим не хватает в шаблонах, у меня же это делается без
единой EMBED вставки
Если есть дочернии Browse (Buffer Queue Browse) в форме редактирования,
то они автоматически сохраняются в транзакции родителя.
Если ошибка делаем откат транзакции (Rollback), иначе завершаем транзакцию
(Commit).
Никаких дополнительных действий вне транзакции не делается, не надо следить
за флагами и чем то ещё.
Опять же повторюсь, это чисто моё решение, а решений может быть много.
HOLD не юзаю, т к у меня бездрайверный подход, хотя словарик и шаблоны имеютЧС> Я просто пытаюсь понять, чем вариант с "выносной" таблицей ИД-шек
ЧС> лучше, чем использование флага "редактируется" для записи в изменяемой
ЧС> таблице (или того же HOLD). Кстати, а почему стандартные возможности
ЧС> (HOLD) не применяются для захвата записи?
место быть.
Andrew Myalin
(Добавление)
Наверно потому, что это плохая стратегия. В многопользовательских системахКстати, а почему стандартные возможности (HOLD) не применяются
для захвата записи?
общие ресурсы должны блокироваться на минимально необходимое время. Иначе
из-за конфликтов доступа к общим ресурсам начнутся проблемы с
производительностью системы в целом. Ну, к примеру, открыл запись,
захолдировал и пошел покурить/по обедать/вызвал начальник... А кто-то не
может из-за этого отчет вывести.
WBR, Nick Tsigouro. MailTo:Nick@arsis.ru
(Добавление)
Из доки:
"...Generally, this excludes other users from writing to, but not reading, the record...."
Вообще я вспомнил - мне самому не понравилось решение с блокировками записей много-много лет назад
Сергей - chusha@mail333.com ; chusha@hotbox.ru
(Добавление)
Здравствуйте, Андрей!
Подход, принятый в стандартных шаблонах, как уже отметил Николай, связан сРешений конечно много, но на мой взгляд, пока юзверь не нажал в форме
редактирования на добавление Ok кнопку,
данных в БД быть не должно, нажатием на Ok кнопку юзверь подтверждает, что
хочет создать документ в БД, а так получается, независимо от его согласия
документ болванка создаётся при входе в форму.
Вот ещё аргумент - вошёл в форму, машинка бах и зависла, болванка осталась
в
БД.
Это опять же чисто моё мнение.
редактированием дочерних таблиц. Например, есть накладная. По любому перед
добавлением записи по товару мы должны сохранить заголовок документа. Это,
разумеется, можно делать и при нажатии кнопки "Добавить" в дочернем browse
(варианты сохранения родителя отдельной кнопкой и предварительный ввод
дочерних записей в очередь рассматривать не будем). Поскольку дочерних
таблиц может быть несколько, то, видимо решили упростить - сохранять
родительскую запись сразу, а при отказе удалять.
Страшного в том, что осталась болванка в базе при сбое, ничего нет. Удалили
или продолжили редактировать.
Кстати, Андрей, а как ты разруливаешь ситуацию с удалениями или
исправлениями номеров (необязательно вручную, а, например, с помощью других
"образующих" полей записи)? Или твой вариант только для первичных ключей?
С уважением,
Вячеслав Черников
Написал: ClaList(2)
