Андрей Светлов
Март 23, 2009 06:27:52
Мне, например, очень бы не помешало.
Нужно нам использовать уникальные числовые ключи, а primary key их сделать нельзя. И при запросе генерировать тоже нельзя - во время заполнения новой формы юзер уже желает видеть ее номер. Если серии номеров с “дырками” - не беда. Лишь бы шли в возрастающем порядке.
Другое дело, что MSSQL (гадость та еще, но мы привязаны к backend) не позволяет делать генераторы.
Т.е. у него есть uniqueidentifier - но это GUID. А пользователи хотят видеть простое инкрементирующееся число. Его легче прочитать и очевидно, что если число больше - значит оно новее.
Вот и извращаемся с несколькими таблицами по одному IDENTITY в каждой - вместо генераторов.
Неприятно до омерзения.
PooH
Март 23, 2009 07:37:50
Андрей Светлов
Нужно нам использовать уникальные числовые ключи, а primary key их сделать нельзя. И при запросе генерировать тоже нельзя - во время заполнения новой формы юзер уже желает видеть ее номер. Если серии номеров с “дырками” - не беда. Лишь бы шли в возрастающем порядке.
У вас нет сервера приложений? двухзвенка?
PooH
Март 23, 2009 10:16:07
Андрей Светлов
А здесь опять сложно…
Спасибо. Интересно. Прямо “Долгий путь к XP в лицах” :)
baloo
Март 24, 2009 19:14:25
PooH
Прошу прощения, просто из любопытства, а зачем вам на клиенте знать значение генератора?
Если запись идентифицируется только по ID, то при inserte новой записи уже надо этот ID знать. Чтобы перейти c def New на def View. Во-вторых, генераторы в FireBird используются не только для подстановки ID через триггер. Это самостоятельная штука, и его можно использовать, к примеру, для генерации уникальных страховых номеров