26.11.2007, 16:25 | #1 |
Заноза в заднице
|
Простая задача нумерации элементов
В связи с особенностями ведения документооброта компании есть потребность назначения уникального номера каждому клиенту, будь-то организация либо контакт. Значит, мыслю так, что нужно создать новый объект "Нумератор", в атрибуте которого будет храниться значение номера. После присвоения номера текущее значение изменяется и сохраняется.
Условия такие, а вот с реализацией что-то не очень... то есть пока совсем никак. К тому же есть сомнения по поводу обсепечения уникальности: ну например, есть опасность, что два пользователя одновременно прочитают один номер и присвоят его разным элементам. Вопросы собсна такие: 1. Как вообще подходить к решению подобных задач? 2. Если возможно - приведите пример скрипта, который в момент открытия формы нового элемента получает значение номера из другого объекта? 3. Как избежать дублирования и обеспечить такое чтение объекта пользователем, в момент которого остальные пользователи запросив это значение, смогут прочесть лишь после того, как первый пользователь запишет новое значение? |
|
27.11.2007, 08:16 | #2 |
Moderator
|
Думаю, что объект тут точно не нужен. Задача получения уникального ключа записи до момента ее сохранения в БД записи, во всех субд решается созданием Sequence, но Microsoft и тут идет своей дорогой упрямо напирая на отсуствие такой необходимости. Сиквенс - просто счетчик. Читаешь его - он возвращает текущее значение и тут же перещелкивается на новое. Счетчик нетранзкционен и используется в монопольном редиме (один пользователь за раз) - короче то что доктор прописал! Жаль что в случае с Microsoft SQL Server он отсутствует. Есть только Work Around:
http://blogs.msdn.com/sqlcat/archive...ce-number.aspx Мое видение: на событие загрузки формы ставим скрипт который получает номер такого "псевдо сиквенса" и вставляет его в поле доступное только для чтения... |
|
27.11.2007, 14:07 | #3 |
Участник
|
Можно использвать preCreateCallout, который получит последний номер, прибавит 1 и присвоит номер. Где-то проходила информация от майкрософт, что callout блокирует работу crm до своего выполнения, т.е. уникальность обеспечивается.
|
|
27.11.2007, 15:16 | #4 |
Moderator
|
А где preCreateCallout возьмет последний номер? Предлогаете каждый раз перебирать все записи чтобы найти его значение? В данном случае просто взять количество записей не прокатит, так как необходима уникальность: сдалали 5 записей, 3ю удалили, осталось 4; при сохранении новой две последнии окажутся 5ыми.
Кроме того, я так понял, необходимо сразу же показать пользователю какой номер будет у нового клиента? Вообще говоря странно что разработчики не поделились с нами этой функциональностью, так как подобный механизм уже работает при создании заказов и статей забы знаний - там мы до сохранения объекта видим какой код он получит. |
|
27.11.2007, 20:48 | #5 |
Участник
|
Нет, зачем же перебирать. Можно использовать дополнительную сущность, запись которой хранит последний номер.
Если нужно сразу показывать номер на форме, можно попробовать вызвать свою страницу, которая произведет те же действия, что и callout, из скрипта с помощью ActiveX объекта Код: var oXmlDoc = new ActiveXObject("Microsoft.XMLDOM"); oXmlDoc.async = false; oXmlDoc.load("url страницы"); ..... |
|
28.11.2007, 08:23 | #6 |
Moderator
|
Складывается впечатление, что нам эта тема уже интереснее чем ее создателю. Где значение хранить не важно, в общем-то. Интересно как это реализовано в самой CRM и можно ли ей "упасть на хвост"? Есть же настройки даже - префиксы счеткика заказов, статей, еще чего-то там. Где-то в системе должна быть закодирована эта функциональность!
|
|
29.11.2007, 14:59 | #7 |
Участник
|
Вообще то там на конце номера для заказов\ счетов\ и т.д. случайно комбинируемая последовательность букв, поэтому думаю они эту проблему не решили : ).
|
|
29.11.2007, 15:53 | #8 |
Moderator
|
Это да. А еще я заметил, что до момента сохранения заказа код-то и не показывают! Так что, думаю, можно особо и не париться - берем дату создания: new Date().dateVal - количество милисекунд в текущей дате и не паримся.
Конечно, остается вероятность дублирования, но она исчезающе мала. |
|
03.12.2007, 16:20 | #9 |
Заноза в заднице
|
|
|
14.03.2008, 07:52 | #10 |
CRM
|
Likefire
Ну и как примерчик? |
|
|
За это сообщение автора поблагодарили: Likefire (1). |
18.03.2008, 15:19 | #11 |
Заноза в заднице
|
Цитата:
Сообщение от ShurikEv
Likefire
Ну и как примерчик?
__________________
Лень мудрого человека - это необходимое средство нейтрализации кипучей активности руководящих им дураков! |
|
|
За это сообщение автора поблагодарили: ShurikEv (1). |
18.03.2008, 15:49 | #12 |
CRM
|
Пример познователен. В виду того, что callout'ы синхронны, действительно можно так делать. У Вас реально прошит GUID пользователя, от имени которого необходимо выполнить веб-сервис (CallerId)? Не совсем правильно, но не в этом суть, т.к. это легко обходится
|
|
18.03.2008, 16:25 | #13 |
Заноза в заднице
|
Ну в книге пример построен таким образом, и кажется в предисловии я должен был отметить, что (цитата): "...Данный пример демонстрирует мощь и эффективность метода работы от имени другого пользователя." В моем примере GUID зашит жёстко, но Вы прекрасно знаете методы, как получить нужный Вам (в примере книги, кстати, тоже подставляется конкретный GUID).
__________________
Лень мудрого человека - это необходимое средство нейтрализации кипучей активности руководящих им дураков! |
|