Попробуйте провести модернизацию БД, при этом автоматом делается реиндексация, может поможет. Если не поможет, то руками, например используя SSMS, но муторно не меньше, чем в АБД переделать.
По поводу переноса из КДЛа приборов, так это не сложно, буквально ссылочный индекс поменять. Но кто гарантирует, что других "завихрений" в БД нет?

Завихрений полно. но я готов менять ссылочные индексы. Где менять, что нужно знать? :)
У меня кроме этой БД в общем не на что облокотиться - проекты сказочные. Где правды больше, в пульте или АБД - ещё вопрос.
Модернизация БД заканчивается "Успехом". Правда, в результате девственная база данных. 

Евгений, в настоящий момент Ориона нет под рукой, смогу подсказать только завтра (время МСК).
В двух словах так: в БД есть таблица приборов, в ней перечисляются все приборы (пульты в том числе), пульты и приборы в протоколе Орион имеют в ссылочном поле значение 0, а те приборы, которые подключены к пульту (протокол ОрионПро), имеют ссылку на индекс этого пульта.

https://drive.google.com/file/d/1TwuufONT-k2JhGZpBmlKwgX7KOxn6MZZ/view?usp=sharing
Поле GType ещё на что-то похоже, но логику не вижу всё равно.

Ссылку посмотреть не могу по причине отсутствия аккаунта Google :-((
По переносу приборов из КДЛа: таблица RSLines, для проблеммных приборов в поле PKUID указать ID записи в той же таблице для нужного пульта.

Ссылку поправил. Ох уж этот гугл...
Попробую на объекте, спасибо.

По поводу данных по ссылке - в поле GType указывается тип шлейфа на основе данных таблицы dTypesElement. В Вашем случае скорее всего 1 или 2 для ШС, а для считки оставьте 0.

Докладываю из домашней лаборатории.
PKUID у пульта 0, у нормальных приборов 1, а у кривых 7. Исправил все 7 на 1, а поскольку при этом воникает ошибка, назначаю и запоминаю каждому из кривых приборов новые адреса в строку GLineNo. При этом у кривого БКИ в отличие от правильного был DeviceType 44 и пока я непоменял на верный 10, он в АБД не появлялся. Всё, с лишними приборами вопрос снят! Спасибо!
Остались Реле\ШС.
При преобразовании в БД ШС в реле возникает конфликт - данный GIndex уже занят в какой-то другой ещё таблице, видимо. Я могу прибавиь к индексу, например 10000 и тогда это реле исчезает и вроде бы проблемы не видно, но при попытке сменить тип уже в АБД возникает конфликт. Надо менять тип одновременно в некой связанной таблице кроме DevItems. 
Где-то была красивейшая таблица связей полей и таблиц.
PS: тип 1 - охранный шлейф, 2 - пожарный, 3 - вроде реле, но с ним связано поле ItemType со значением 9
PPS: в инспекторе справа кроме типа шлейфа есть пользвательский номер. Я просто удалил из той же таблицы для пробы пару элементов с более высоким номером (видимо более "молодых"). После этого со шлейфом можно работать и выставлять тип как обычно (не забудьте предварительно убрать со входов типа "Реле" связанные разделы). Есть неуверенность, можно ли так делать, хоть база и не легла, но выглядит оптимистично!

Здравствуйте Королёв Евгений Владимирович!
Вот скрипт, делал для себя, может и вам службу верную сослужит-- === таблица шлефов всех КДЛ ==
SELECT
RSLines.GLineNo AS "Адрес"
, dTypes.Name
, RSLines.Name AS "Название прибора"
, DevItems.Address-DevItems.Address/256*256 AS "Шлейф" -- номер ШС реле считывателя
, DevItems.Name AS "Название шлейфа" -- название
, DevItems.Gtype as "Тип шлейфа"-- тип элемента
, DevItems.Config as "Накапливать статистику"-- накапливать статистику 1 - да 0 -нет 2 - централизованное управление
, pObjects.GIndex as "Раздел"
FROM DevItems
JOIN RSLines ON (DevItems.DeviceID = RSLines.ID)
JOIN dTypes ON (RSLines.DeviceType = dTypes.ID)
JOIN pObjCont ON (DevItems.ID = pObjCont.ShleifID)
JOIN pObjects ON (pObjCont.ObjectID = pObjects.ID)
WHERE
--DevItems.Address BETWEEN (256*XXX+YYY) AND (256*XXX+YYY) -- где XXX - адрес прибора YYY - адрес шлейфа
DevItems.Address BETWEEN (256*1+1) AND (256*1+14)
OR DevItems.Address BETWEEN (256*1+16) AND (256*1+25)
ORDER BY "Адрес", "Шлейф" -- == журнал за промежуток ==
SELECT
pLogData.TimeVal,
pLogData.DeviceTime,
pLogData.Par3 AS "адрес", -- адрес прибора
pLogData.Par4 AS "шлейф",
pLogData.Event, -- ID события
Events.Contents AS "Событие",
pLogData.Remark AS "Описание",
pLogData.RazdIndex AS "Раздел",-- номер раздела
pObjects.Name AS "Название Раздела"
FROM
pLogData, Events, pObjects
WHERE
pLogData.Event=Events.Event
AND pObjects.GIndex=pLogData.RazdIndex
AND pLogData.TimeVal BETWEEN "17.09.2019 00:00:00" AND "17.09.2019 23:59:59"
ORDER BY pLogData.TimeVal DESC -- сортировка в обратном порядке--- обновление программы управления и типа шлефа СП 2
UPDATE
DevItems
SET
Gtype = 11 -- адресный релейный
, Config = 0
, State = 0
, Command = 39 -- Включить при пуске
, Flags = 0
, ItemType = 9 -- адресный релейный модуль
, TimeOutConfig = 0
, TimeOutControl = 65536
WHERE
-- РЕЛЕ СП2 --
Address = (256*1+9)
OR Address = (256*1+14)
GO

О, полезные штуки, спасибо. Можно даже сообразить, как с БД работать благодаря комментариям!

В 2014 SQL Management Studio, к сожалению, не сработали запросы. Первый ничего не выдал. Второй ругается на дату\время. Не разобрался.

Формат даты зависит от настроек вашей операционной системы, а во втором запросе проверьте какие адреса КДЛ вы указали. Внимательно изучите комментарии в скриптах

Ааа, ну комментарии же :) Да, пожалуй тупо копировать не вдумываясь - плохая практика.