iBase.ru Forum

Доброго времени суток.
Firebird 2.5b, использую временные таблицы. Если в пути указатать русские буквы (в данном примере "тест"), то в DDL созданной таблицы вместо русских букв будут кракозябры. Соответственно, работать с такой таблицей невозможно.
Как можно обойти?

А тебе принципиально использовать путь с русскими буквами?
И вообще ты создаешь не временную, а внешнюю таблицу

Ну да, внешнюю, несколько оговорился, ибо использую их как временные.
Что касается русских букв - принципиально. Пользователь может поставить софт в любую папку, в какую пожелает, в том числе с русскими буквами в имени пути. Думал на счет временных системных папок, но и там могут быть русские буквы.

Незнаю надо поопробовать...
щас просто некогда..
шампанское рекой...

aes писал(а):Ну да, внешнюю, несколько оговорился, ибо использую их как временные.

А использовать временные таблицы как временные таблицы не позволяет что?

Коллеги, спасибо за ответы, но необходим именно механизм внешних таблиц - он используется для связи двух разных приложений, т.е. одно "кладет данные", а второе "забирает", таким образом временные таблицы не подходят (менять механизм также не хочется, ввиду того, что он достаточно жизнеспособный).
Необходимости использовать русских путей не критично, но некрасиво - пользователь сам выбирает папку, куда устанавливает приложение, может выбрать и с русским именем. Просто хотелось бы уточнить - есть ли проблема в этом у сервера? (или может это ограничение/глюк).

А второе приложение тоже на IB\FB и использует этот файл как внешнюю таблицу?
Если нет то нельзя ли рассмотреть вариант когда первое приложение выгружает данные не во внешнюю таблицу, а например в обычный dbf?

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

есть ли проблема в этом у сервера? (или может это ограничение/глюк).

Проблема разрешима правильной кодировкой, но вызывает недоумение именно желание работать с внешними таблицами. Раз временные не подходят, то в чём проблема с обычными?

Проблема разрешима правильной кодировкой

На этом месте поподробней плиз, с примером.

в чём проблема с обычными?

Проблема в том, что данные в этих таблицах будут часто обновляться (раз в 5 сек. примерно), "смотреть" в эти таблицы могут (и скорей всего будут) несколько пользователей одновременно, соответственно возникают трудности с уборкой мусора. Поэтому и было решено использовать внешние таблицы.

я скажу только, что на мой взгляд, это достаточно оригинальное использование сервера.

А заказчики вообще очень большие выдумщики

aes писал(а):

Проблема разрешима правильной кодировкой

На этом месте поподробней плиз, с примером.

А, нет, не разрешима, я забыл про баг, который сам же в трекер и загнал...

aes писал(а):Проблема в том, что данные в этих таблицах будут часто обновляться (раз в 5 сек. примерно), "смотреть" в эти таблицы могут (и скорей всего будут) несколько пользователей одновременно, соответственно возникают трудности с уборкой мусора. Поэтому и было решено использовать внешние таблицы.

Не понял. Чуть выше ты говорил, что одно приложение будет в таблицу писать, а другое читать. Путаешься в показаниях?

Кстати, внешние таблицы невозможно обновить, так что в данном случае про них можно забыть.

PS: Если бы мне потребовалось такое извращение с пятисекундным обновлением, я бы, наверное, использовал контекстные переменные.

Чуть выше ты говорил, что одно приложение будет в таблицу писать, а другое читать. Путаешься в показаниях?

Нет, не путаюсь, просто недоуточнил Первое приложение каждые 5 сек. дергает второе приложение, которое тут же что-то там опрашивает, удаляет файл внешней таблицы и потом кладет туда полученные данные, после чего первое приложение их рефрешит.

А, нет, не разрешима, я забыл про баг, который сам же в трекер и загнал...

Ок, с этим ясно.

aes писал(а):Первое приложение каждые 5 сек. дергает второе приложение, которое тут же что-то там опрашивает, удаляет файл внешней таблицы и потом кладет туда полученные данные

Точнее сказать - пытается удалить, напарывается на отказ в доступе (поскольку файл занят движком) и умирает в мучениях.

Как я уже сказал самое лучшее в такой ситуации - хранить заголовки опрашиваемых параметров в нормальной таблице, а их значения - в контекстных переменных.

Хотя нет, вру. Самым лучшим было бы вообще не трогать базу, а получать данные прямо из второго приложения любым IPC методом (например, через сокеты).

когда я делал такие приложения, я не заморачивался внешними таблицами. у нас одно приложение генерило файлы сначала в текстовом формате, потом в xml (по мере развития), а второе эти файлы парсило и заливало в базу. После заливки файлы разбирались на обработанные и ошибочные, и перемещались в соответствующие папки.
Как я понимаю, здесь происходит примерно то же самое, иначе зачем периодически создавать и удалять файл external table.

Точнее сказать - пытается удалить и умирает в мучениях

Да неее... живет себе. Плохо правда, но живет. Хотя есть некоторые опасения, что при слишком активном использовании проживет недолго.

Самым лучшим было бы получать данные прямо из второго приложения любым IPC методом

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

Как я понимаю, здесь происходит примерно то же самое, иначе зачем периодически создавать и удалять файл external table.

Да, все верно. Только объемы информации небольшие, и опрос/обновление достаточно частое.