Передано значение недопустимого типа 1с
Обновлено: 06.07.2024
Доброго дня всем
1с 8.3 Работаю с бизнес -процессами. Возникла сложность при завершении.
Есть ТЗ: При завершении задачи "Ознакомится с результатом" завершить комплексный бизнес процесс и все незавершенные задачи по нему.
В форме ЗадачиИсполнителя есть кнопка. Команда на кнопке выполняется наКлиенте. В конце выполнения я и решила подпихнуть свою обработку. Которая выполняется в общем модуле.
Вот как я это делаю. Вызов общего (клиент) из команды формы (Параметр: форма задачи)
Вызов
Ну и в общем модуле я работаю уже непосредственно с задачей, ищу по ней бизнес-процесс, завершаю задачи.
Так вот теперь суть всего вопроса:
После завершения работы на сервере когда уже отладчик стоит на КонецФункции у меня неожиданно все сваливается в ошибку
ЧТо не так то?? Почитала кучу форумов и справок, но не нашла ответа на вопрос. Может кто поможет и опишет корректность выполнения процедур Клиент-Сервер-Клиент. Буду очень признательна за любую информацию по этому вопросу __________________
Помощь в написании контрольных, курсовых и дипломных работ здесь
Ошибка при вызове метода
Всем доброго утречка! Такой вот код написала, где программно создаю и хочу провести, но выдаёт.
Ошибка при вызове метода
Выдает ошибку в строке Ferma.ask(); хочу чтобы при запуске программы писало строчку, а потом.
СтрокаТаблицыЗначений
.
Доступность:
Сервер, толстый клиент, внешнее соединение.
Я не могу этого понять Функция из общего модуля не возвращает никакие значения.
По логике я просто прихожу в нее с задачей,ссылкой. Ее использую как параметр для запроса. Сама задача не перезаписывается, не изменяется. Из функции я просто выхожу не передавая никаких параметров.
Возникает вопрос откуда появляются эти данные с типом СтрокаТаблицыЗначений. Зачем они возвращаются?? Как они передаются и почему, если программно я их не передаю??
Именно это мне и хочется понять и разобраться, чтоб в будущем обойти эту проблему
З.Ы. ТЗ я выполнила, обошла другим путем. Вызвала свою обработку с из процедуры которая выполняется наСервере. Все отработало отлично без всяких проблем
Но все таки может кто знает и сталкивался с такими ситуациями?? Поделитесь опытом
Это уже на замененной обработке.
А при добавлении в регистре сведений "Контактная информация" такой ошибки нет.
(13) я решил проблему изменением в пару строк. Ошибка в том, что в функцию могут передаваться выборки из разных запросов, "как раньше" и "в новом формате". Если передается выборка "как раньше", то она не содержит в себе поля "Значение", по этому и возникает ошибка.
В Функции ПолучитьПредставлениеАдреса()
Строку:
после обновления на релиз 166.2
в справочнике Клиенты на закладке контакты
идет неправильная сортировка,
раньше все заполненные элементы были вверху,
а сейчас вверху находятся пустые строки, а заполненные строи идут в середине и в конце (15)
Внести изменение в общем модуле УправлениеКонтактнойИнформацией
Процедура ПрочитатьКонтактнуюИнформацию
Добавить строчку кода в конце процедуры:
Все сделал что указано у user1270445
Теперь вылезает ошибка такого рода
: Ошибка при вызове метода контекста (ЗаписатьJSON)
ЗаписатьJSON(ЗаписьJSON, Значение,, "АдаптацияПолейКонтактнойИнформации", УправлениеКонтактнойИнформациейСлужебный);
по причине:
Передано значение недопустимого типа
Если ПустаяСтрока(СтруктураЗаписи.Значение) Тогда (23) все добавилось без ошибок (на серверной базе). Роль Добавление и изменение адресной информации у пользователя включена. Установила релиз 1.3.167.1 + загрузила новый классификатор + добавила некоторым пользователям роль "Добавление и изменение адресной информации" - пользователи довольны)))
Описание:
В документе Начисление по больничному листу при повторном открытии уже введенного адреса очищаются введенные значения
Описание:
При проведении документа Реестр сведений ФСС о пособиях о нетрудоспособности возникает ошибка:
Не удалось разобрать адрес регистрации, возможно указан адрес а пределами РФ!
Описание:
В справочнике Медицинские организации после заполнения адреса не заполняется код КЛАДР
Способ исправления:
Общий модуль УправлениеКонтактнойИнформацией
Функция ПолучитьПолныйАдрес(Запись) Экспорт
Обработка РедактированиеКонтактнойИнформации
Форма ФормаЗаписиАдреса
Сейчас осталась проблема по вводу физлиц, если не знаешь индекс, то при вводе адреса индекс не добавляет. (39) Индекс добавляется когда номер дома выбирается из справочника, а не вводится вручную, как привыкли. (38) Можете поделиться костылем, а то из-за этого переводить всех на новый релиз не хочется!
(40) У нас ошибка: если ввод новой контактной информации делать через зеленый плюс, система запрашивает вид контактной информации и при выборе любого вида контактной информации вываливается ошибка : Поле объекта не обнаружено (Значение)
Если ПустаяСтрока(СтруктураЗаписи.Значение) Тогда
Причем эта ошибка проявляется не у всех, у некоторых пользователях ее нет, но разницы мы найти не можем
Там изменения в нескольких модулях. Не в одном месте. Лучше переходить сразу на 167.3, там еще часть ошибок исправлена. Или ждать 168. Обещают 2.11.Добрый день!
У меня 167.1
При добавлении новой контактной информации теперь не пишутся значения (дом, улица и т.д.) в ресурсы одноименного регистра (поле1, . поле10), соответственно в печатных формах всех документов пропали адреса, в полях форм также не выводятся, такак как представление строится запросом на основе этих значений
Подскажите, пожалуйста, это исправлено в следующих релизах?
(46) Проверяли до 167.3 - не исправлено. Ждем 168.1 Может там исправят. Разработчикам писали.На вскидку, думаю что если в модуле обработки Редактирование контактной информации
то должно работать
Пока не проверял.
(50)Да, так работает, контактную информацию (которая вводилась после обновления) нужно будет перезаписать (50) Поля заполняются. А почему может не заполняться "ТипДома", "ТипКорпуса", "ТипКвартиры"?Что я не так заполняю? На экране все поля заполнены и типы тоже. (50) В печатных формах документов адреса появились. Все хорошо. Большое спасибо. В 167.3 исправили при повторном открытии документа Начисление по б/л Поле5 чтобы не пропадало. Здравствуйте!
У нас немного другая конфигурация, но ошибки такие же в программе.
Подскажите, пожалуйста, у новых сотрудников в карточке Т-2, а именно в пункте
Адресе места жительства в ячейке "почтовый индекс" пустота.
Это нормально ?
До обновления такого не было.
При редактировании Адреса админ-территориально выдает ошибку
: Тип не определен (ФормаКлиентскогоПриложения)
ТипыСвойств.Вставить("ФормаВладелец", Тип("ФормаКлиентскогоПриложения"));
Обновил до 168.1 Но ОСТАЕТСЯ ПРОБЛЕМА!
Посмотрите пожалуйста, у кого база не сильно допилена, нет ли такой проблемы:
В случае исправления адреса у физлица, который ранее был заведен по КЛАДРу, в регистре контактной информации остаются старые поля (поле1,поле2,поле3….) из КЛАДРа и добавляется новая информация в поле «Значение» и Представление.
При заполнении документа начисление по больничному при выборе сотрудника автоматически в поле «адрес по регистрации» подставляется старая информация из КЛАДР. В Случае, если сотрудник новый, и адреса ранее не было, адрес по ФИАС не не подставляется в данное поле. Так же не заполняется совсем поле «Уник. Номер по ФИАС»
Возможно, данные проблемы есть в других документах, в которые подставляются данные из этого регистра.
(13) Похоже, что мой, но решение не подходит. У меня ошибка раньше возникает
(14) там несколько вариантов было.
Константа установлена?
Константы.ВестиУчетМаркируемойПродукцииИСМП.Установить(Истина)
(1) типичная ошибка разработчиков ОФ начинающих работать с УФ.
Нужно внимательно читать справку.
Начать с проверки конфигурации, на толстый клиент ОФ, тонкий клиент, внешнее соединение и сервер.
Обычно проблема в модуле объекта его код выполнялся в ОФ в толстом клиенте в УФ такое не возможно.
Или в регламентных заданиях.
Надо половинить комментариями текст процедуры и ловить строку на которой падает. Чисто обращение к свойству элемента
(4) Я так делал уже;) Полдня потерял, закомментил эту процедуру пока целиком. Это не единичный случай, в еще одной процедуре при создании такая же ошибка, потом при записи вальнулось - то же аналогичные конструкции используются
(8) Искал бинарным поиском, в каком месте рождается ошибка - комментил код половинами . Дошел до вызова этой процедуры. Процедура тоже не вся с ошибками. Это ее надо тоже комментить, чтобы найти участки проблемного кода. Кроме этой процедуры есть еще одна. И это только открытие формы. При записи аналогичные ошибки. Наверняка есть при изменении элементов формы. Короче, считаю, что искать неправильные конструкции и исправлять их на правильные - контрпродуктивно. Должно быть другое решение. Разработчики тестили же, что писали. Может в свойствах формы надо что-то выставить
Разберитесь, зачем нужен НаСервереБезКонтекста.
Попробуйте поменять на &НаСервере и выкинуть параметр Форма. В тексте процедуры заменить Форма на ЭтаФорма.
Если ошибка воспроизводится на демо-базе, то такое стоит писать на техподдержку.
(9) НаСервере пробовал ставить, Форма на ЭтаФорма, вот это всё. Повторюсь, проблема не в одной процедуре, так придется всю форму перелопатить. А насчет демки годный совет, спасибо, сейчас скачаю-посмотрю
Прогресс: В демке ошибка не возникает. Но. В этот документ конкретно, и в подсистему ИС МП изменений никаких не вносилось. Я обновление с ней накатил только 2 недели назад, и сел разбираться. Значит, дело в параметрах ИБ.
(19) Кэш чистил, пока только пользовательский. С серверным не так просто - работа круглосуточно идет.
(20) так нужно его по любому почистить. Что и ночью остановить нельзя? Должен же быть технологический перерыв даже при 24/7
(18) не шайтан, а внутренний кеш 1С. Как с ним работать можно посмотреть здесь .
Преподаватель 1С
Санкт-Петербург
зарплата от 100 000 руб. до 120 000 руб.
Временный (на проект)
Сериализуя этот объект в JSON, может быть получен следующий документ:
2. Объектная техника работы
2.1. Общая информация
Система «1С:Предприятие» поддерживает сериализацию следующих данных в формат JSON:
● Строка – сериализуется в строку;
● Число – сериализуется в число;
● Булево – сериализуется в литералы true и false;
● Неопределено – сериализуется в null
● Массив, ФиксированныйМассив – сериализуется в массив JSON в том случае, если любой элемент массива может быть сериализован в JSON.
● Структура, ФиксированнаяСтруктура – сериализуется в объект JSON:
● Ключ – ключ элемента структуры.
● Значение – значение элемента структуры в том случае, если значение может быть сериализовано в JSON.
● Соответствие, ФиксированноеСоответствие – сериализуется в объект JSON:
● Ключ – ключ элемента соответствия. Ключ может быть только значением типа Строка, в противном случае будет генерироваться исключение.
● Значение – значение элемента соответствия в том случае, если значение может быть сериализовано в JSON.
● Дата – формат сериализации определяется настройками.
● Если выполняется попытка сериализации типа, отсутствующего в данном списке – будет вызвано исключение.
При работе с объектной техникой, имеется возможность читать (и писать) данные в соответствие или структуру. Основное отличие между этими объектами состоит в том, что ключ элемента структуры подчиняется правилам формирования переменной на встроенном языке, а ключ элемента соответствия может быть любым. С учетом того, чтоб JSON не накладывает ограничений на значение ключа, не все JSON-документы можно
прочитать в структуру. Еще одним различием между структурой и соответствием является то, что к элементам структуры можно обращаться «через точку», а к элементам соответствия такой доступ не предоставляется. В связи с этим, может оказаться удобным получать данные в виде структуры, если ключи из JSON-документа соответствуют требованиям к ключам структур системы «1С:Предприятие».
Объектная техника предполагает достаточно простую работу с данными, однако платой за это является большой расход памяти, т. к. весь JSON-документ обрабатывается целиком в оперативной памяти.
2.2. Запись
Для того чтобы выполнить запись объекта в формате JSON, необходимо использовать (в простейшем случае) следующие объекты:
1. Собственно записываемый объект, например типа Структура.
2. Объект, обеспечивающий низкоуровневую запись данных в формате JSON – ЗаписьJSON.
3. Объект настроек сериализации НастройкиСериализацииJSON.
Метод глобального контекста ЗаписатьJSON() оперирует вышеперечисленными объектами. Рассмотрим пример, в котором потребуется записать структуру, которая состоит из трех элементов разного типа (но типы являются примитивными):
В результате работы данный пример сформирует следующий JSON-документ:
В результате работы данный пример сформирует следующий JSON-документ:
Если несколько расширить набор записываемых данных, например, добавить к ним значение типа УникальныйИдентификатор, то запись не будет выполнена. В результате исполнения кода:
Будет вызвано исключение:
Причиной такого поведения является то, что тип УникальныйИдентификатор не входит в состав JSON-сериализуемых типов данных системы «1С:Предприятие». Однако система предоставляет возможность «обойти» это ограничение: необходимо передать в функцию ЗаписатьJSON() имя функции обратного вызова, которая будет заниматься JSON-сериализацией неподдерживаемых объектов. Эта функция будет называться
функцией преобразования. При этом формат такой сериализации будет разрабатывать непосредственно сам прикладной разработчик. Надо понимать, что такая сериализация не будет универсальной, т. к. принимающая сторона, не обладающая знаниями о формате сериализации, не сможет прочитать переданные данные. Другими словами, формат сериализации необходимо разрабатывать совместно всеми сторонами обмена
такого рода данными.
С учетом вышесказанного, более сложный вариант обмена теперь происходит следующим образом:
● Вызывается функция сериализации объекта в формат JSON (ЗаписатьJSON()).
● Система «1С:Предприятие» для каждого элемента структуры, тип значения которого не сериализуется в формат JSON, будет вызываться функция преобразования.
● Функция преобразования анализирует переданный объект и принимает решение – отказаться от его записи или вернуть платформе значение, которое может быть сериализовано в JSON.
Доработанный код записи будет выглядеть следующим образом:
Следует обратить внимание, что функция преобразования должна быть объявлена с указанием ключевого слова Экспорт. Также следует помнить, что функция преобразования (в модуле управляемой формы) может быть описана только в «контекстной» части модуля, т. е. с использованием директивы компиляции &НаКлиенте или &НаСервере.
В результате работы приведенного примера будет сформирован следующий JSON-документ:
При создании функции преобразования следует помнить о следующих особенностях:
● Функция преобразования вызывается для значений всех типов, которые не поддерживают сериализацию в JSON (см. раздел 16.2.1).
● Если функция преобразования вернет значение, которое не может быть сериализовано в JSON – будет вызвано исключение.
● Если переданное значение является структурой, то вызов функции преобразования для элементов этой структуры будет вызваться до того, как в поток будет записано имя свойства этого элемента. В результате функция преобразования может отказаться от записи значения и структура формируемого JSON-документа не будет нарушена.
● Имя свойства будет передано в функцию преобразования только для элементов структур и соответствий.
2.3. Чтение
2.3.1. Общая схема
Чтение данных в объектной технике выглядит аналогично записи. Рассмотрим пример чтения файлов, которые формировались во время рассмотрения объектной записи (предыдущий раздел).
Документ имеет следующее содержание (с точностью до значения даты):
При чтении JSON-документа в переменную Данные будет сформирована структура вида:
Ключ = ДлинаЗаписи, значение = 20
Ключ = КлючЗаписи, значение = abcdefgh
Ключ = ДатаИзменения, значение = <значение даты и времени>
Такой вариант чтения хорошо подходит в том случае, если читаемые данные могут быть преобразованы в структуру или соответствие и все читаемые данные могут быть однозначно десериализованы без потери информации о типе. Если читаемые данные обладают сложной структурой или требуют выполнения дополнительных преобразований при чтении, то можно пойти двумя путями:
1. Получить соответствие (или структуру), в которое будет полностью загружен JSON-документ, и потом завершить преобразование с помощью обхода получившегося объекта.
2. Заниматься необходимым преобразованием непосредственно во время загрузки данных.
Для этого необходимо передать в функцию ПрочитатьJSON() имя функции обратного вызова, которая будет заниматься десериализацией JSON-данных в нужные объекты системы «1С:Предприятие». Эта функция будет называться функцией восстановления.
В обоих случаях прикладной разработчик должен знать, какие данные и в каком виде находятся JSON-документе. Далее будут подробно рассмотрены оба варианта загрузки данных. В качестве макетной задачи будет рассматриваться получение погоды в г. Москва с помощью некоторого интернет-сервиса. В качестве ответа интернет-сервис возвращает JSON-документ следующего содержания:
Кратко рассмотрим описание формата:
● id – идентификатор города;
● name – имя города;
● dt – дата и время получения погоды, в формате Unix, GMT;
● coord – местоположение города:
● lon – долгота;
● lan – широта.
● sys – дополнительная информация:
● country – страна расположения города;
● sunrise – время восхода Солнца в формате Unix, GMT;
● sunset – время заката Солнца, в формате Unix, GMT.
● weather – дополнительная информация о погоде:
● main – общая характеристика погоды;
● description – описание погоды.
● main – собственно описание погоды:
● temp – температура, в градусах Кельвина. Для получения градусов Цельсия необходимо вычесть 273.15;
● pressure – давление в гектопаскалях. Для перевода в миллиметры ртутного столба, надо значение давления умножить на 0,75.
● humidity – влажность в %.
● wind – параметры ветра:
● speed – скорость в милях в час. Для перевода в километры в час необходимо умножить на 1,61.
● deg – направление ветра, в градусах.
● clouds – информация об осадках:
● all – вероятность возникновения осадков, в %.
В результате загрузки этих данных должна получиться структура, где все времена представлены стандартным типом Дата, температура – в градусах Цельсия, скорость – в километрах в час, а давление – в миллиметрах ртутного столба.
Рассмотрим загрузку данной информации обоими способами. Данные записаны в файле c:\temp\weather.json.
2.3.2. Чтение с постобработкой
Собственно процесс чтения выглядит просто:
В результате в переменной Данные будет следующая информация:
Рис. 3 Результат загрузки
Без учета необходимости конвертации все выглядит предсказуемо. Однако дата и время автоматически не преобразовались. Можно попробовать указать системе на то, что поле dt (например) является полем, где находится дата и время:
Ошибка произошла потому, что система не понимает формат даты и времени, выраженной простым числом. Программный интерфейс работы с JSON предлагает функцию, помогающую выполнить конвертацию полей типа Дата – ПрочитатьДатуJSON(). Для использования этой функции необходимо привести десериализованную строку к формату, принятому, например, в JavaScript. В рассматриваемом примере получится
следующий программный текст:
В результате значение свойства Данные.dt станет равно значению 23.09.2014 13:35:40 (типа Дата). Остальная конвертация выполняется аналогичным образом.
2.3.3. Чтение с функцией восстановления
Вариант постобработкой выглядит не очень хорошо, если чтение JSON-документа предполагается выполнять в разных местах прикладного решения. В этом случае может возникнуть ситуация, когда код преобразования будет расположен в нескольких местах прикладного решения.
Хорошей заменой постобработки, в этом случае, является использование функции восстановления. Для применения функции восстановления необходимо описать саму функцию и несколько изменить само чтение документа:
В вышеуказанном примере присутствует особенность – функция восстановления будет вызвана для всех свойств, которые будут обнаружены в JSON-документе. Это не всегда удобно и, кроме того, существенно снижает производительность чтения JSON-документа (за счет вызова функции восстановления). Например, при чтении метеорологических данных нам необходимо выполнять особое преобразование только для свойств, в
которых содержится дата и время, а остальные свойства мы конвертировать не собираемся. Чтобы не анализировать в функции восстановления имя реквизита (как в вышеприведенном примере), можно поступить другим способом: явным образом передать в функцию чтения JSON-документа список реквизитов, которые содержат дату и время, а функцию восстановления написать исходя из того, что эта функция будет вызвана только для необходимых свойств. В результате получится следующий код:
Следует обратить внимание, что функция восстановления должна быть объявлена с указанием ключевого слова Экспорт. Также следует помнить, что функция восстановления (в модуле управляемой формы) может быть описана только в «контекстной» части модуля, т. е. с использованием директивы компиляции &НаКлиенте или &НаСервере. При разработке функции восстановления необходимо принимать во внимание тот факт, что свойства документа считываются не в том порядке, как они представлены в файле.
Рассмотрим последовательность, в которой свойства JSON-документа попадают в функцию восстановления. Для этого разместим в таблице каждое свойство файла и то, в каком порядке будет прочитано свойство:
В общем случае, можно сформулировать следующее правило обхода: первым будет прочитано свойство, которому не подчинено ни одно другое свойство. Например, свойству id не подчинено никакое свойство, и оно считывается первым. Однако свойству coord подчинено свойства lon и lat, поэтому вначале будут считаны эти свойства, а лишь затем – свойство coord, которое в качестве значения получит структуру (или соответствие) из подчиненных свойств документа.
3. Работа с XDTO-объектами
3.1. Общая информация
Работа с XDTO-объектами, в основном, ориентирована на обмен информации между системами, написанными на платформе «1С:Предприятие».
Однако сам механизм не накладывает никаких ограничений на его использование для обмена с другими системами.
JSON-сериализация XDTO-объекта выполняется сразу в JSON-документ, без формирования в памяти полной структуры сериализуемых объектов.
Также следует учитывать, что JSON-сериализация «эмулирует» XML-сериализацию, в силу чего получающийся JSON-документ внешне выглядит очень похоже на соответствующий XML-документ.
В JSON-документ могут быть помещены любые объекты системы «1С:Предприятие», для которых указано, что они могут быть сериализованы в XDTO. При попытке выполнить сериализацию значения неподдерживаемого типа будет вызвано исключение.
3.2. Запись
Для того чтобы выполнить запись XDTO-объекта в формате JSON, необходимо использовать (в простейшем случае) следующие объекты:
1. Собственно записываемый объект, поддерживающий преобразование в/из XDTO, например, элемент справочника.
2. Сериализатор XDTO-объектов – СериализаторXDTO;
3. Объект, обеспечивающий низкоуровневую запись данных в формате JSON – ЗаписьJSON.
4. Объект настроек сериализации НастройкиСериализацииJSON.
Собственно сериализация выполняется с помощью метода ЗаписатьJSON() объекта СериализаторXDTO. Рассмотрим пример сериализации данных типа СправочникОбъект. В качестве примера используется справочник Валюты, который содержит поля Курс (типа Число) и ДатаКурса (типа Дата):
Сериализация значений типа Дата выполняется в формате ISO (определяется механизмом XDTO) и не управляется при записи данных. Также не поддерживается использование функции преобразования при операции сериализации, в отличие от потоковой (см. раздел 16.2.4) и объектной (см. раздел 16.2.2) техник.
Также следует помнить о следующей особенности: при записи объекта не формируется его тип, поэтому после JSON-сериализации XDTO-объекта отсутствует возможность выполнить десериализацию без указания типа считываемого объекта. Предыдущий пример сериализации элемента справочника Валюты будет невозможно десериализовать без явного указания типа значения. Чтобы упростить ситуацию, можно воспользоваться
параметром НазначениеТипаXML метода ЗаписатьJSON() объекта СериализаторXDTO. Если в качестве значения этого параметра указать НазначениеТипаXML.Явное, то появится возможность выполнить десериализацию без явного указания типа, а сформированный файл будет выглядеть следующим образом:
С помощью JSON возможно выполнить сериализацию XDTO-объектов, которые не соответствуют какой-либо схеме. В этом случае используется явное описание типов реквизитов, одноименные свойства не будут объединяться в массив, а будут выводиться в JSON-документ поэлементно, в соответствии с XDTO-объектом.
Пример:
3.3. Чтение
В общем случае, чтение XDTO-объекта из JSON-документа аналогично записи. Чтение выполняется с помощью механизма чтения XDTO-объектов из XML-файла, поэтому чтение выполняется со следующими ограничениями:
● Возможно чтение только тех объектов, для которых существует XDTO-сериализация.
● Свойства в JSON-документе должны следовать в том же порядке, как и в XDTO-объекте.
● В случае если читаемый объект не соответствует схеме – будет вызвано исключение.
● Имеется возможность выполнять чтение произвольного JSON-документа в объект XDTO (ОбъектXDTO) с помощью фабрики XDTO (ФабрикаXDTO). Такое чтение возможно в том случае, если:
● фабрика XDTO, с помощью которой выполняется чтение, «знает» о типах, которые присутствуют в JSON-документе, из которого производится чтение.
● все элементы JSON указаны без явного указания типов и элементов, специфичных для JSON-документов, формируемых при сериализации объектов XDTO.
Выполнить чтение JSON-документа в том случае, если в нем используются типы, которые неизвестны фабрике XDTO, с помощью которой выполняется чтение документа – невозможно.
Рассмотрим пример чтения некоторого JSON-документа, например, полученного при работе примера работы со справочником Валюты из предыдущего раздела .
В результате работы примера в переменно Данные будет помещен объект типа СправочникОбъект.Валюты для валюты с кодом 978. Однако данное поведение будет наблюдаться только в том случае, если при выполнении JSON-сериализация значение параметра НазначениеТипаXML было установлено в значение Явное. В противном случае при попытке чтения (как указано выше) будет вызвано исключение. При чтении объекта с
неявным указанием типа объекта, читаемый тип можно передать в виде параметра метода ПрочитатьJSON(). В этом случае пример будет выглядеть следующим образом:
4. Потоковая техника работы
4.1. Общая информация
Потоковая техника работы с документом ориентирована на то, что документ целиком не загружается в память и обрабатывается последовательно, от элемента к элементу. Например, если надо прочитать только какой-то объект из JSON-документа, то потоковая техника может дать существенный выигрыш, особенно в том случае, если требуемый элемент находится в начале обрабатываемого документа.
4.2. Запись
Для того чтобы выполнить потоковую запись JSON-документа, необходимы записываемые данные и объект ЗаписьJSON. При этом следует понимать, что формирование корректной структуры JSON-документа полностью лежит на прикладном разработчике, который формирует документ. Для упрощения такого контроля объект ЗаписьJSON имеет свойство ПроверятьСтруктуру.
Рассмотрим простой пример записи документа:
В результате исполнения этого программного кода будет сформирован следующий документ:
Такой формат документа удобен для визуального просмотра, но занимает больше места. Можно изменить значение первого параметра конструктора ПараметрыЗаписиJSON на значение ПереносСтрокJSON.Нет и результирующий документ примет такой вид (разница составит примерно 20%):
4.3. Чтение
Потоковое чтение JSON-документа выполняется аналогично его записи: прикладной разработчик в цикле читает следующий элемент, определяет, что считано и обрабатывает считываемые данные.
Примитивный случай потокового чтения документа может выглядеть следующим образом:
При исполнении данного кода предполагается, что:
● Переменная КогдаСформировано содержит значение типа Дата. Содержит дату и время формирования JSON-документа.
● Переменная СписокЗаказов является массивом ссылок на документы заказов.
Исполнение данного код приведет к формированию следующего JSON-документа:
Изменяя значения параметров объектов НастройкиСериализации и ПараметрыJSON, а также манипулируя параметрами метода ЗаписатьДатуJSON(), можно изменять результирующий JSON-документ для максимального соответствия «ожиданиям» принимающей системы.
С подобной ошибкой я уже сталкивался, она обычно возникала, когда я пытался передать неправильные данные с сервера на клиент (результат запроса, например). Но путем трассировки я выяснил, что на этот раз ошибка возникает вовсе не при возврате из функции, а при передаче параметра с клиента на сервер! Призадумался я - параметр у функции единственный и является он ссылкой на элемент справочника. В соседней обработке такой же точно вызов отлично работает, а в этой не хочет работать совершенно. Любопытства ради сделал функцию, которая принимает один параметр (ноль) и возвращает тоже ноль. Не работает! Та же самая ошибка при вызове функции! Поэкспериментировав немного, я понял, что ошибка возникает при передаче ЛЮБЫХ параметров ЛЮБОГО типа с клиента на сервер О_о. Я никогда не сталкивался с подобным и решил проверить, чем моя нерабочая обработка отличается от рабочей. После недолгих изысканий я обнаружил единственное существенное различие в моих двух обработках - в новой обработке есть макет-таблица, а в старой нет. Чувствуя себя настоящим шаманом, выпилил процедуру загрузки макета на форму, и. внезапно все серверные процедуры и функции снова заработали О_о. Собственно вопрос, в чем дело? Процедуры и функции прилагаются!
Итак, ошибки при передаче параметров появляются после выполнения следующего кода:
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
Ошибка передачи данных между клиентом и сервером
Группы и элементы справочника "Номенклатура" имеют реквизит "Услуга". Если в группе меняется.
Ошибка передачи данных в dataGridView
Данный код должен передавать данные с 1 формы на другую в dataGridView. Но срабатывает исключение.
Ошибка передачи данных - сокеты
Проблема состоит в следующем: работаю с сокетами, пытаюсь передать три строки от клиента к серверу.
Ошибка канала передачи данных
Всем привет! студия XE5 postqresql установленная на виртуальной машине, все настроено по факу, до.
Читайте также: