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

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Экспорт в системы тех.анализа
Страницы: 1
RSS
Некорректная отработка экспорта через ODBC
 
#1
24.05.2015 23:28:16
Добрый день!

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

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

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

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

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

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

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

Но, если настроить индексы, например, в таблице параметров (уникальный индекс по полю, в которое вносятся значения поля "Инструмент *"), то при импорте через 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



С уважением,
Сергей.
 
 
#4
25.05.2015 23:51:58
Сергей,

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

С уважением,
Сергей.
 
 
#5
27.05.2015 16:51:09
Цитата
Сергей пишет:
Судя по описанной Вами логике, отсутствие галки должно работать при наличии уникальных индексов.
Не вижу противоречий уже сказанному ранее.
Сначала происходит вставка, если она не удачна то обновление.
Все работает.
 
 
#6
27.05.2015 17:21:56
Цитата
Сергей пишет:
Сергей,

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

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

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

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

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


С уважением,
Сергей.
 
 
#8
27.05.2015 23:56:43
Цитата
Сергей пишет:
и обновление не производится.
Делаем в базе таблицу
Код
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
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2024,
ARQA Technologies
Наверх