нельзя так с генераторами


индексы, индексы...



Ты хочешь сказать, что после добавления, если выполнить refresh, то в наборе данных ты увидишь запись? Хм...




И не должен видеть, можно показывать в редких случаях.


Ты этот код понимаешь? Для чего он?


Почитай про OLD_, NEW_ и MAS_ в докементации к фибам.


И ты вообще знаешь для чего рефреш?

Ты не увидишь новой записи в НД, пока не переоткроешь его.

Добавлено через 1 минуту и 11 секунд

Опять же, посмотри, что за параметр можно вставить в скобки CloseOpen()

Согласен.

А как же область видимости транзакции? При возникновении исключения у меня выполняется Cancel в соответствующих событиях DataSet. Кроме того, открываем Хелен Борри (2-е издание) на стр. 700 и читаем, читаем...


Почему? Ведь если в качестве ключа использовать другие уникальные данные, показывать их можно, так почему номер нельзя?
Я же объяснил, что требуется четкая последовательность регистрационных карт. Есть определенная процедура (в смысле регламент) исключения и удаления регистрационной карты.

Если использовать генерацию в AutoUpdate Oprions или этот вариант, то после добавления/обновления записи (если установлено в Options RefreshAfterPost->true или принудительно обновлять в соответсвующем событии DataSet) запись появится в наборе данных и гриде и окажется в фокусе. Проверено.

Читал.

Еще раз повторю, что увижу.

Это сообщение отредактировал(а) former - 9.9.2009, 21:59

Так я про это и говорю. Пример:
Условие 1 все транзакции read commited
Условие 2 триггер на проверку наличия типа 
1. Старт транзакции 1
2. Старт транзакции 2
3. Транз№1 Insert into table (id) values (1);
4. Транз№2 Insert into table (id) values (1);
5. Транз№1 Commit
6. Транз№2 Commit
Как думаешь сколько записей с id=1 будет в БД?
И вызовется ли исключение?

Потому что пользователи ныть начинают... типа: "А я хочу по порядку...." и т.д. и т.п.
А тут уже даже программист хочет по порядку    



Стормозил, ты не увидишь данных, которые были добавлены другими транзакциями.

Сегодня проведу эксперимент.

Два поста подряд пытаюсь донести суть.
Строгая нумерация не моя прихоть. Яркий пример бухгалтерия, где номера договоров, счетов, инвентарных номеров и прочих документов идет в строгой последовательности. Что прикажешь делать? Как им присваивать номера?

Для этого используется отдельная кнопка, которая переоткрывает DataSet, т.е. делает полный Refresh. А то получится, что пользователь добавил запись и должен заново выполнять поиск, фильтрацию и т.д., что бы продолжить с ней работать. Согласись, что нажать на одну кнопку он всегда успеет, чем искать каждый раз нужную запись. Кроме того, каждый раз ворочить большин набором данных не очень-то экономично, по отношению к ресурсам и нагрузки на сеть и сервер, особенно, если пользователей много.

Не надо путать искусственный ключ с номером договора.
А если с нового года/пятилетки/и т.д. нужно начать нумерацию с начала? Что будешь делать?
Обычно делают так:
1. ID никто, кроме программиста, не видит.
2. Под № договора выделяют отдельное поле или несколько полей.
3. Строится уникальный индекс по полям "№ договора" + Год, может еще какие поля можно добавить.
4. ID получают в начале редактирования.
5. К этому ID привязывают detail таблицы.
6. Итоговый номер договора генерируется после того, как сделаны все проверки и данные договора добавлены.

Deniz, индексы это хорошо, а вот что тогда с исключениями делать? Какого формата сообщение увидит пользователь в результате исключения?

Т.е. для номера договора должен использоваться отдельный генератор?

Это сообщение отредактировал(а) former - 10.9.2009, 14:56

Так создай им отдельное поле № договора!!!

Добавлено через 35 секунд
А если прийдётся изменить значение? Ты дашь пользователю редактировать значение поля первичного ключа? Ну ну 

Добавлено через 1 минуту и 28 секунд
Создай ещё один генератор для номера договора и/или сам на клиенте атоматом подставляй.

Добавлено через 10 минут и 55 секунд
ааа, Deniz уже написал 

Добавлено через 12 минут и 21 секунду

да!!! Можно делать и 

Deniz, с транзакция ми действительно прав. Но как тогда быть с сообщениями исключений, если использовать индексы? Ведь они должны быть понятны пользователю.

Нет, пользователь ничего не редактирует. Номер карты присваивается генератором.

    

Ну это только при условии, что номер состоит из одних цифр.

Akella, так что с Refresh-ом?  

Это сообщение отредактировал(а) former - 10.9.2009, 18:37

Deniz, Akella, спасибо за помощь!
С исключениями я разобрался, используя репозиторий.
А вот с номером договора так и не понятно, в какой момент его нужно генерировать и где?

Но всё равно когда-нибудь понадобится изменять номер карты, корректировать, мало ли. Если будет отдельное поле - без проблем, а если ковырять первичный ключ....  


  
а так?


При условии, что поле LCD типа Timestamp   

Это сообщение отредактировал(а) Akella - 10.9.2009, 19:09

Я имел виду, как быть с текстовым вариантом?

вот и славненько   
Здесь есть куча вопросов:
Как выглядит этот номер? Как он должен генерироваться? Кто отвечает за генерацию?
По своему опыту могу сказать, что в таких номерах (договор, вх. документ и т.д.) обычно присутствуют разные буквы и метасимволы, причем автоматизировать процесс генерации бывает достаточно сложно.
Иногда лучше назначить одного ответственного, кто будет вбивать № договора во внесенный в БД документ, чем попытаться определить след. номер от "458-П/2009/В-32".

Ручной ввод - самое простое, что можно придумать.  Но человеческий фактор....  
Я уже кое-что сам вчера придумал. Можно использовать префиксы для каждого типа договора. Создать для них отдельную таблицу.
Например, для 458-П/2009/В-32:
Префикс - -П/2009/В- (для каждого типа договора свой)
Изменяемые части - 458 и 32. Для них генераторы. Значения получать в процессе редактирования, в зависимости от условий договора.
Что-то вроде регулярных выражений.

Безусловно, такой подход имеет свои недостатки.

Это сообщение отредактировал(а) former - 11.9.2009, 09:06

former, не все так просто, все зависит от того, какой на Вашем предприятии принят алгоритм формирования номеров.
Поскольку официально-декларирующего алгоритма нет, то каждый извращается как хочет, например (458-П/2009/В-32):
458 - порядковый номер
П - тип договора
2009 - год заключения
В-32 - дополнительные параметры по договору
Может быть два одинаковых порядковых номера но с разными типами 458-П и 458-С.

если будет один назначенный ответственный с одного компа (с проверкой на уникальность), проблем будет меньше, а если еще пару раз сделать показательное наказание за ошибки ...
В общем удачи.