Ошибка variable not found in subplan target lists

Описание ошибки:
Ошибка появилась в типовом функционале базы 1С:Управление торговлей 8, ред. 10.3 (релиз 10.3.66) после перехода из файлового варианта в клиент-серверный режим работы на релизе платформы 1С:Предприятие 8.3.16.1148 на PostgreSQL 12.5

Найденные решения:

Не смотря на то, что база не типовая, но ошибка начала появляться в типовом функционале. А именно при попытке выбора в документы товародвижения (Поступление/Реализация товаров и услуг) из формы списка справочника «Номенклатура» номенклатуры в табличную часть этих документом или при попытке получения значения типов цен.

Рис.1. Ошибка СУБД: ERROR: variable not found in subplan target lists при переводе базы на PostgreSQL 12.5

Возможно воспользоваться «Тестированием и исправлением информационной базы». В рамках тестирования будет осуществлена «Реиндексация таблиц информационной базы». Не забудьте перед тестированием создать архивную копию базы.

Если тестирование не поможет, то можно обратить внимание на следующие два момента.

Первый — проверить запросы на соответствие рекомендациям, которые даны в обсуждении на форуме forum.mista.ru, а так же другие мелкие советы по типу обновления релиза платформы 1С:Предприятие 8.

Второе — проверить значение параметра join_collapse_limit в файле конфигурации PostgreSQL. Не рекомендуется устанавливать значение «1» для 1С 8. Об этом более подробно можно прочитать в обсуждении к теме на сайте infostart, в которой  описано появление ошибки при попытке сформировать отчет «ОСВ» в базе 1С:УПП в режиме обычного интерфейса.

Проверка файла конфигурации (postgresql.conf в каталоге «data» для баз PostgreSQL) в данном примере показала, значение параметра было 20.

Установка значения параметра в «12» помогло и ошибка не возникала. Так же по рекомендации второго варианта из статьи возможно пробовать установить join_collapse_limit = 8 или join_collapse_limit = 12.

Главное, не забыть перед редактированием и сохранением файла конфигурации СУБД PostgreSQL отключить службу. После изменения и сохранения в файле службу нужно запустить.

Оцените, помогло ли Вам предоставленное описание решения ошибки?

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

29-12-2020

Журавлев А.С.
(Сайт azhur-c.ru)

bolero

25.12.18 — 17:13

VladZ

1 — 25.12.18 — 17:22

(0) Не пишите идиотские запросы. Или переходите на MS SQL.

bolero

2 — 25.12.18 — 17:30

lodger

3 — 25.12.18 — 17:44

bolero

4 — 25.12.18 — 17:52

(3) не совсем похоже, но пошел обновлять тестовый сетап на 8.3.14

deman_ru

5 — 13.01.19 — 22:52

(4) Помогла 14я платформа?

bolero

6 — 14.01.19 — 20:28

Cyberhawk

7 — 14.01.19 — 20:33

Сегодня зарелизилась 8.3.13.1690

lodger

8 — 14.01.19 — 20:38

(7) чем сильно лучше предыдущей?

Fram

9 — 14.01.19 — 22:25

(8) да, как обычно — старые ошибки поправили, новых добавили. надо же бизнес на плаву держать ))

DasHaar

10 — 15.01.19 — 13:35

bolero

11 — 15.01.19 — 14:30

DasHaar

12 — 15.01.19 — 14:34

bolero

13 — 15.01.19 — 15:03

Cyberhawk

14 — 15.01.19 — 19:11

(8) Пару каких-то больных ошибок пофиксили. Все что после 8.3.9.1850 — УГ какое-то.

shirik666

15 — 16.01.19 — 12:28

Тоже вываливается ошибка при формировании ОСВ за 18 год —  Postgre 10.5-9.1C, платформа 8.3.13.1644 конфигурация 1С:Управление микрофинансовой организацией и кредитным потребительским кооперативом КОРП. Кто-то пробовал писать на ЛК 1С? (12) проблема решилась откатом Postgre?

user713067

16 — 16.01.19 — 13:37

user713067

17 — 16.01.19 — 13:40

КЭш на рабочей станции чистил

shirik666

18 — 16.01.19 — 13:42

(16) думаю от прав пользователя это не зависит, видимо проблема в Postgre 10.5-9.1C и платформе…

Очевидно

19 — 16.01.19 — 13:49

(16) можт у неё (ГБ) какие-то поля дополнительно в СКД выведены ? попробуй у неё в ОСВ вернуть «Стандартные настройки»…

user713067

20 — 16.01.19 — 14:36

Очевидно

21 — 16.01.19 — 14:45

(20) Видимо осталось пошагово превратить «развёрнутое сальдо» в «Простую» (Т.е. по одному полю приводить рабочую в состояние нерабочей … и понять в каком месте начинает проявляться ошибка (думаю какое-то и полей криво отрабатывает) … а дальше уже смотреть при каких условиях это поле работает криво … и т.д.

DasHaar

22 — 16.01.19 — 16:29

DasHaar

23 — 16.01.19 — 17:39

shirik666

24 — 16.01.19 — 19:53

(22) простите за тупой вопрос, но как откатить  postgre до 10.3-3.1C? Какими образом вы это делали? Понятно, что забепкапить базу и инсталировать 10.3-3.1C на сервер, у меня win server 2012

DasHaar

25 — 17.01.19 — 10:26

alkomotiv

26 — 18.01.19 — 15:09

Сегодня вышла версия 10.5-10.1C. С нашей платформой 8.3.13.1644 — ошибка по-прежнему сохраняется (последнюю платформу 8.3.13.1690 не пробовали). PostgreSQL на Windows Server 2008 R2. Откатываемся к 10.3-3.1C, на виртуалке проверили — во всяком случае эта ошибка исчезла.

artemru

27 — 21.01.19 — 22:23

В оборотке зашел в Настройки — Стандартные настройки — Настройки с развернутым сальдо.  И Все сформировало!!  Платформа 8.3.13.1644  Postgres 10.5-9.1C  Релиз БП 3.0.67.67

user713067

28 — 23.01.19 — 06:28

bolero

29 — 24.01.19 — 15:56

(28) понизил join_collapse_limit с 20 до 1 — ОСВ в БП начала запускаться, зато установки цен в УТ не открываются (либо открываются бесконечность)

dmrjan

30 — 24.01.19 — 16:45

gni

31 — 24.01.19 — 22:32

palsergeich

32 — 24.01.19 — 22:43

(31) 13 платформу не ставь тока

gni

33 — 24.01.19 — 23:00

(32) 13 платформа уже стоит, причем не самая удачная (8.3.13.1513),  но пока вроде критичных для нас ошибок не замечено, поэтому пока останемся на ней.

gni

34 — 24.01.19 — 23:01

Поставил, т.к. на момент установки на сайте 1С было написано «Внимание! Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.13.1513. «

bolero

35 — 25.01.19 — 09:40

dmrjan

36 — 25.01.19 — 10:19

dmrjan

37 — 25.01.19 — 10:21

ansh15

38 — 30.01.19 — 10:43

bolero

39 — 30.01.19 — 12:25

bolero

40 — 30.01.19 — 12:26

(39) «apparently work somehow» бгг, чувствуются наши духовные скрепы

bolero

41 — 30.01.19 — 12:45

Елена Троянская

42 — 07.02.19 — 16:59

31.01 версия 8.3.14.1565 вышла, кто-нибудь пробовал обновлять для решения проблемы?

cruppy

43 — 07.02.19 — 17:18

Елена Троянская

44 — 08.02.19 — 20:09

апну

cruppy

45 — 10.02.19 — 12:08

(44) обновил на 8.3.14.1565, к сожалению проблема осталась… Что еще можно попробовать? Обновить Postgresql?

МихаилМ

46 — 10.02.19 — 14:15

(45) запрос в осв

ansh15

47 — 10.02.19 — 15:27

(46) Учитывая (23), видимо, над этим сейчас и бьются. Почти месяц уже…

cruppy

48 — 10.02.19 — 17:21

Елена Троянская

49 — 17.02.19 — 22:28

(48) +1, заработала ОСВ

DrZombi

50 — 17.02.19 — 22:47

(0) На версии 8.3.12 столкнулся с аномалиями в запросах (казалось бы простой запрос, не показывает данные),  а вы тут про оптимизацию размечтались

DrZombi

51 — 17.02.19 — 22:48

(1) май скуль тоже не гарантирует, 1С обещает

ansh15

52 — 18.02.19 — 01:49

rphosts

53 — 18.02.19 — 03:18

(52) не-не-не с такими приколами подожду годовщины десятки

bolero

54 — 18.02.19 — 10:18

bolero

55 — 18.02.19 — 10:30

(29) (48) (49) Опытным путем выяснил, что при значении join_collapse_limit = 2 установки цен в УТ все еще открываются, а ОСВ уже работает. При значении 3 и выше — не работают установки цен в УТ, при значении 1 — не работает ОСВ в БП.

ansh15

56 — 21.02.19 — 14:34

bolero

57 — 21.02.19 — 15:40

ansh15

58 — 21.02.19 — 15:55

(57) Ну, у семи нянек…

bolero

59 — 21.02.19 — 16:08

(57) б, это Сигаев и коммитил. Мне как-то стыдно теперь.

Наблюдающий

60 — 21.02.19 — 18:40

(0) Не знаю, зачем вам так нужна 10 версия постгреса. Я провел тесты и прироста не увидел, а скорее наоборот. Windows 10 (1809), тест гилева: 9.6.5-4.1С – 51.5 балл, 10.5-24.1C – 50 баллов. По тесту фрагстера везде на 200-300 меньше у десятки, только регистр накоплений на 100 больше, тест в 1 поток. УТ 11.4.6.230, попробовал сформировать книгу продаж – десятка на 30% дольше формирует, отчеты по реализованной номенклатуре одинаково. У нас только реализации и номенклатура, нечего особо тестить, но мне и этого хватает. Где там это увеличение производительности – не ясно, по крайней мере под виндой.

(56) с релизом 10.5-24 ОСВ в БП3.0 работает при любом значении join_collapse_limit; установки цен в УТ11 открываются.

<?php // Полная загрузка сервисных книжек, создан 2023-01-05 12:44:55
global $wpdb2;

global $failure;

global $file_hist;
/////  echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;

//подключаемся к базе

$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL

// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке

if (!empty($wpdb2->error))

{

/////   echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';

$failure=TRUE;

wp_die( $wpdb2->error );

}
$m_size_file=0;

$m_mtime_file=0;

$m_comment='';

/////проверка существования файлов выгрузки из 1С

////файл выгрузки сервисных книжек

$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';

if (!file_exists($file_hist))

{

/////   echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';

$m_comment='Файл обмена с сервисными книжками не существует';

$failure=TRUE;

}
/////инициируем таблицу лога

/////если не существует файла то возврат и ничего не делаем

if ($failure){

///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']

/////   echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));

wp_die();

/////    echo '<H2><b>Возврат в начало.</b></H2><br>';

return $failure;

}

/////проверка лога загрузки, что бы не загружать тоже самое

$masiv_data_file=stat($file_hist);   ////передаем в массив свойство файла

$m_size_file=$masiv_data_file[7];    ////получаем размер файла

$m_mtime_file=$masiv_data_file[9];   ////получаем дату модификации файла

////создаем запрос на получение последней удачной загрузки

////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
/////   echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';

/////   echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';

/////   echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';

////препарируем запрос

$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);

$results=$wpdb2->get_results($text_zaprosa);
if ($results)

{   foreach ( $results as $r)

{

////если штамп времени и размер файла совпадают, возврат

if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))

{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));

wp_die();

return $failure;

}

}

}

////если данные новые, пишем в лог запись о начале загрузки

/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';

$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу

$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');

$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);

$results=$wpdb2->query($clear_tbl_zap_repl);

/////   echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';

if (empty($results))

{

/////   echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';

//// если очистка не удалась, возврат

$failure=TRUE;

wp_die();

return $failure;

}
////загружаем данные

$table='vin_history';         // Имя таблицы для импорта

//$file_hist Имя CSV файла, откуда берется информация     // (путь от корня web-сервера)

$delim=';';          // Разделитель полей в CSV файле

$enclosed='"';      // Кавычки для содержимого полей

$escaped='

Related Posts
  
 
 
Групповой перерасчет отпуска
 
Конфигурация "1С: Монтаж окон"
 
Контроль документов
 
Процент по виду расчета списком
 
Карточка складского учета для бухгалтерия 3.0
 
Сохранение чеков ККМ в файл xml
 

7 Comments

 
 
Для начала надо указывать версию Postgres
 А вообще это ошибка субд и исправлена она в PG 10.5-11.1C, либо использовать join_collapse_limit = 1
Reply ↓ 
 
 
(надо указывать версию Postgres) Исправил в статье.
 
Версия PostgresPro PostgreSQL 11.1, compiled by Visual C++ build 1800, 64-bit.
 
Ошибка сейчас проявляется.
 
Обнаружен такой материал: https://infostart.ru/public/554213/
 
join_collapse_limit = 6 # по умолчанию 8 . Внимание!!! Для 1С не стоит устанавливать значение этого параметра равным 1, как в рекомендациях фирмы 1С. Иначе сложные запросы с большим количеством соединений и источников данных станут надолго зависать. Примером для КА являются: документ Инвентаризационная опись основных средств, Отчет по временным разницам и т.п., поскольку данные отчеты используют множество соединений с таблицами регистров сведений.
 
У нас join_collapse_limit = 8, пока ничего не меняли.
 
Reply ↓ 
 
 
В посте 61 обсуждения этой проблемы(см. ссылку в публикации) прямо сказано, что на PostgreSQL версии 10.5-24.1C указанная проблема больше не возникает.
 
Reply ↓ 
 
 
Было не понятно, почему в версии более ранней судя по номеру 10.5-24.1C, указанная проблема больше не возникает, а в нашей более свежей 11.1, она есть. Пришлось копнуть глубже и вот что выяснилось.
 
Ответ любезно предоставленный службой технической поддержки Постгрес Профессиональный
 
Версии. Раз в год выходит очередная мажорная версия Postgres, в которую добавляют новые функциональные возможности. Например, это версия 10 или 11. А дальше в течение года, обычно раз в квартал, выходят минорные версии с исправлениями ошибок. Например, 10.7 или 11.2. Таким образом версия 11.X будет более богата функционалом, но не факт, что будет содержать все исправления, которые есть в 10.Y. Нужно смотреть на дату выпуска минорной версии и список попавших в версию исправлений, который обычно публикуется в Замечаниях к выпуску (Release Notes).
 В случае 10.5-24.1С, мажорная версия 10 минорная 5, а 24 — похоже на номер сборки.
 Удалось найти, что это за ошибка. Она проявляется только в версии 11, исправление будет доступно в нашей сборке 11.2. Баг улучшений в оптимизаторе запросов. Можно либо взять версию 10.6 (где ошибки нету), либо подождать выхода исправленной 11.2.
Решение: принятое в нашей компании: Подождем версию 11.2.
 
Понятно почему, УПП для нас база важная,, но не самая , кроме нее стоят другие базы, которые важнее. А вот их то не хотелось бы переводить на более раннюю версию Постгремсса.
 
Так что способ описанный в статье, пока остается в силе.
 
Reply ↓ 
 
 
Postgre 11.5. Платформа 8.3.15.1489 (сервер х64, клиенты х32), конфига УПП 1.3.120.1.
 Переехали с постгре 9.6 и платформы 8.3.12 — словил ошибку «variable not found in subplan target lists», но не в ОСВ, а в рабочем месте менеджера по продажам при установке галки вывода цены. В дефолтовом конфиге от 1с в постгре стоит join_collapse_limit = 20. Вечером попробую уменьшать (до 8 или 6). Но помню, что join_collapse_limit = 1 приводил к серьезным тормозам на более ранних версиях постгре.
p.s.В bugtrack-е 1с эта ошибка в 11.5 все еще есть, хотя до этого писали, что починили в 10.5, 10.8, 11.1.
 
Reply ↓ 
 
 
(5) Вчера под вечер выпустили обновления 10.10-4.1C и 11.5-7.1C. Может быть в них исправили.
 
Reply ↓ 
 
 
(5) join_collapse_limit = 8 и даже join_collapse_limit = 12 решают проблему
 
Reply ↓ 

 
Leave a Comment 
Ваш адрес email не будет опубликован. Обязательные поля помечены *

I have a legacy Django project (django-1.1.29) and some tests in pytest (pytest-4.3.0), all running inside Docker. The database is PostgreSQL 10 and is a docker-compose service on which the application depends on. The python version is 2.7.18.

Lately the tests started to fail with a strange error:

InternalError: variable not found in subplan target list.

The error occurs only when I count the number of objects of a certain model, e.g. Problem.objects.count(). The instruction is turned into the following query

(0.000) SELECT COUNT(*) AS "__count" FROM "problems_problem"; args=() by Django.

The whole log is here:

self = <integration_tests.project_name.subjects.test_views.test_theme_problem_view_set.TestThemeProblemViewSet object at 0x7f01faccbe50> jclient = <project_name.common.test_utils.json_client.JSONClient object at 0x7f01fadb8ed0> def test_all_is_ok(self, jclient, subject_model, content_manager): url, data = self._main_prepare(jclient, subject_model, content_manager) response = jclient.post_json(url, data[0]) assert response.status_code == 201 > assert Problem.objects.count() == 1 integration_tests/project_name/subjects/test_views/test_theme_problem_view_set.py:86: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/local/lib/python2.7/dist-packages/django/db/models/manager.py:85: in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) /usr/local/lib/python2.7/dist-packages/django/db/models/query.py:364: in count return self.query.get_count(using=self.db) /usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py:499: in get_count number = obj.get_aggregation(using, ['__count'])['__count'] /usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py:480: in get_aggregation result = compiler.execute_sql(SINGLE) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <django.db.models.sql.compiler.SQLCompiler object at 0x7f01faee3a50> result_type = 'single', chunked_fetch = False def execute_sql(self, result_type=MULTI, chunked_fetch=False): """ Run the query against the database and returns the result(s). The return value is a single data item if result_type is SINGLE, or an iterator over the results if the result_type is MULTI. result_type is either MULTI (use fetchmany() to retrieve all rows), SINGLE (only retrieve a single row), or None. In this last case, the cursor is returned if any query is executed, since it's used by subclasses such as InsertQuery). It's possible, however, that no query is needed, as the filters describe an empty set. In that case, None is returned, to avoid any unnecessary database interaction. """ if not result_type: result_type = NO_RESULTS try: sql, params = self.as_sql() if not sql: raise EmptyResultSet except EmptyResultSet: if result_type == MULTI: return iter([]) else: return if chunked_fetch: cursor = self.connection.chunked_cursor() else: cursor = self.connection.cursor() try: cursor.execute(sql, params) except Exception as original_exception: try: # Might fail for server-side cursors (e.g. connection closed) cursor.close() except Exception: # Ignore clean up errors and raise the original error instead. # Python 2 doesn't chain exceptions. Remove this error # silencing when dropping Python 2 compatibility. pass > raise original_exception E InternalError: variable not found in subplan target list /usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py:899: InternalError 

I would really appreciate if anyone could help me fix this issue or at least give some hints where to find the reasons.

Here is what I’ve attempted to do so far but none of these helped:

• Use different versions of PostgreSQL (10, 11, 12, 13)
• Disable the server-side cursor