Простая задача нумерации элементов

[Likefire]

В связи с особенностями ведения документооброта компании есть потребность назначения уникального номера каждому клиенту, будь-то организация либо контакт. Значит, мыслю так, что нужно создать новый объект "Нумератор", в атрибуте которого будет храниться значение номера. После присвоения номера текущее значение изменяется и сохраняется.
Условия такие, а вот с реализацией что-то не очень... то есть пока совсем никак. К тому же есть сомнения по поводу обсепечения уникальности: ну например, есть опасность, что два пользователя одновременно прочитают один номер и присвоят его разным элементам.
Вопросы собсна такие: 1. Как вообще подходить к решению подобных задач?
2. Если возможно - приведите пример скрипта, который в момент открытия формы нового элемента получает значение номера из другого объекта?
3. Как избежать дублирования и обеспечить такое чтение объекта пользователем, в момент которого остальные пользователи запросив это значение, смогут прочесть лишь после того, как первый пользователь запишет новое значение?

[Артем Enot Грунин]

Думаю, что объект тут точно не нужен. Задача получения уникального ключа записи до момента ее сохранения в БД записи, во всех субд решается созданием Sequence, но Microsoft и тут идет своей дорогой упрямо напирая на отсуствие такой необходимости. Сиквенс - просто счетчик. Читаешь его - он возвращает текущее значение и тут же перещелкивается на новое. Счетчик нетранзкционен и используется в монопольном редиме (один пользователь за раз) - короче то что доктор прописал! Жаль что в случае с Microsoft SQL Server он отсутствует. Есть только Work Around:
http://blogs.msdn.com/sqlcat/archive...ce-number.aspx
Мое видение: на событие загрузки формы ставим скрипт который получает номер такого "псевдо сиквенса" и вставляет его в поле доступное только для чтения...

[Lida]

Можно использвать preCreateCallout, который получит последний номер, прибавит 1 и присвоит номер. Где-то проходила информация от майкрософт, что callout блокирует работу crm до своего выполнения, т.е. уникальность обеспечивается.

[Артем Enot Грунин]

А где preCreateCallout возьмет последний номер? Предлогаете каждый раз перебирать все записи чтобы найти его значение? В данном случае просто взять количество записей не прокатит, так как необходима уникальность: сдалали 5 записей, 3ю удалили, осталось 4; при сохранении новой две последнии окажутся 5ыми.
Кроме того, я так понял, необходимо сразу же показать пользователю какой номер будет у нового клиента?
Вообще говоря странно что разработчики не поделились с нами этой функциональностью, так как подобный механизм уже работает при создании заказов и статей забы знаний - там мы до сохранения объекта видим какой код он получит.

[Lida]

Нет, зачем же перебирать. Можно использовать дополнительную сущность, запись которой хранит последний номер.
Если нужно сразу показывать номер на форме, можно попробовать вызвать свою страницу, которая произведет те же действия, что и callout, из скрипта с помощью ActiveX объекта

var oXmlDoc = new ActiveXObject("Microsoft.XMLDOM");
oXmlDoc.async = false;
oXmlDoc.load("url страницы");
.....

Только это ненадежно, скрипт можно отключить.

[Артем Enot Грунин]

Складывается впечатление, что нам эта тема уже интереснее чем ее создателю. Где значение хранить не важно, в общем-то. Интересно как это реализовано в самой CRM и можно ли ей "упасть на хвост"? Есть же настройки даже - префиксы счеткика заказов, статей, еще чего-то там. Где-то в системе должна быть закодирована эта функциональность!

[Likefire]

Цитата:

Сообщение от Enot Poloskun

Складывается впечатление, что нам эта тема уже интереснее чем ее создателю.

Это только впечатление. ;-) На самом деле тема очень интересна и я даже нашел один примерчик в книге. Я попробую, как он вообще работает и тогда обязательно отчитаюсь, как и чего.

[sam]

Вообще то там на конце номера для заказов\ счетов\ и т.д. случайно комбинируемая последовательность букв, поэтому думаю они эту проблему не решили : ).

[Артем Enot Грунин]

Это да. А еще я заметил, что до момента сохранения заказа код-то и не показывают! Так что, думаю, можно особо и не париться - берем дату создания: new Date().dateVal - количество милисекунд в текущей дате и не паримся.
Конечно, остается вероятность дублирования, но она исчезающе мала.

[ShurikEv]

Likefire
Ну и как примерчик?

[Likefire]

Цитата:

Сообщение от ShurikEv

Likefire
Ну и как примерчик?

Вот: Разбор кода примеров SDK, а также разных прочих

[ShurikEv]

Пример познователен. В виду того, что callout'ы синхронны, действительно можно так делать. У Вас реально прошит GUID пользователя, от имени которого необходимо выполнить веб-сервис (CallerId)? Не совсем правильно, но не в этом суть, т.к. это легко обходится

[Likefire]

Ну в книге пример построен таким образом, и кажется в предисловии я должен был отметить, что (цитата): "...Данный пример демонстрирует мощь и эффективность метода работы от имени другого пользователя." В моем примере GUID зашит жёстко, но Вы прекрасно знаете методы, как получить нужный Вам (в примере книги, кстати, тоже подставляется конкретный GUID).