FB->ODBC->Access

Похоже я чего-то недопонимаю...

На сервере лежит 2 расшареные базы (IB 6.0 и FB 2.0), и стоит сервер FB 2.0

На другой машине настраиваю к ним ODBC.
Первый касяк - конектится только чётными попытками! На нечётные пишет "Access to database "D:\db\my.gdb" is denied by server administrator" Несмотря на то, что сетевой диск называется "P". Причём все чётные конекты проходят, а все нечётные вызывают ошибку. Я в шоке!

Далее прилинковываю таблицы в Ассess. База IB 6.0 работает неспешно, но стабильно.
База FB работает шустро, но самая нужная таблица не грузится. Т.е. при попытке её открыть, медленно-медленно одно за одним все поля отображаются как #error и навязчиво, на каждое поле выскакивает месага (не ошибка) "Sсaling of decimal value resulted in data truncation!"
Я так понял, что это из-за одного поля типа Decimal, содержащего дробные значения. Как бы его мягко и безболезненно програмно заменять на Double, желательно прямо в базе, используя ODBC + АDO/DAO? Поле не критичное, можно просто его не влючать во вьюху, но "не солидно" как-то...

Заранее спасибо! :)

про ib/fb не знаю ничего - эти слова для меня как наречие туземцем из племени муба-юмба.

в общем плане про проблему 2 можно сказать следующее:

возможно она состоит из двух частей:
если все поля отображаются как #error, то это может быть результатом неверного определения локального индекса для линкованной таблицы. попробуйте проиндексировать ее локально (поиск по odbc и index on) по подходящему кандидату, тогда, может быть, данные и появятся. ( а может быть и нет, если одбц драйвер в принципе "не подходит" для акцесса)

касательно сообщения об усечении данных.
Одбц- драйвера могут вести себя в этом месте по разному. «Тупые» - понимают, что это число и сразу пытаются конвертировать его в дабл, пока не споткнутся о фактически полученное значение, которое не укладывается в дабл. В таком случае они именно этот столбец или даже только одно спотыкательное значение отображается как еррор или звездочками. Драйвер может норовить такое значение вернуть как строку. От этого акцессу плохеет – ему сказали, что будут числа и даже начали их подсовывать, а потом вдруг акцесс видит, что вместо чисел строки лезут.

«Умные» драйвера - понимают, что в этом месте может быть засада и сразу возвращают и значения и описания таких полей как текстовые. Они будут отображаться условно-нормально, а со сложением – тут уж depens…
Поищите в документации к драйверу - в его настройках - могут обнаружиться крыжики, как обруливать такие случаи и выдавать ли предупреждающие сообщения.

Если ничего такого не сыщется, то останется только пробовать во вьюхе ( если ее можно трогать, или создать свою, которую и линковать) привести поле к удобоваримому типу с использованием функций, которые могут называться cast, convert, to_типданных. (Не знаю, как такое может называться в ib/fb).
Приведение типов может помочь.

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

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

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

Попробуйте задать вопрос по первой проблеме в форуме по Ib/fb там вы с большей вероятностью получите вменяемый совет по теме четности/нечетности.