и ишо - digest search так и делает - как написал @savl
[DOUBLEPOST=1425481932,1425481856][/DOUBLEPOST]

это в @urlencode? мммм, ну щас

не понял

 

и ишо - digest search так и делает - как написал @savl
[DOUBLEPOST=1425481932,1425481856][/DOUBLEPOST]не понял

Просто я думалъ
Все получилось. Пасиба. Возможно, так и будем
Function URLEncode(s As String, cset As String) As String
Dim v As Variant
v= Evaluate(|@URLEncode("| + cset + |";"| + s + |")|)
URLEncode= v(0)
End Function
Set DivisionByCode=db.GetView("DivisionByCodeURLEncode")
Dim dc As NotesDocumentCollection
Print URLEncode(KSTR, "Domino")
Set DivisionDoc=DivisionByCode.GetDocumentByKey(URLEncode(KSTR, "Domino"),True)
If Not DivisionDoc Is Nothing Then
Print "Вижу" + DivisionDoc.Division(0) + DivisionDoc.Code(0)
End If

 

Выводы - GetDocumentByKey по ключам, содержащим символы чужих кодировок, лучше делать, прогнав и колонку в виде через @URLENCODE, и аргумент через функцию, кодирующую в BASE-64. Ну, либо через GetAllDocumentsByKey со сравнением значений.
А вот почему данная функция выдает такую ошибку, я, пожалуй, запрошу ibm
PS: костыль с бантиком

 

или еще хлеще - пассворд по двум одинаковым последовательностям сгенерит мне разные значения..... и будет совсем красота

Теоретически может с мизерной вероятностью. Хотя ваш ключ тоже сгенерён односторонней функцией - зуб даю! А НИ ОДНА односторонняя функция не даст 100% гарантии индивидуальности, тем более с таким коротким результатом (даже mod2 c идеальным случайным числом не меньше второго слагаемого, чего не бывает в принципе). Иначе не было бы проблемы идеального шифрования.
Мне кажется Вы мудрите.
-------------------------------
Но это так, теория. А ващще, принимая сторонний док, можете сгенерить новый ключ по любому алгоритму, который считаете надёжным, хоть UNID.

 

Хотя ваш ключ тоже сгенерён односторонней функцией - зуб даю!

вполне возможно, а алгоритм создания ключей в домине - хэш ф-ция
вот, возможно, в коллизию и воткнулись

 

Мне кажется Вы мудрите.

Нет, я, напротив, считаю усложнением замену существующих ключиков. Пусть будут такими, как есть, тем более что они нужны только на этапе синхронизации иерархии документов со сторонним приложением, которое является источником.
Далее они мне не нужны и не используются. Поэтому, если у них выйдет дубль, то это будет у них проблема, а вот если у нас - то уже моя. И зачем?
Через @UrlEncode все-же, считаю, красивее.

 

нашел свои изыскания Rus Кодировка Query_string В Ls Documentcontext
к делу относится косвенно, использует др. бридж (LS2J вместо собак)

 

Интересная дискуссия... один в один как форумах RDBMS )