Напоролся на такую особенность. Обычно получаешь документ с его табличными частями, там у каждой строчки есть LineNumber по порядку, и пропуски делать нельзя. Т.е., удаляешь строку из ТЧ - нужно перенумеровать.

Получаю документ УстановкаЦенНоменклатуры из УТ 11.4.6.174 / 8.3.13.1644, там в табличных частях LineNumber идет в таком порядке:
1, 1, 2, 3, 5, 4, 5, 6, 9, 7, 8, 9, 13, 10, 11, 12, 17, 13, 14, 15.
Т.е., все что могло с индексом массива пойти не так - пошло не так: дубли, пропуски, номера не по порядку.

Если смотреть в SQL, там LineNo и _keyfield идут в строгом порядке с 1 по 20 и с 0x00 по 0x13.

Естественно, даже если ничего не изменять и послать обратно ту же табличную часть в PATCH - естественно, вываливает 500.

В этом месте я просто строки перенумеровал, и все взлетело.

Но простите, ч-ч-что за ерунда? Уж не из-за этой ли особенности в документации прописано, что ТЧ в патче нужно слать целиком, а не по частям?

Если я буду везде перенумеровывать ТЧ перед отправкой, пользователи будут обнаруживать свои документы не в том порядке, в котором они их оставляли - это нехорошо.

Ну ты же уже сообщил об ошибке в 1С, правда?

(0) > Если смотреть в SQL, там LineNo и _keyfield идут в строгом порядке

Нет.

(2)


SELECT
  pspk."НомерСтроки",
  pspk._keyfield
FROM names."Документ_УстановкаЦенНоменклатуры_Товары" pspk
WHERE
    pspk."Ссылка_Ссылка" = names.guid2bytea('01239740-7a6a-11e6-f487-1efb12b8561c')
;


1,E'\\x00000000'
2,E'\\x00000001'
3,E'\\x00000002'
4,E'\\x00000003'
5,E'\\x00000004'
6,E'\\x00000005'
7,E'\\x00000006'
8,E'\\x00000007'
9,E'\\x00000008'
10,E'\\x00000009'
11,E'\\x0000000A'
12,E'\\x0000000B'
13,E'\\x0000000C'
14,E'\\x0000000D'
15,E'\\x0000000E'
16,E'\\x0000000F'
17,E'\\x00000010'
18,E'\\x00000011'
19,E'\\x00000012'
20,E'\\x00000013'


(3) Без указания ORDER BY порядок результатов неопределен. SQL сервер отдает тебе записи в зависимости от настроения диска, прогрева кэша, загрузки памяти и прочих фаз луны на небе.

Эту классику даже джуниоры знают.

(4) Хорошо. Я имел в виду, что нет дублей и пропусков.

(4) "SQL сервер отдает тебе записи в зависимости от настроения диска, прогрева кэша, загрузки памяти и прочих фаз луны на небе. "

Чаще всего он отдаёт порядок по использованному индексу. В запросе сверху это кластерный.

(6) > это кластерный
Преклоняюсь перед гуру, прозревающим план запроса по имени вьюхи

(7) план запроса здесь вообще не тема обсуждения, нажрался - спи.

Я обратил внимание, что LineNumber в OData может не совпадать с LineNo в SQL, и пытаюсь выяснить, нормальное ли это поведение системы, и чего от нее еще ожидать.

OData перспективный, но пока еще очень черный ящик, который 500 выдает направо и налево, а что ему не нравится - часто не объясняет ни в ответе, ни в техножурнале.

(0) > В этом месте я просто строки перенумеровал, и все взлетело.

И таки да, ничего не взлетело. Небольшая часть документов патчится, а большая - все еще 500 с пустым сообщением, зависимость пока не нашел.

(9) зависимость нашел: если есть поле 'НастройкиКомпоновкиДанных_Base64Data' - то обратно его не принимает, только 'НастройкиКомпоновкиДанных' в декодированном из base64 виде.