This is topic Импорт данных через ODBC in forum Работа в MS Windows (ODBC/DDE/OPC/NET) / Working under MS Windows at Форум TRACE MODE: техническая поддержка.
Решение проблемы получения данных из базы 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 :
А вообще - рекомендую Вам войти в Администратор источников по 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 источников в разделе Трассировка задаете путь для лог-файла и включаете его. Затем повторяете процедуру передачи данных в СУБД из ТМ в МРВ, после чего смотрите последние сообщения в данном лог-файле. Он текстовый, поэтому разобраться будет довольно легко.
