This is topic Импорт данных через ODBC in forum Работа в MS Windows (ODBC/DDE/OPC/NET) / Working under MS Windows at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/13/t/000080.html

Posted by Игорь (Участник № / Member № 1027) on :
 
Решение проблемы получения данных из базы Acces 2000 по ODBC близко к положительному исходу. По “метке” получаем данные из необходимой записи.
А вот получить последние данные, поступившие в таблицу расходов не можем ввиду не очень хорошего знания SQL. Как ни прописуем в конфигурационном файле odbc.cfg условие выборки, серверу непонятен формат ДАТЫ. Итак, наша цель получить последние данные из архивной таблицы расходов Access.
Структура файла конфигурации odbc.cfg такова:
DSN=DENDB
SQL1=SELECT*FROM
HEADER1=DENTAB
FOOTER1=WHERE DATATIME=
Где DATATIME-поле формата типа 29.07.2004 10:31:00
Пожалуйста помогите правильно сформулировать условие SQL-запроса.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Регистрация выполнена правильно, должно работать.
Сервер - это приложение, которое предоставляет данные по запросу или передает данные другим по собственной инициативе. Клиент - это то приложение, которое только запрашивает данные.

Просьба - не создавать дополнительных топиков по одной и той же теме, а продолжать обсуждение одной темя в рамках одного топика.
 
Posted by Игорь (Участник № / Member № 1027) on :
 
Решение проблемы получения данных из базы Acces 2000 по ODBC близко к положительному исходу. По “метке” получаем данные из необходимой записи.
А вот получить последние данные, поступившие в таблицу расходов не можем ввиду не очень хорошего знания SQL. Как ни прописуем в конфигурационном файле odbc.cfg условие выборки, серверу непонятен формат ДАТЫ. Итак, наша цель получить последние данные из архивной таблицы расходов Access.
Структура файла конфигурации odbc.cfg такова:
DSN=DENDB
SQL1=SELECT*FROM
HEADER1=DENTAB
FOOTER1=WHERE DATATIME=
Где DATATIME-поле формата типа 29.07.2004 10:31:00
Пожалуйста помогите правильно сформулировать условие SQL-запроса.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Попробуйте так:
FOOTER1=WHERE DATATIME=#29/07/2004 10:31:00#

А вообще - рекомендую Вам войти в Администратор источников по ODBC в системе и во вкладке "Трассировка" включить трассировку транзакций по ODBC в файл. Тогда в этом лог-файле будет легче понять - что же не нравится драйверу MS Access при выполнении Вашего SQL-запроса.
 
Posted by Игорь (Участник № / Member № 1027) on :
 
Все-таки удалось "уговорить" "Взлет" на передачу данных из собственного архива в каналы ТМ. В соответствущую таблицу было вставлено уникальное ключевое поле-счетчик, т.е последней полученной записи этого поля соответствует наибольшее значение этого поля.Таким образом мы избежали использования русского слова в условии SQL-запроса в конфигурационном файле:
DSN=RASHODS
SQL1=SELECT * FROM
HEADER1= ROPALL
FOOTER1=WHERE Дата...
Теперь он понятен ТМ ,в SQL-запросах которого должны присутствовать только английские названия.
Сейчас он выглядит так:
DSN=RASHODS
SQL1=SELECT * FROM
HEADER1= ROPALL
FOOTER1=WHERE NUMERDEN=...
Где NUMERDEN и есть пресловутое ключевое поле-счетчик.
Пробовали получить значения вариантом SQL Delphi:
DSN=RASHODS
SQL1=SELECT * FROM
HEADER1= ROPALL
FOOTER1=WHERE(NUMERDEN=(SELECT MAX (NUMERDEN) from ROPALL),
Были попытки:
WHERE NUMERDEN=MAX(NUMERDEN)
не понимает их ТМ и все тут.
Подскажите пожалуйста какие еще могут быть варианты получения данных из записи с максимальным значением ключевого поля NUMDEN.
Заранее благодарим за помощь в нашем нелегком деле!Денис.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
"не понимает их ТМ и все тут." - Сомневаюсь, дело в том, что Вы работаете в режиме "ТМ как ODBC-клиент", а в этом режиме ТМ не обрабатывает SQL-запросы, которые Вы пишите в файле odbc.cfg, он просто складывает три фрагмента в текстовую строку и передает ODBC-источнику, указанному в DSN, а уж драйвер этого источника разбирает этот запрос. Поэтому, синтаксис и правила задания SQL-запроса определяет не ТМ, а тот ODBC-драйвер, через который Вы работаете.
 
Posted by Игорь (Участник № / Member № 1027) on :
 
Возникла проблема с передачей данных из ТМ в БД Access по ОДБС. Подскажите, что не так.
Есть зарегистрированная база данных Kolonka, в ней две таблицы: KOLONKAIN и KOLONKAOUT.
В директории проекта создан конфигурационный файл:
DSN=Kolonka
SQL1=SELECT * FROM KOLONKAIN
SQL2=UPDATE KOLONKAOUT
Созданы два канала для управления обменом.
Часть ответственную за считывание данных описывать не буду, т.к. в ТМ данные из базы поступают отлично.
Заметил, что для того, чтобы оба канала функционировали нормально, значение(1) необходимо присваивать им не одновременно. Поэтому сигнал к обмену они получают попеременно (асинхронно).
Создал канал SQL_UPR_INS тип OUTPUT, вид F, ПУСТОЙ, SQL_Выполнить ( I1=1, I2=1, С2=0, C3=0).
В таблице KOLONKAOUT есть поле SQL_IND и еще восемь полей Obr_Schet1 …. Obr_Schet8.
В базе каналов есть каналы с аналогичным названием типа INPUT, вида F, ПУСТОЙ, SQL_для вставки ( I1=1, I2=1, С2=0, C3=0).
Запись в таблице не обновляется……..Почему?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Что в лог-файле Профайлер пишет после попытки выполнить запрос?
 
Posted by Игорь (Участник № / Member № 1027) on :
 
Сейчас не могу посмотреть...Ключ занят! Но ошибка SQL (6) о чем-нибудь говорит?
 
Posted by Игорь (Участник № / Member № 1027) on :
 
Выскакивает только в момент попытки записи в базу.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
А зачем ключ? Лог-файл всегда есть в директории проекта, после запуска его под Профайлером, можете привести его текст здесь?
 
Posted by Игорь (Участник № / Member № 1027) on :
 
Я его стер, а чтобы запустить профайлер нужен ключ инструменталки...
 
Posted by Игорь (Участник № / Member № 1027) on :
 
Вот содержание лога

SQL:operator is: INSERT INTO KOLONKAOUT (AVTOMAT,Obr_Schet1,Obr_Schet2,Obr_Schet3,Obr_Schet4,Obr_Schet5,Obr_Schet6,Obr_Schet7,Obr_Schet8,SQL_IND) VALUES(0,0,0,20,0,0,0,0,0,1)
SQL:error in ExecDirect:S0022
#01S1C2
= 8
= 0
RS:COM1 check error (FC-5a34-2002)
SQL:operator is: SELECT * FROM KOLONKAIN
SQL:columns is 1 SQLFLAG
SQL:columns is 2 SQLNUMBER
SQL:columns is 3 SQLZADANIE
SQL:execute: SELECT * FROM KOLONKAIN
ODBC Read
#01S3C0
= 8
= 0
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Запрос на вставку в СУБД вернул ошибку от драйвера: "SQL:error in ExecDirect:S0022"
Самый лучший способ узнать причину, почему драйверу ODBC MS Access не понравился запрос - это включить в ОС лог-файл на ODBC-транзакции.

Через Панель управления - Администрирование - Менеджер ODBC источников в разделе Трассировка задаете путь для лог-файла и включаете его. Затем повторяете процедуру передачи данных в СУБД из ТМ в МРВ, после чего смотрите последние сообщения в данном лог-файле. Он текстовый, поэтому разобраться будет довольно легко.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2