Некорректная отработка экспорта через ODBC

Страницы: 1
RSS
Некорректная отработка экспорта через ODBC
 
Добрый день!

В разделе "Использование ODBC для экспорта информации" справки QUIK в описании параметров написано:
  • «Чистить таблицу перед выводом» - если флажок установлен, то перед началом экспорта, при смене сессии, сервера или пользователя старые данные из таблицы будут удалены; если флажок снят, то новые данные будут замещать старые по мере поступления.
Но, в действительности, режим "обновления", в принципе, не работает. Если снять галку, то строки добавляются повторно. Причем не только измененные, а все.

Проверял на разных таблицах. Везде все одинаково. Индексов уникальности в таблицах нет.

Приходится использовать режим полного чистки перед записью. В таком случае размер базы растет очень быстро.

Прошу пояснить, в чем смысл такого режима обновления. Если это все-таки ошибка (причем - ей уже много лет), то сообщите, когда она будет исправлена.

С уважением,
Сергей.
 
"Здравствуйте,
Описанное поведение не является ошибочным.
Сначала происходит вставка, если она неудачна из за нарушения уникальности, то обновление.
Это общепринятый подход, обусловленный тем что предварительно проверять наличие данных в базе более трудозатратно.
Уникальность записи контролируется не QUIK, а самой базой данных через первичные ключи или индексы уникальности.
Соответственно если они не настроены, то очередная запись добавляется, а не обновляется.

таким образом, если галка "Чистить таблицу перед выводом" включена, происходит очистка таблицы, и в ней вставка срабатывает успешно, в результате данные добавляются
если галка "Чистить таблицу перед выводом" отключена, вставка не срабатывает, в результате данные обновляются.
То есть Вам нужно ее включить
 
Добрый день, Сергей!

Судя по описанной Вами логике, отсутствие галки должно работать при наличии уникальных индексов.

Но, если настроить индексы, например, в таблице параметров (уникальный индекс по полю, в которое вносятся значения поля "Инструмент *"), то при импорте через ODBC (когда значения уже вставлены, и необходимо сделать апдейт):

В MS Access выводится сообщение:

[Microsoft][Драйвер ODBC Microsoft Access] Изменения не были успешно внесены из-за повторяющихся значений в индексе, ключевых полях или связях.  Измените данные в поле или полях, содержащих повторяющиеся значения, удалите индекс или переопределите его, чтобы разрешить повторяющиеся значения, и повторите попытку.
SQLSTATE=23000
Код ошибки=-1605

А при экспорте в FireBird:

[ODBC Firebird Driver][Firebird]violation of PRIMARY or UNIQUE KEY constraint "INTEG_2" on table "QUIKPARAMS"
Problematic key value is ("TICKER" = 'Si34000BR5')
SQLSTATE=23000
Код ошибки=-803



С уважением,
Сергей.
 
Сергей,

я не знаю синтаксис ODBC.
А нем нет ничего подобного команде "update or ins ert in to..."?

С уважением,
Сергей.
 
Цитата
Сергей пишет:
Судя по описанной Вами логике, отсутствие галки должно работать при наличии уникальных индексов.
Не вижу противоречий уже сказанному ранее.
Сначала происходит вставка, если она не удачна то обновление.
Все работает.
 
Цитата
Сергей пишет:
Сергей,

я не знаю синтаксис ODBC.
А нем нет ничего подобного команде "update or ins ert in to..."?

С уважением,
Сергей.
Этот вопрос зависит от базы данных в которую идет экспорт.
То есть затрагивается момент потери совместимости.
К тому же текущая реализация ничем не хуже
 
Добрый день, Сергей!

Вы пишите:
Уникальность записи контролируется не QUIK, а самой базой данных через первичные ключи или индексы уникальности.
Соответственно если они не настроены, то очередная запись добавляется, а не обновляется.

А в этом сообщении https://forum.quik.ru/messages/forum11/message4956/topic546/#message4956 я написал, что при наличии уникальных индексов выдается ошибка, и обновление не производится.

Поясните, в каких тогда случаях работает обновление, а не добавление, и что настроил некорректно.
Еще раз повторюсь, что удалять все данные, а потом добавлять новые - на мой взгляд, нерационально, да и БД быстрее растет.


С уважением,
Сергей.
 
Цитата
Сергей пишет:
и обновление не производится.
Делаем в базе таблицу
Код
CRE ATE   TABLE [dbo].[Table_1](
   [instrument] [varchar](255) NOT NULL,
   [last] [decimal](19, 6) NULL,
 CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED 
(
   [instrument] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO


Далее в терминале строим ТТП по какому-нибудь инструменту и добавляем одно единственное поле "Цена последней сделки"

настраиваем экспорт, запускаем, данные едут все хорошо.
Останавливаем экспорт а потом снова запускаем.
Появляется сообщение о нарушении первичного ключа (так и должно быть)
Смотрим в базу, данные продолжают обновляться. Ровно как и должно быть.
То есть у нас описанная проблема не воспроизводится.

Опишите аналогично как Вы воспроизводите?
Страницы: 1
Читают тему (гостей: 2)
Наверх