Тема неоднократно обсуждалась. Но в основном вопросы были связаны с подключением к базам Firebird по сети и т.п.

Меня же интересует только одно. У меня есть файл с расширением *.gdb. Мне нужно посмотреть, что в нем есть, и считать некоторые данные.

Про сайт www.ibprovider.com я знаю. Вроде бы там можно скачать Firebird. Правда, несколько смутило упоминание о trial-версиях на 30 дней. Вроде бы Firebird бесплатный?

Также я скачала драйвер Firebird_ODBC_2.0.0-Win32.exe , который советовали скачать на форуме для связи с Firebird или для открытия файлов *.gdb

Так с чего вообще начинать? Надо ли для начала скачать сам Firebird? Или это не обязательно? Если использовать Firebird_ODBC_2.0.0-Win32.exe, то в какой среде еuо открывать - в VFP? Или еще как-то? Насчет паролей я не знаю. Вроде бы файл *.gdb беспарольный. Ну, а если есть пароль, то советовали просто открыть файл в Firebird под админом с админовским паролем по умолчанию.

Опыта работы с Firebird не имею.

В общем, хотелось бы получить представление о том, в каком направлении двигаться, что нужно скачать/установить (и откуда ), чтобы можно было вытащить из файла *.gdb данные. Что из себя представляют данные, мне в принципе известно в общих чертах. Так что понять, что это "те или не те" данные, я смогу.

Использовал FireBird запущенный как службу, возможно прокатит без установки самого сервера.

1. Ставишь драйвер на клиента, как любой аналогичный

2. Прописываешь строку подключения, если мне не изменяет склероз, в секции DBNAME прописываешь путь к файлу fdb (для серверной реализации есть особенность, путь к fdb надо прописывать ЛОКАЛЬНЫЙ, типа C:\Programm files, а не \\IP\Share или RemoteDisk\Folger)

3. Системный логин/пароль - SYSDBA/mastrkey

Я понял, что надо что-то подключать, а вот что - не понял...

Ну просто опыта нет никакого в этих вопросах. Как иногда изредка говорит IK - полный нуб.

А можно поподробнее?

1.Что значит "поставить драйвер на клиента"? То есть я запускаю драйвер из командной строки на локальном компьютере? Или из какой среды пользоваться этим драйвером? Из VFP? Или откуда?

2. Где находится секция DBNAME, в которой надо прописать строку подключения? Видимо, в каком-то файле конфигурации?

3. Какой командой просматривать файл?

Ну, если я эти первые этапы преодолею, то потом, возможно, задам более осмысленные вопросы.

"Взять данные" это слишком абстрактная постановка задачи.

Например можно скачать embedded версию FB с этой страницы - это просто архив с несколькими нужными dll-ками, вынуть эти dll и положить рядом с gdb файлом (внутри архива есть документация - какие именно файлы нужны - 4-х dll хватит для большинства случаев). Потом взять утилиту IBExpert (которую опять таки не требуется инсталлировать - файл по ссылке простой самораспаковывающийся архив) и распаковать в ту же папку - запустить, "зарегистрировать БД" (в режиме local, конечно же) и спокойно открыть и смотреть - в т.ч. экспортировать данные в разные форматы.
gdb, кстати, формально есть файл БД Interbase 6.0 а не Firebird - но это на самом деле не имеет практически никакого значения

Спасибо!

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

Но тут уже другие проблемы. Как я понимаю, сами данные находятся в Databases->Tables.

Я выбираю нужную таблицу, потом выбираю Table-export date, и загоняю таблицу, например, в *.dbf

А вообще, как понимаю, вероятнее всего используется кодовая таблица 1251 в Firebird? Или может быть и любая другая?
Это я насчет того, какую выбирать кодовую страницу при открытии *.dbf в Foxe?

И еще в этом IBExpert пишется насчет того, что данные можно смотреть как Unicode.

Все же думаю, что вряд ли там кто-то особо изголялся, и кодовая страница 1251.



Исправлено 1 раз(а). Последнее : Simple777, 26.07.13 08:55

Simple777
Я выбираю нужную таблицу, потом выбираю Table-export date, и загоняю таблицу, например, в *.dbf

Понятия не имею какую именно разновидность dbf-а генерит IBExpert и в какой CP Главное убедится вначале что выбрана верная кодировка при открытии gdb - т.е. что данные "читаемы" - иначе дальнейшее бессмысленно.

Simple777
А вообще, как понимаю, вероятнее всего используется кодовая таблица 1251 в Firebird? Или может быть и любая другая?

Может быть любая - но кодировка в gdb это одно, а кодировка в файле создаваемом IBExpert это совсем другое... Он вполне может и 866-е dbf-ы делать - под "старьё" ориентироваться Впрочем, по данным всё и так должно быть видно.

Столкнулся с такой вот заморочкой.

Запустил IBExpert.exe (18 246 144 - размер, дата файла - 29.06.13), зарегистрировал database, сделал connect, и стал конвертировать таблицы в dbf-формат.

Все шло хорошо, но вдруг на одной из таблиц появилось сообщение: Out of memory. Это происходит где-то в районе 52 тыс записей. Я попытался просто просмотреть таблицу (без конвертации), но опять таки в районе 52 тыс выдается сообщение об ошибке Out of memory. В тоже время общее число записей подсчитать можно, и IBExpert показывает, что всего записей в районе 54 тыс.

Я пробовал освобождать место на диске C:, и на рабочем диске F: (откуда запускался IBExpert), но это не дало результатов. Попробовал поискать по инету, но тоже ничего вразумительного по этому поводу не нашел. Кто-то, например, конвертировал файл размером в 3 млн записей, и где-то там в середине файла тоже появлялось сообщение Out of memory. Но у меня-то всего 54 тыс записей.

Я попробовал найти более новую версию IBExpert по ссылке www.ibexpert.com, но там почему-то есть только trial version, да и после установки этой версии ничего не установилось на самом деле.

Все это я проделывал в WinXP 32

Потом я попытался запустить IBExpert из-под Win7 32, но при попытке законнектиться с базой выдается сообщение, что, дескать, установлена 32-разрядная библиотека, и што я обращаюсь к 64-разрядному Firebird штоле?

Вопчем, так ничего и не вышло с этим запуском из-под Win7 32.

Может быть, надо было сначала проинсталлировать Firebird в Win7 32?

На Win XP 32 Firebird был ваапче-то предварительно проинсталлирован.

Ваапче, такое впечатление, что за истекшие полгода что-то там со ссылками на скачивание произошло. Или, может быть, я чего-то подзабыл?

Думаю, что под Win7 32 сообщений о нехватке памяти не будет (хотя, конечно, файл для коннекта не очень маленький - 120 метров примерно), но в каком порядке и что надо проинсталлировать, чтобы корректно работал Firebird?

И какие нынче есть актуальные ссылки для скачивания IBExpert free?


P.S. Может быть, можно разбить таблицу на части (или удалить несколько тыс записей в начале таблицы) средствами IBExpert и после этого выполнить конвертацию "хвоста"?



Исправлено 2 раз(а). Последнее : Simple777, 16.02.14 14:48

Поскольку через IBExpert решить проблему не удалось, попробовал (по совету многоопытных коллег на форуме ) подключиться к базе Firebird через ODBC-драйвер.

Скачал драйвер (с сайта разработчиков Firebird), проинсталлировал, подключился к базе. Вроде бы и проблем нет.
Однако выяснилось, что при выполнении sqlexec() поля integer и smallint конвертируются, а поля varchar - нет. Притом размер таких полей в базе Firebird не маленький - varchar(2500), например.

Вот пример вызова sqlexec()



Поиском на форуме пользовался, но как-то не разобрался, как все же перегнать поле varchar в memo-поле, используя sqlexec


Может быть, надо указать в запросе какие-то дополнительные опции? Или установить какие-то SET или SYS() ?


P.S. И еще дополнительный вопрос: а как взять данные из поля blob таблицы firebird ?



Исправлено 2 раз(а). Последнее : Simple777, 23.03.14 13:38

Скорее всего нужно в строке соединения (или в DSN если ты так настраиваешь соединение) указывать какие-то дополнительные настройки. Приведенная в тексте строка соединения IMHO не является корректной - там не указано даже имени драйвера...

Длинные варчар должны без проблем выниматься в мемо (при том сами). Короткие (до стандартного размера поля в 255 символов) - по умолчанию в Char, но через CURSORSETPROP("MapVarchar", .T., 0) можно их получать в фоксовом Varchar. Блобы будут выниматься скорее всего в General тип поля, но это есть очень нехорошо, и тут как раз имеет смысл задать настройку CURSORSETPROP("MapBinary", .T., 0).
Если вдруг комбинация Unicode/ANSI настроек между сервером и клиентом приводит к тому что строки вынимаются в виде Unicode (визуально - латинские буковки идут "через одну"), то следует попробовать SYS(987, .T.)

P.S. Получив -1 от SQLEXEC нужно немедленно применить AERROR(laInfo) а не заниматься гаданиями - отчего же запрос поломался...

Lainfo выдает:

LAINFO A
( 1, 1) N 1526 ( 1526.00000000)
( 1, 2) C "Connectivity error: [ODBC Firebird Driver][Firebird]arithmetic exception, numeric overflow, or string truncation
Cannot transliterate character between character sets"
( 1, 3) C "[ODBC Firebird Driver][Firebird]arithmetic exception, numeric overflow, or string truncation
Cannot transliterate character between character sets"
( 1, 4) C "HY000"
( 1, 5) N -802 ( -802.00000000)
( 1, 6) N 1 ( 1.00000000)
( 1, 7) C .NULL.

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

В таблице Firebird данные в кодовой таблице 1251 - это точно. И что же такого не может перевести VFP?

В полях типа varchar есть символы с кодом ascii <32

Но ведь это не должно влиять на результат SQL-запроса? Или влияет? Значения полей в дальнейшем должны перекодироваться, и таких символов не будет.

Если же ASCII <32 влияют на запрос, то можно как-нибудь использовать UDF для "перекодирования на лету" значения полей с ASCII <32 ?

Simple777
Как я понимаю, выдается сообщение, что строка усечена

Нет, это маловероятно.

Simple777
и нельзя выполнить транслитерацию между таблицами символов.

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

Simple777
символы с кодом ascii <32

Точно так же как и символы с другими кодами подвергаются "трансляции" - если брать однобайтные кодировки (не юникоды) то я думаю что они все переводятся "сами в себя" - и даже не только <32 но и все до 128-го А вот уже >=128 - там как раз и начинаются пляски - от замен/упрощений (типа литер с умляутами до их "базовых" версий) до полного "отказа" - например никак невозможно перевести кириллическую букву в западно-европейскую или в греческую. В юникод, конечно, можно - но опять же юникоды тоже разные...





Исправлено 1 раз(а). Последнее : Igor Korolyov, 23.03.14 16:54

Внимательно прочитал Help по настройке конфигурации соединения. Соединение устанавливается. Кодовую таблицу пробовал ставить разную. Числовые поля конвертируются. Поля varchar(2500) - нет. Устанавливал CURSORSETPROP("MapVarchar", .T., 0). Ничего не помогает. Искал примеры на хоботе и скуле. Синтаксис по соединению у меня такой же, как и в примерах. Там рассматривают случаи, когда varchar(255). При этом varchar(255) формируется в поле memo. Наверное, есть какие-то нюансы, когда varchar больше 255 символов. Может быть надо в запросе что-то указывать типа:

sele myfiel as ... и что-то после этого написать?

Или все же есть какой-то set, отвечающий за работу с varchar более 255 символов?

Вроде бы проблема смехотворная - все же известно, как надо соединяться и выполнять SQL-запрос, а вот не работает...



Исправлено 1 раз(а). Последнее : Simple777, 24.03.14 23:29

Нашел в одной из таблиц varchar(20), но даже это поле не конвертируется. Такшта дело, видимо, не в длине поля varchar, а в какой-то перекодировке. Но драйвер ODBC предлагает только выбрать таблицу для исходных данных. Ничего другого про кодовую таблицу нет. И там, где таблицы Firebird не требуют перекодировки (то есть явно читаются значения полей), можно просматривать данные даже при помощи FAR при выборе кодировки 1251.



Исправлено 1 раз(а). Последнее : Simple777, 25.03.14 08:50

Simple777
Внимательно прочитал Help по настройке конфигурации соединения.

Надеюсь это был хелп к используемому ODBC драйверу...

Simple777
Кодовую таблицу пробовал ставить разную.

Пример? В строке соединения указывал или через SET NAMES?

Simple777
Наверное, есть какие-то нюансы, когда varchar больше 255 символов.

Нет, кроме того что в не-мемо поле его вынуть, естественно, нельзя.

Simple777
Может быть надо в запросе что-то указывать

Теоретически в запросе можно менять кодировку, но если она в БД и так 1251 то это будет абсолютно лишнее.

Simple777
Или все же есть какой-то set, отвечающий за работу с varchar более 255 символов?

Нет, кроме вышеуказанных ничего нет, и зависит это вовсе не от размера варчар поля на сервере...

Взял с сайта разработчика свежую версию драйвера Firebird_ODBC_2.0.2.153_Win32.exe
Установил. Установил прогу пользующую gdb (заодно она установила и сам FB сервер). Через IBExpert посмотрел пару файликов gdb, нашел там табличку с varchar(20) и varchar(2500). Из фокса соединился и сделал простой запрос
Получил совершенно предсказуемый и корректный результат - C(20) и мемо поля - с русским текстом.

После добавления в строку соединения параметра CHARSET=WIN1251 получил на запросе твою ошибку. Если уж и надо чего указывать, так это CHARSET=NONE

Удивительное рядом!

Я указывал и таблицу 1251, и NONE в конфигурации ODBC - не работало все равно. Видимо, строка соединения у меня была не полностью сформирована, хотя и пароль, и имя пользователя в конфигурации ODBC я указывал.

У меня приведенный пример от Igor Korolyov тоже отработал корректно.
Правда, я получил этот же результат, выполнив при помощи IBExpert экспорт нужной таблицы в скрипт с расширением *.sql Потом этот *.sql загнал в таблицу по appe from, и обработал полученные записи, что было не совсем тривиально. На выходе получил такой же файл, что и по запросу через ODBC, хотя нельзя исключать, что в каких-то местах и возникли шероховатости.
А при помощи ODBC все делается в 2 строки. Теперь у меня есть 2 варианта на выбор.

Спасибо за помощь!

Хоть проблема и решилась, но осталось не совсем понятно, при помощи какой именно компоненты ODBC выполняется команда.
У меня на компьютере проинсталлированы IBEXpert и ODBC для связи с VFP

Если, я вызову сервис ODBC, например, таким способом:

lnHandle = SQLSTRINGCONNECT() && без параметров

то появляется следующее диалоговое окно, в котором можно выбрать 2 способа подключения:

- через файловый источник данных
- через источник данных компьютера

1. Файловый источник данных:

[attachment 18513 pict11.jpg]


2. Источник данных компьютера:


[attachment 18514 pict22.jpg]



Я не совсем понимаю. Оба этих способа доступны благодаря установленному драйверу ODBC, или один способ доступен через ODBC, а второй через серверную часть FireBird, которую установил IBEXpert?

И какой способ подключения выполнила команда (функция):

lnHandle = SQLSTRINGCONNECT("DRIVER=Firebird/InterBase(r) driver; DBNAME=f:\...GDB;UID=SYSDBA;PWD=masterkey")

То есть каким способом произошло подключение: через файловый источник данных или через источник данных компьютера?

И вообще, чем принципиально отличаются друг от друга оба способа подключения?


OFFTOP

P.S. Только сейчас обнаружил любопытную вещь.
Если набрать аббревиатуру VFP на кириллице, то получится МАЗ... Случайность или закономерность?

Simple777
в котором можно выбрать 2 способа подключения:

Это не разные способы подключения, это чуть разные способы хранения информации о подключении - в реестре (при том там есть ещё 2 варианта - на всю систему или только для текущего пользователя) или в файлике. По сути же они не отличаются - равно как и использование SQLSTRINGCONNECT() и явная передача информации о подключении в виде строки.

Simple777
Оба этих способа доступны благодаря установленному драйверу ODBC

Да. IBExpert вообще не при делах. А "серверная часть" - тут я не в курсе нюансов.
Однозначно что для доступа по сети (к другой машине) требуется установка "серверной части" на эту машину (ну вариант хранения базы в "общей папке" не рассматриваем - только клиент-сервер ), но вот для локального доступа - если использовать для строки подключения синтаксис с указанием локального пути/имени файла, то скорее всего серверная часть не нужна - нужна, вероятно, только клиентская библиотека gds32.dll - я не обратил внимания ставит её или нет "установщик ODBC драйвера".

Simple777
И какой способ подключения выполнила команда (функция): ... SQLSTRINGCONNECT... То есть каким способом произошло подключение: через файловый источник данных или через источник данных компьютера?

С одной стороны это "третий вариант" (для его использования вообще не нужно заходить в системную оснастку "администратор ODBC"), с другой - они практически ничем не отличаются кроме как способом передать драйверу данные для подключения
Вообще внутри ODBC API есть разница между подключением через DSN и без оного (хотя один из форматов "строки подключения" это как раз указание использовать DSN или FILEDSN - т.е. данные из реестра или из файла .dsn) но для прикладного применения можно считать что "принципиальной разницы нет".