Форум QUIK [тема: Некорректная отработка экспорта через ODBC]

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

Wed, 27 May 2015 23:56:43 +0300

Некорректная отработка экспорта через ODBC в форуме Экспорт в системы тех.анализа.

====quote====
Сергей пишет:
и обновление не производится.

=============
Делаем в базе таблицу
====code====

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

=============

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

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

Опишите аналогично как Вы воспроизводите?
27.05.2015 23:56:43, Sergey Gorokhov.

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

Wed, 27 May 2015 23:29:36 +0300

Некорректная отработка экспорта через ODBC в форуме Экспорт в системы тех.анализа.
Добрый день, Сергей!

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

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

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

С уважением,
Сергей.
27.05.2015 23:29:36, Сергей.

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

Wed, 27 May 2015 17:21:56 +0300

Некорректная отработка экспорта через ODBC в форуме Экспорт в системы тех.анализа.

====quote====
Сергей пишет:
Сергей,

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

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

=============
Этот вопрос зависит от базы данных в которую идет экспорт.
То есть затрагивается момент потери совместимости.
К тому же текущая реализация ничем не хуже
27.05.2015 17:21:56, Sergey Gorokhov.

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

Wed, 27 May 2015 16:51:09 +0300

Некорректная отработка экспорта через ODBC в форуме Экспорт в системы тех.анализа.

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

=============
Не вижу противоречий уже сказанному ранее.
Сначала происходит вставка, если она не удачна то обновление.
Все работает.
27.05.2015 16:51:09, Sergey Gorokhov.

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

Mon, 25 May 2015 23:51:58 +0300

Некорректная отработка экспорта через ODBC в форуме Экспорт в системы тех.анализа.
Сергей,

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

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

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

Mon, 25 May 2015 23:47:35 +0300

Некорректная отработка экспорта через ODBC в форуме Экспорт в системы тех.анализа.
Добрый день, Сергей!

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

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

С уважением,
Сергей.
25.05.2015 23:47:35, Сергей.

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

Mon, 25 May 2015 20:55:11 +0300

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

таким образом, если галка "Чистить таблицу перед выводом" включена, происходит очистка таблицы, и в ней вставка срабатывает успешно, в результате данные добавляются
если галка "Чистить таблицу перед выводом" отключена, вставка не срабатывает, в результате данные обновляются.
То есть Вам нужно ее включить
25.05.2015 20:55:11, Sergey Gorokhov.

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

Sun, 24 May 2015 23:28:16 +0300

Некорректная отработка экспорта через ODBC в форуме Экспорт в системы тех.анализа.
Добрый день!

В разделе "Использование ODBC для экспорта информации" справки QUIK в описании параметров написано:

«Чистить таблицу перед выводом» - если флажок установлен, то перед началом экспорта, при смене сессии, сервера или пользователя старые данные из таблицы будут удалены; если флажок снят, то новые данные будут замещать старые по мере поступления.

Но, в действительности, режим "обновления", в принципе, не работает. Если снять галку, то строки добавляются повторно. Причем не только измененные, а все.

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

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

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

С уважением,
Сергей.
24.05.2015 23:28:16, Сергей.