Данные истории не найдены |
Я |
05.02.22 — 13:31
Всем привет!
Подскажите, пожалуйста, что с этим делать?
Включил историю изменения для документа, изменил документ, вижу появившуюся версию.
Пытаюсь ее открыть, получаю сообщение «Данные истории не найдены» (без подробностей).
Что бы это значило?
1 — 05.02.22 — 15:00
(0) Давно включили (больше 30 дней)? Код ниже выполняли?
ИсторияДанных.ОбновитьИсторию(Истина, Истина);
2 — 05.02.22 — 15:19
Для новых документов корректно отрабатывается история?
В версионировании БСП в регистр каждый раз при изменении записывается полная версия объекта (в реквизит запихали 100мб данных и привет).
В платформенной истории фиксируются именно изменения, т.е. при 1-ой записи полная версия сохраняется и потом при изменении реквизитов фиксируется только изменение этого реквизита.
Если программно удалять старые версии, то ничего хорошего не получится (нельзя корректно вернуться на указанную версию). Почему-то не добавили механизм создания полного слепка по номеру версии с возможностью удаления предыдущих изменений.
Предположу, что 1-ая версия документа у вас удалена.
3 — 05.02.22 — 18:30
Там еще есть обработка версии,нсли галочку автоматически не поставили,то система ожидает обработки и только после этого версию можно будет увидеть.
4 — 06.02.22 — 09:58
(2) для некоторых документов и справочников корректно, для некоторых нет. Системы в этом так и не нашел.
Я попытался очистить историю полностью:
— отключил использование истории для документа (ИсторияДанных.УстановитьНастройки(МойОбъектМетаданных, Неопределено)
— удалил программно все версии
— включил историю
— сделал несколько изменений документа, увидел версии в истории версий
— при попытке открыть получил «Данные истории не найдены»
Может быть надо как-то иначе «резетнуть» ведение истории, чтобы для документа начать всё с начала?
5 — 06.02.22 — 09:59
(3) вы про обновление истории? ИсторияДанных.ОбновитьИсторию()?
6 — 06.02.22 — 11:21
(5)да
7 — 06.02.22 — 12:53
(4) и какой номер версии после этих манипуляций?
8 — 06.02.22 — 13:11
Т.е. в истории должна быть версия 1, рисунок с плюсом (добавление). Остальные версии с карандашом (изменение).
9 — 06.02.22 — 18:23
(8) Если историю включили после того, как объект был создан, то будут только версии с карандашом.
10 — 07.02.22 — 09:16
(7) номер версии действительно не обнуляется, и версии с карандашом. После отключения/включения номер первой появившейся версии — 12.
11 — 07.02.22 — 09:17
(6) на обновление истории есть регламентное задание. При экспериментах я обновление истории запускаю кнопкой.
12 — 07.02.22 — 09:30
(10) Как обнулить — не знаю, там несколько системных таблиц:
1. Текущая версия
2. Очередь с версиями
3. Основная таблица с версиями
Может еще что-то забыл, видимо когда отключаете ведение истории таблица с текущими версиями не обновляется и при записи документа сравниваются данные таб.1, записываются изменения в таб.2, записывается новая версия в таб.1.
13 — 07.02.22 — 09:46
В своё время помогло мне, но у меня задача другая была.
https://infostart.ru/1c/articles/1161879/
14 — 07.02.22 — 09:58
(13) это я читал, да, спасибо. На ИТС размещение данных истории по таблицам — тоже читал.
Но решения своей проблемы я пока не вижу. Как мне представляется, надо как-то «правильно» отключить/включить ведение истории. Удаление версий и программное отключение, как я делал — видимо, это неправильно.
Осложняется тем, что у меня нет прямого доступа к SQL-серверу, т.е. решить вопрос хотелось бы на стороне 1С.
15 — 07.02.22 — 11:21
(14) Снял признак хранения истории в конфигураторе у документа.
Выполнил:
ИсторияДанных.УдалитьВерсии(Метаданные.Документы.НазваниеДокумента);
Включил обратно, записи начали создаваться с 1-ой версии. Вся история удалилась.
orcdunaev
16 — 07.02.22 — 21:24
Всем спасибо, разобрался!
У меня неправильно удалялись версии.
В коде отрабатывала не ветка условия, где:
ИсторияИзменений.УдалитьВерсии(ОбъектМетаданных)
а ветка, где:
ИсторияДанных.УдалитьВерсии(ОбъектМетаданных, ПорогХранения).
При этом ПорогХранения = ТекущаяДата();
Видимо, это привело к таким результатам, что удалилась базовая версия документа… Хотя мне почему-то кажется, что это не самое ожидаемое поведение…
Ошибка при заполнении СТД-Р
Добрый день! ЗУП 8.3 (8.3.18.1289). Оформила приказ на увольнении сотрудника. СЗВ-ТД оформлена и передана в ПФР. В справке СТД-Р не отражается увольнение. Пишет, что не найдены сведения с идентификатором, при этом СЗВ-ТД ссылается на мероприятие с другим кодом идентификации. Как заполнить СТД-Р? Скрины прилагаю.
Я пробую IB очень первый раз. Я пытаюсь получить исторические данные о $EUR, но получаю сообщение об ошибке:
Ошибка 162, reqId 3: сообщение об ошибке службы исторических рыночных данных: нет исторических рыночных данных для EUR/CASH@FXSUBPIP за последние 1800, контракт: Contract(secType=’CASH’, symbol=’EUR’, exchange=’IDEALPRO’, currency= ‘ДОЛЛАР США’)
Ниже мой код:
import datetime
from ib_insync import *
if __name__ == '__main__':
ib = IB()
r = ib.connect('127.0.0.1', port=7497, clientId=1)
contract = Contract()
contract.symbol = "EUR"
contract.secType = "CASH"
contract.currency = "USD"
contract.exchange = "IDEALPRO"
data = ib.reqHistoricalData(
contract=contract,
endDateTime='',
durationStr='100 D',
barSizeSetting='30 mins',
useRTH=True,
whatToShow='ADJUSTED_LAST'
)
2 ответа
https://interactivebrokers.github.io/tws-api/historical_bars.html#available_products_hd
Вы можете видеть, что whatToShow='ADJUSTED_LAST' должен быть чем-то доступным для форекс, например MIDPOINT. Очевидно, что никаких дивидендов, на которые можно было бы рассчитывать, нет.
Кроме того, нет реальной биржи форекс и исчерпывающих данных, все, что вы получаете, это то, что происходит в IB.
1
brian
29 Сен 2022 в 13:54
Проблема здесь не в определении самого контракта FOREX, а в запрошенных настройках бара.
durationStr=’100 D’,
barSizeSetting=’30 минут’,
Параметр barSizeSetting недоступен для выбранной продолжительности Str. Если вы проверите графический интерфейс TWS и откроете график исторических данных для контракта FX, вы увидите, что самый низкий размер бара, доступный для продолжительности 100 дней, составляет 2 часа.
Вы всегда должны проверять, доступна ли функциональность, которую вы требуете от API, через графический интерфейс TWS. API IBKR взаимодействует либо с TWS, либо с IBGateway, которые, в свою очередь, отправляют запрос в IBKR. Если функция недоступна через графический интерфейс, она, скорее всего, недоступна через API.
0
A_Trader
29 Апр 2023 в 05:35
I’ve a SQL query where if output is NULL it should not send warning .
l_sup_id NUMBER;
begin
SELECT per_all_assignments_f.supervisor_id
INTO l_sup_id
FROM per_all_assignments_f
WHERE person_id = p_person_id
AND trunc (sysdate) BETWEEN effective_start_date
AND effective_end_date
AND primary_flag = 'Y';
elsif (p_person_type = 'APPRAISER' AND l_sup_id IS NOT NULL) then
hr_utility.set_message(801, 'HR_51888_APR_APPRAISER_NULL');
hr_utility.raise_error;
end if;
Whenever l_sup_id is null according to logic
hr_utility.set_message(801, 'HR_51888_APR_APPRAISER_NULL');
should not be executed
But whenever l_sup_id is null I am getting
ORA-01403: no data found
error in logs
If l_sup_id is not null application working is fine
jarlh
42k8 gold badges45 silver badges63 bronze badges
asked Apr 28, 2015 at 6:52
5
From documentation,
NO_DATA_FOUND
A SELECT INTO statement returns no rows, or your program references a
deleted element in a nested table or an uninitialized element in an
index-by table.
In your PL/SQL code, the SELECT .. INTO statement returns no rows, thus it raises NO_DATA_FOUND error. It never goes to the next line, i.e. your IF-ELSE construct.
If you want to continue the operation, then you need to handle the EXCEPTION gracefully.
For example,
SQL> SET serveroutput ON
SQL>
SQL> DECLARE
2 o_ename emp.ename%TYPE;
3 i_empno emp.empno%TYPE;
4 BEGIN
5 SELECT ename INTO o_ename FROM emp WHERE empno = i_empno;
6 -- Handle no_data_found
7 EXCEPTION
8 WHEN no_data_found THEN
9 -- do something
10 dbms_output.put_line('No records found for employee no '|| i_empno);
11 END;
12 /
No records found for employee no
PL/SQL procedure successfully completed.
SQL>
answered Apr 28, 2015 at 7:11
Lalit Kumar BLalit Kumar B
47.3k13 gold badges96 silver badges123 bronze badges
As the error suggests its pointing to NO DATA for the condition, to handle that you need to use «Exception Handling», Please see the code for the changes,
declare
l_sup_id NUMBER;
begin
SELECT per_all_assignments_f.supervisor_id
INTO l_sup_id
FROM per_all_assignments_f
WHERE person_id = p_person_id
AND trunc (sysdate) BETWEEN effective_start_date
AND effective_end_date
AND primary_flag = 'Y';
elsif (p_person_type = 'APPRAISER' AND l_sup_id IS NOT NULL) then
hr_utility.set_message(801, 'HR_51888_APR_APPRAISER_NULL');
hr_utility.raise_error;
end if;
--changes start
exception
when no_Data_found then
dbms_output.put_line('No data exists for lsup '|| l_sup_id)
--changes end
end;
Edit:
SQL> SELECT * FROM TESTEMP WHERE EMPNO=6677;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
6677 JUPITER CLERK 7902 17-DEC-80 800 20
SQL>
SQL> declare
2 l_count number;
3 begin
4 select comm into l_count from testemp where empno=6677 ;
5 DBMS_OUTPUT.PUT_LINE('lcount is'||l_count);
6 if (l_count IS NULL) then
7 dbms_output.put_line('no data');
8 else
9 dbms_output.put_line('data');
10 end if;
11 end;
12 /
lcount is
no data
PL/SQL procedure successfully completed.
Your condition wont go into the if at all if you compare to NULL or how ever you want to use it according to your specification
answered Apr 28, 2015 at 6:55
anudeepksanudeepks
1,0801 gold badge12 silver badges22 bronze badges
2
Thank you for all the responses.
Instead of plain sql I created the following cursor
cursor csr_supervisor_id
is
SELECT supervisor_id
FROM per_all_assignments_f
WHERE person_id = p_person_id
AND trunc (sysdate) BETWEEN effective_start_date
AND effective_end_date
AND primary_flag = 'Y';
and fetched it in l_sup_id
open csr_supervisor_id;
fetch csr_supervisor_id into l_sup_id;
Now no data received error is not coming.
answered Apr 28, 2015 at 7:55
Думаю, с этой ошибкой мало кто сталкивался. Для этого, во-первых, нужно работать со встроенной в платформу историей данных, а она не больно-то популярна: кто-то привязан к БСП (она пока использует привычное всем версионирование на регистрах сведений), кому-то не нравится реализация — там и правда не всё гладко с точки зрения производительности.
Во-вторых, нужно сделать так: выключить историю данных для объекта метаданных, а потом грохнуть накопленные версии объектов до того, как новые изменения объекта перекочуют из буфера в основную таблицу.
В двух словах о том, как вообще работает история данных. По дефолту она выключена, и достаточно привилегированный пользователь может включить её для нужных ему объектов — констант, справочников, документов и так далее. После этого при изменении данных в этих объектах платформа будет фиксировать, что именно меняется. Делает она это в два этапа: сначала — относительно быстрая запись в промежуточный буфер (таблицу _DataHistoryQueue0); потом, при вызове метода ОбновитьИсторию(), информация мигрирует в основное хранилище версий (таблицу _DataHistoryVersions) и становится доступна в интерфейсе приложения.
Обновление истории можно делать сразу при записи, но для сокращения транзакции его обычно выносят в регламентное задание. В итоге миграция данных из буфера в основную таблицу происходит с некоторой периодичностью: например, раз в пять минут. Так вот, если между изменением данных объекта и обновлением истории данных выключить историю объекта и удалить его версии — метод ОбновитьИсторию() выкинет исключение: он попытается переместить изменения из буфера в основную таблицу, но не сможет привязать их к уже накопленным данным.
Для наглядности — рабочий код, воспроизводящий проблему для справочника Items на платформе 8.3.17.1989. Можете подставить любой другой объект, с которым работает история данных — разницы нет.
Как избежать этой ошибки? Ну, очевидно: метод ОбновитьИсторию() нужно вызывать непосредственно перед тем, как отключать историю для объекта. Лучше всего делать это в период, когда пользователи с системой не работают: есть риск, что между обновлением истории и её выключением вклинятся чьи-то транзакции, которые спровоцируют ту же проблему. Для гарантии можно использовать монопольный режим.
Ещё в голову приходит исключительная блокировка на таблицу объекта, но документация не советует вызывать метод ОбновитьИсторию() внутри транзакций — так что тут я не уверен.
Как исправить эту ошибку? Включите историю данных для проблемного объекта, обновите историю и выключите её обратно. Выйдите, так сказать, из класса и зайдите нормально.
2021-06-08 17:12:05
1С