Имеется ASA 9.0.2 билд на память не помню, кажется 2542, но это не существенно. Эффект поторяется на всех билдах и был замечен еще на 7 и 8 версиях.

В скрипте исполняемом запуском по расписанию dbisqlc требуется импортировать данные из файла dbf. Импорт нужно сделать во временную таблицу, которая объявляется в самом скрипте:

DECLARE LOCAL TEMPORARY TABLE t_data(
o_dat date,
sum numeric(12,2),
comm varchar(512)
) not transactional;

input into t_data from aaa.dbf format DBASEIII by order;

Порядок и число полей, типы данных соответствуют.

Теперь собственно проблема:
- если input делает юзер, не имеющий статуса creator, то возникает ошибка - "нет прав на создание таблицы".

- если input делает DBA, то получаем собщение - "таблица уже существует".

Согласно BOL, при исполнении INPUT для форматов типа dBASE, если целевой таблицы нет, она создается, если есть - данные льются в нее.

Дать юзеру-импортеру права на создание таблиц нельзя по условиям безопасности - ему зарезано все, кроме коннекта и вызова нескольких SP, которые и делают отстальную работу.

Если импорт делается из форматов ASCII, FIXED и т.п., то проблем не возникает.

Может быть кто уже боролся с такими проблемами.

White OwlГлупый наверное вопрос, но все же: А ты все эти команды в блок begin/end положить не пробовал?


Пробовал. Не помогло :( Но попробую еще разок. Проблема именно с local temporary table

White Owl
А в конце блока можно делать принудительное удаление временной таблицы. И вообще по описанию задачи я не вижу, почему бы не создать один раз глобальную временную таблицу. Намного проще будет работать.


Есть несколько ограничений :
1.Процедура импорта происходит регулярно и часто, а я не уверен, что постоянное создание/дропанье base таблиц благосклонно воспримется сервером.

2.Структура исходных данных может меняться, и пересоздавать/править глобальную временную таблицу сложно организационно. А так, я присылаю поправленный скрипт и все работает дальше. И мне ехать никуда не нужно :).

3.Иногда требуется повторная загрузка старых данных - для этого случая есть архив скриптов импорта.

4.Импорт выполняется запуском батника по расписанию или ручками, значит нужно явно прописать пароль. Поэтому сделан спец пользователь, который имеет право только на исполнение нескольких SP, которые подготовленные данные толкают дальше в систему.

White Owl
У меня впрочем еще с ASA6 вполне работают скрипты написаные вот так:


Не годится, т.к. по условиям игры импорт делается от имени лишенца - create table #t( ..... ) ему, увы, запрещен.

White Owl
Ну вообще-то, "declare local temporary table aaa" и "create table #aaa" абсолютно идентичны :) И в том и в другом случае создается таблица принадлежащая сессии и она автоматически убивается по завершению сессии.
А насчет частоты создания/удаления временных таблиц - точно говорю, никаких проблем нету :)

Это я протормозил - # не заметил :-)
Но если операторы
и
эквивалентны, почему input не видит таблицу в первом случае ?

На лицо глюк :(. Завтра попробую create table #aaa

White Owl
Это единственный серьезный аргумент против глобальных временных таблиц. Но если меняются исходные таблицы.... может имеет смысл наваять внешний конвертор данных? Который бы автоматически подстраивался под новый набор колонок?


Вот я и ваяю внешний конвертор данных. Правда не автоматический.
С автоматическим возникает вопрос согласования спецификаций. Без человека все равно не обойтись :( А dbisql и SQL-скрипты обладают достаточными возможностями для конвертации.

У меня там пользователь - оператор, который может нажать кнопочку и сделать внеплановую закачку данных, посмотреть на статистику и решить - принимать их или нет. И учить его программировать или делать настройки конвертора самому дело неблагодарное. :( Повлиять на поставщиков исходных данных тоже не могу. Они говорят - "А нам так удобно и переделывать не будем!" :-((

На днях столкнулся с аналогичной проблемой при импорта данных из системы "Клиент-банк". Эти умники по умолчанию экспортируют как раз в dbf.

dbisqlc напрочь отказывался делать input - лезли ошибки преобразования. Чем они делают файл я так и не понял, Clipper файл принимал и данные показывал.
Вскрытие показало, что авторы в поле типа numeric(6) умудрились записать время обработки операции в формате "16:43". Clipper спокойно принимал 16, а dbisql - нет :(

После 4 дней общеня с банком оказалось, что система, к счастью, умеет делать экспорт и в текстовый файл. Правда fixed формат, но уже не тот глюкавый DBF :)

Наконец добрался до компьютера с ASA и занялся экспериментами.
Для начала попробовал сделать как рекомендовано White Owl :
White Owl
У меня впрочем еще с ASA6 вполне работают скрипты написаные вот так:
Ни разу не встречал проблем.

Проблема встретилась. Не помню уже, как там было в ASA6, но ASA 9.0.2.3044
ругается "SQLCODE = -131, синтаксическая ошибка около input..." :(

Как только убираю begin и end начинает пытаться работать.

Что я делаю неправильно ?

Дальнейшие эксперименты показали, что нужная мне конструкция работает только тогда , когда исполняется через dbisql G . А меня интересует исполнять импорт через dbisql C - машинка там дохловатая, и вообще - нет никакого интереса деплоить туда JRE и прочие радости. :(

Кроме того, замечены за dbisqlG плавающие глюки, когда при загрузке в БД множества объектов через последовательность операторов READ, вдруг он сходит с ума и начинает русские комментарии и констатны превращать в "крокозябры". :(

Попробую написать в поддержку, авось кейс откроют :(

White Owl dp_tndПроблема встретилась. Не помню уже, как там было в ASA6, но ASA 9.0.2.3044
ругается "SQLCODE = -131, синтаксическая ошибка около input..." :(
Как только убираю begin и end начинает пытаться работать.
Что я делаю неправильно ?
Все правильно. Просто dbisqlc отправляет все что находится внутри begin/end блока на сервер, не разбираясь. А input это команда dbisql*, а не сервера. dbisqlg в этом плане умнее...

А вот и не умнее. :-) Та же самая ошибка, точнее наверное особенность работы. Но input в локальную временную таблицу он делает нормально. Кинул письмо в Московский саппорт, Ждемс...

Кстати, в недрах BOL, в разделе о деплоировании административных утилит зарыта фраза, что "... мы не гарантируем в dbisqlc всех фич и полной совместимости с dbisqlg" :-(( Но не настолько же.

Я конечно их понимаю, но команда input делалась в те далекие времена, когда о java-версиях утилит мы и не подозревали. И у меня крутится в голове смутное воспоминание, что на версии 5.5 оно таки работало, а с переходом на 6 надобность в таком варианте отпала. А теперь вот снова появилась :))