Fox & InterBase
Alex Ilyin
Возможно ли подключиться к БД InterBase?
Безуспешно пробую по аналогии с MS SQL-сервером:
lnHandle = SQLSTRINGCONNECT( "Driver=Interbase; Server=P4; UID=SYSDBA;
pwd=MASTERKEY;
Database = qqq; )
ИнтерБэйс-клиент это ODBC-драйвер, или что-то своё, неповторимое?
После установки Клиента вместе с Сервером в администраторе источников ODBC
ничего нового не появилось.
SYSDBA и MASTERKEY - это их стандартные логин и пароль, типа "sa" в MS SQL.
Vladimir Sklyar
17 Июн 04 14:30, Alex Ilyin -> All:
AI> Возможно ли подключиться к БД InterBase?
AI> Безуспешно пробую по аналогии с MS SQL-сервером:
AI> lnHandle = SQLSTRINGCONNECT( "Driver=Interbase; Server=P4; UID=SYSDBA;
AI> pwd=MASTERKEY;
AI> Database = qqq; )
необходимо указывать путь базе данных
вот что написано в readme к одному из ODBC драйверов
Examples connection:
1)Open("DSN=mcsAddress;")
2)Open("DSN=mcsAddress;UID=MCSSITE;PWD=mcssite;")
3)Open("DSN=mcsAddress;UID=MCSSITE;PWD=mcssite;DBNAME=172.17.2.10:/usr/local/
efldata/mcsAddress.fdb;")
4)Open("DRIVER=Firebird/InterBase(r)
driver;DBNAME=172.17.2.10:/usr/local/efldata/mcsAddress.fdb;")
5)Open("DRIVER=Firebird/InterBase(r)
driver;UID=MCSSITE;PWD=mcssite;DBNAME=172.17.2.10:/usr/local/efldata/mcsAddress
.fdb;")
С уважением, Владимир ICQ UIN: 98466893
E-mail: cser...@mail.ru [ N4614EC ]
... Ах, вы не спонсоp?! Положите вилкy!..
Serg Goncharov
Как-то Alex Ilyin писал All :
AI> Возможно ли подключиться к БД InterBase?
Я тоже пару дней назад задался таким вопросом.
Порылся в инете - нашел IBPhoenix Firebird ODBC Driver, поставил.
В администраторе ODBC появился Firebird/Interbase(r) Driver.
Hастроил источник данных - указал имя источника данных (DSN), путь к базе
данных, имя пользователя "SYSDBA" и пароль "masterkey" (кстати, строчные
буквы).
Далее нажимаешь кнопку Test Connection и получаешь Connection successfill!
Запустил VFP7 и попытался создать удаленное представление.
Часть таблиц открываются нормально, часть нет. Выдается сообщение
"Connectivity error: Dynamic SQL Error"
"SQL Error code=-104"
"Token unknow - line1, char 20"
"."
По этому поводу собирался еще поковыряться и написать в эху вопрос.
Если сейчас ответит кто - не обижусь ;-)
Потом попробовал просто из командной строки понабирать:
lcDSN="MyDSN"
lnCCC=SQLCONNECT(lcDSN,"SYSDBA","masterkey")
SQLTABLES(lnCCC)
SQLEXEC(lnCCC,"select * from _nametable_")
Все работает, однако дальше не продвинулся, пока нет времени.
PS. Это моя первая попытка подключиться к удаленной базе данных.
Serg
Vladimir Sklyar
18 Июн 04 09:52, Serg Goncharov -> Alex Ilyin:
AI>> Возможно ли подключиться к БД InterBase?
[...skipped...]
Вот сейчас пробывал то кусок, который приводил ранее из описалова
драйвера, команда выглядит так
= SQLSTRINGCONNECT("DRIVER=Firebird/InterBase(r)
driver;UID=sysdba;PWD=masterkey;DBNAME=192.168.0.3:c:\cservice.fdb;")
До перестановки системы все работало, сейчас нет. Через DSN и щас работает,
но при настройке DSN я указываю библиотеку клиента и все работает. Даже при
работе с удаленным сервером из IBExpert-a без указания клиента не работает.
В старой системе у меня был еще локально установленый FireBird, т.е. он эту
библиотеку клиента зарегестир в системе, наверно
Как вариант - зарегестрить каким-нибудь макаром клиентскую библиотеку или
поставить клиента для Interbase/FireBird. Сам еще не пробывал.
С уважением, Владимир ICQ UIN: 98466893
E-mail: cser...@mail.ru [ N4614EC ]
... Борьба за мир - это как секс за девственность.
Alexey Kirpitchev
Конечно. :о)
> ИнтерБэйс-клиент это ODBC-драйвер, или что-то своё, неповторимое?
> После установки Клиента вместе с Сервером в администраторе источников ODBC
> ничего нового не появилось.
Экая путаница в голове. ODBC-драйвер - это, грубо говоря, специальный
драйвер, позволяющий работать с каким-либо источником данных посредством
определенного стандартного программного интерфейса. То есть приложение с
поддержкой ODBC знает как работать с драйвером ODBC, а уж каждый драйвер
знает как общаться со своим источником данных и возвращать полученные данные
стандартным образом обратно. Эдакий переводчик с эсперанто на другие языки.
:о)
Клиенты же баз данных - это обычно набор библиотек/исполняемых файлов,
которые реализуют низкоуровневую работу с сервером баз данных. Например это
может быть DLL, содержащая функции API для работы с сервером БД. В принципе
при наличии клиента уже можно работать с сервером БД. Но придется
использовать вызовы функций API и писать на С/С++ и т.п., либо же
использовать какую-либо обертку над API.
В случае Interbase, ODBC-драйвер - это тоже обертка над API (других не
встречал, нафига городить свое, когда самый низкий уровень уже прописан).
То бишь, для работы ODBC-драйвера Interbase необходимо, чтобы был установлен
клиент Interbase на клиентском компьютере. Его можно устанавливать
инсталятором или просто бросить файл gds32.dll (для Interbase) или
fbclient.dll (для Firebird) или yaclient.dll (для Yaffil, для последних
версий) из системной папки компа, на котором установлен сервер БД в
системную папку клиентского компа.
Резюмирую, для работы VFP с Interbase или его клонами через ODBC (можно еще
и через ADO) необходимо:
1. установить клиента Interbase на клиентский комп,
2. установить к-л ODBC-драйвер для Interbase
Сам я использую ODBC-драйвер из поставки Interbase 5.6 от Intersolve (но
для работы с Dialect 3 нужны более новые драйверы, ибо IB 5.6 о диалект 3
слыхом не слыхивал еще :о) )
Вот когда это все будет стоять на клиентском компе, тогда и можно будет из
VFP подсоединяться к IB посредством sqlstringconnect'а или sqlconnect'а.
Если VFP, версии меньше 6, то придется сделать System DSN и подключаться
так:
nc = sqlstringconnect('DSN = имя_DSN; DB = имя_сервера:путь_к_БД; UID =
имя_пользователя; PWD = пароль')
либо
nc = sqlconnect('имя_DSN', ...) - в зависимости что указано в настройках DSN
(см. VFP Help)
Как только соединение состоится - SQLEXEC в руки, и делать все что
заблагорассудится. :о)
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Serg Goncharov
Как-то Alexey Kirpitchev писал Alex Ilyin :
AK> Как только соединение состоится - SQLEXEC в руки, и делать все что
AK> заблагорассудится. :о)
А не подскажешь ли ты, почему попытка создать удаленное представление для
доступа к Interbase серверу с помощью View Designer вызывает
ошибку сразу после выбора ЛЮБОЙ таблицы:
"Connectivity error: Dynamic SQL Error"
"SQL Error code=-104"
"Token unknow - line1, char 20"
"."
В то же время, из командной строки представление создается.
CREATE SQL VIEW My_VIEW REMOTE CONNECTION connect1;
as select * from events
И потом дизайнером открывается...
PS. С помощью sqlexec достучаться до таблиц получается.
Пока не получается модифицировать данные в таблице.
Внимательнее, видимо, надо почитать про cursorsetprop() ;-).
Serg
Alexey Kirpitchev
для
> доступа к Interbase серверу с помощью View Designer вызывает
> ошибку сразу после выбора ЛЮБОЙ таблицы:
> "Connectivity error: Dynamic SQL Error"
> "SQL Error code=-104"
> "Token unknow - line1, char 20"
> "."
> В то же время, из командной строки представление создается.
> CREATE SQL VIEW My_VIEW REMOTE CONNECTION connect1;
> as select * from events
> И потом дизайнером открывается...
Смотри, что Remote View Designer в SQL подставил. Не нравится IB, что там
написано.
Вообще, я уже давно Remote View не пользуюсь. Шибко ограниченные они по
возможностям. Предпочитаю сквозные запросы. Да и использование
SQLSTRINGCONNECT'а удобнее - настройки соединения можно вынести в ini-файл,
а не мучится с настройкой DSN'ов и Connections.
Использование Remote View в VFP 7.0 вообще бесполезно при наличии
CursorAdapter'а - гораздо мощнее и удобнее(я использую свой класс,
аналогичный)
> PS. С помощью sqlexec достучаться до таблиц получается.
> Пока не получается модифицировать данные в таблице.
> Внимательнее, видимо, надо почитать про cursorsetprop() ;-).
Не обязательно связываться с автоматикой, тем более, что автоматика эта
знать не знает о хранимых процедурах, а обновления зачастую проще с помощью
них осуществлять. И вообще, ну ее, автоматику эту, многого она не умеет. :о)
Хотя без использования CursorAdapter'а (или аналогов) нужно много писать
ручками для обновления в лоб.
Примерно так:
= SQLEXEC(nc, 'UPDATE ib_table set field1=?имя_переменной/поля_таблицы where
field2=?)
или
= SQLEXEC(nc, 'INSERT into ib_table (field1, field2)
values(?имя_переменной/поля_таблицы, ?имя_другой_переменной)')
или для хранимых процедур:
= SQLEXEC(nc, 'EXECUTE PROCEDURE upd_table1 (?имя_переменной/поля_таблицы,
?имя_другой_переменной)')
А после не забывать про Commit:
= SQLCOMMIT(nc)
Serg Goncharov
Как-то Alexey Kirpitchev писал Serg Goncharov :
> "Token unknow - line1, char 20"
> "."
AK> Смотри, что Remote View Designer в SQL подставил. Hе нравится IB,
AK> что там написано.
Это я уже понял. Ошибка появляется сразу при попытке добавить первую же
таблицу, и View SQL показывает пустоту.
AK> Вообще, я уже давно Remote View не пользуюсь. Шибко ограниченные
AK> они по возможностям. Предпочитаю сквозные запросы. Да и
AK> использование SQLSTRINGCONNECT'а удобнее - настройки соединения
AK> можно вынести в ini-файл, а не мучится с настройкой DSN'ов и
AK> Connections.
AK> Использование Remote View в VFP 7.0 вообще бесполезно при наличии
AK> CursorAdapter'а - гораздо мощнее и удобнее(я использую свой класс,
AK> аналогичный)
Я только начинаю работать с удаленными данными, хотелось бы попробовать
разные варианты.
У меня VFP 7.0, а CursorAdapter только в 8.0 появился...
PS. Спасибо за подробный ответ.
Serg
Alexey Kirpitchev
> AK> что там написано.
> Это я уже понял. Ошибка появляется сразу при попытке добавить первую же
> таблицу, и View SQL показывает пустоту.
Ну не знаю, у меня таких проблем не было. Может ODBC-драйвер кривит. Больше
ничего сказать не могу.
> Я только начинаю работать с удаленными данными, хотелось бы попробовать
> разные варианты.
По мне так Remote View для баловства, для простейших задач. :о)
> У меня VFP 7.0, а CursorAdapter только в 8.0 появился...
Его даже в семерке не было? М-да... Я просто с 5 на 8 прыгнул.
Для VFP 5.0 и класс свой писал еще не зная ничего о CursorAdapter'e (по
мотивам дельфийских компонент)
http://www.foxclub.ru/sol/index.php?act=view&id=380
Только потом выяснилось, что в VFP >5.0 инициализация курсора (есть там
свойство SQLInitSelect) при открытии формы не происходит (объекты в гриде
требуют привязки к источнику сразу после создания, а не после создания
грида, как в VFP 5). А при наличии открытого курсора все работает.
В общем, требует еще доводки (мне пока не до него), но использовать можно,
во всяком случае, идеи :о) Иначе использовать сквозные запросы не очень,
мягко говоря, удобно. :о)
Igor Korolyov
You wrote to Serg Goncharov on Tue, 22 Jun 2004 16:37:05 +0000 (UTC):
[Sorry, skipped]
AK> По мне так Remote View для баловства, для простейших задач. :о)
Смотря как его использовать :) Например я его использую для хранения текстов
SQL запросов (их всё равно надо где-то хранить :)) и параметров настройки
"автообновления" - т.е. сам RV открываю в режиме NODATA а потом взяв оттуда
всё что надо по CursorGetProp (в т.ч и хендл расшаренной коннекции или
statement-а в VFP 8) и уж потом работаю с SPT.
[Sorry, skipped]
AK> Только потом выяснилось, что в VFP >5.0 инициализация курсора (есть там
AK> свойство SQLInitSelect) при открытии формы не происходит
Ну это смотря где и что прописывать - для объектов "положенных" на формы
порядок инициализации сложно предугадать и ещё сложнее управлять - но если
их динамически создавать в Load то вроде как должно сработать... А в VFP8
специально добавили свойство BindControls - пока оно .F. никакие контролы не
пытаются обращаться к своим источникам...
AK> (объекты в гриде требуют привязки к источнику сразу после создания, а
AK> не после создания грида, как в VFP 5). А при наличии открытого курсора
AK> все работает.
Соответственно обходной манёвр - создавать "заглушки" - т.е. "пустые"
курсоры через CREATE CURSOR ... Где-то в Load или через DE, а потом
пересоздавать их на основе твоего класса доступа. Возникающая проблема
перестройки грида думаю не смутит - ибо решается на раз :)
AK> В общем, требует еще доводки (мне пока не до него), но использовать
AK> можно, во всяком случае, идеи :о) Иначе использовать
AK> сквозные запросы не очень, мягко говоря, удобно. :о)
Да, без классовых обёрток и без отдельных хранилищ для текстов SQL запросов
и прочих параметров это нетехнологично...
--
WBR, Igor
Alexey Kirpitchev
текстов
> SQL запросов (их всё равно надо где-то хранить :)) и параметров настройки
> "автообновления" - т.е. сам RV открываю в режиме NODATA а потом взяв
оттуда
> всё что надо по CursorGetProp (в т.ч и хендл расшаренной коннекции или
> statement-а в VFP 8) и уж потом работаю с SPT.
Тексты запросов в самом объекте и хранятся. :о) По задумке он полностью
самодостаточен: инициализирует курсор с помощью запроса, обновляет данные
(все или строку), отправляет изменения.
И хэндл коннекции получать гораздо технологично по SQLSTRINGCONNECT. :о)
> Ну это смотря где и что прописывать - для объектов "положенных" на формы
> порядок инициализации сложно предугадать и ещё сложнее управлять - но если
> их динамически создавать в Load то вроде как должно сработать... А в VFP8
> специально добавили свойство BindControls - пока оно .F. никакие контролы
не
> пытаются обращаться к своим источникам...
Дык, идея то в том и была, что все прописывается на этапе проектирования
формы - объект кладется на нее в дизайнере и свойства прописываются (в том
числе и тексты запросов). Остается только форму запустить, а при ее закрытии
можно настроить и автоматическое закрытие курсоров :о) В VFP 5.0 так все и
работает.
В VFP 8.0 извернулся с помощью BindControls по твоему совету :о) (я уже
писал про этот курсорадаптеровидный ;о) Грид).
А с динамическим созданием в LOAD, ясен пень заработает, но задумывалось то
другое, опять же дополнительное кодирование.
> Соответственно обходной манёвр - создавать "заглушки" - т.е. "пустые"
> курсоры через CREATE CURSOR ... Где-то в Load или через DE, а потом
> пересоздавать их на основе твоего класса доступа. Возникающая проблема
> перестройки грида думаю не смутит - ибо решается на раз :)
Опять же путь понятный, но не то, не есть гуд. :о) Меняется структура - надо
менять запрос в нескольких местах... А с использованием моего Грида -
изменил свойство - и все, Вэлкам! :о)
Естетственно с перестройкой грида и так уже все решено, иначе не работало бы
обновление курсора.
В общем, в 5-м и 8-м VFP Грид этот работает как задумано, а вот в 6 и 7
предварительная инициализация курсора нужна.
> Да, без классовых обёрток и без отдельных хранилищ для текстов SQL
запросов
> и прочих параметров это нетехнологично...
Да уж, подтверждаю. Испытано на себе. :о)
--
Igor Korolyov
You wrote to Igor Korolyov on Thu, 24 Jun 2004 17:03:20 +0000 (UTC):
[Sorry, skipped]
AK> Тексты запросов в самом объекте и хранятся. :о) По задумке он полностью
AK> самодостаточен: инициализирует курсор с помощью запроса, обновляет
AK> данные (все или строку), отправляет изменения.
Не очень красиво - получается огромная куча классов (конечно если их вынести
из формы) - для всякого источника данных свой класс... А если делать через
параметрически настраиваемые классы, то теоретически достаточно одного
класса - он считает всё что надо из словаря данных (тексты запросов и т.п.)
и таким макаром надо будет только указывать какой именно источник данных нам
нужен для конкретного экземпляра этого класса... Ессно что есть и
исключения - когда надо индивидуально кодировать всякие BeforeUpdate и т.п.
(для CA конечно, но возможно что и для твоих классов - если ты реализовывал
в них "псевдо-события" т.е. методы гарантированно вызывающиеся при тех или
иных действиях над курсором).
AK> И хэндл коннекции получать гораздо технологично по SQLSTRINGCONNECT. :о)
Да тут ты совершенно прав.
[Sorry, skipped]
AK> Дык, идея то в том и была, что все прописывается на этапе проектирования
AK> формы - объект кладется на нее в дизайнере и свойства прописываются (в
AK> том числе и тексты запросов).
Это сильно накладно IMHO. Практически никакого ООП - значит масса ручной
работы :(
[Sorry, skipped]
AK> В общем, в 5-м и 8-м VFP Грид этот работает как задумано, а вот в 6 и 7
AK> предварительная инициализация курсора нужна.
Ну ещё один способ - динамическая привязка грида (да и в принципе любых иных
контролов) - т.е. не пиши в дизайнере RecordSource и ControlSource, а
заполняй их только после полной инициализации формы (например дёрнув из Init
формы спец. метод грида "ReBind"... В VFP6 и старше это достаточно просто
сделать через Property_Assign для класса грида + Form.SetAll("Property"...))
--
WBR, Igor
Alexey Kirpitchev
вынести
> из формы) - для всякого источника данных свой класс... А если делать через
> параметрически настраиваемые классы, то теоретически достаточно одного
> класса - он считает всё что надо из словаря данных (тексты запросов и
т.п.)
> и таким макаром надо будет только указывать какой именно источник данных
нам
> нужен для конкретного экземпляра этого класса... Ессно что есть и
> исключения - когда надо индивидуально кодировать всякие BeforeUpdate и
т.п.
> (для CA конечно, но возможно что и для твоих классов - если ты
реализовывал
> в них "псевдо-события" т.е. методы гарантированно вызывающиеся при тех или
> иных действиях над курсором).
Он в форме должен быть. Это ж Грид. :о) (даже если потом разделю на две
части: источник данных и Грид, умеющий работать с ним в паре, все равно
место его в форме).
А мне вот не кажется, что использование еще одного звена, в виде словаря, не
упрощает работу. :о)
> Это сильно накладно IMHO. Практически никакого ООП - значит масса ручной
> работы :(
Не вижу в чем ручной работы больше чем при использовании словаря. Форму все
равно рисуем в дизайнере, тут сразу и объекты доступа под бочком. А для
изменеия в словаре нужно дополнительно его открыть, найти соответвующую
запись по к-л идентификатору... Не вижу преимуществ. Опять же - не дай бог
помрет словарь - все запросы и настройки тю-тю. :о) А все формы убить - надо
еще постараться. ;о)
Хотя для некоторых случаев и подойдет такая организация, не спорю. Но мне
пока нет. :о)
А при чем тут ООП? Чем мои объекты, наследники одного класса, хуже одного
твоего объекта, наследника тоже одного класса? :о)
> Ну ещё один способ - динамическая привязка грида (да и в принципе любых
иных
> контролов) - т.е. не пиши в дизайнере RecordSource и ControlSource, а
> заполняй их только после полной инициализации формы (например дёрнув из
Init
> формы спец. метод грида "ReBind"... В VFP6 и старше это достаточно просто
> сделать через Property_Assign для класса грида +
Form.SetAll("Property"...))
Это понятно. Но где-то в объекте надо хранить источники данных для множества
колонок. Визуально свойство-массив не заполнишь...
--
Igor Korolyov
You wrote to Igor Korolyov on Fri, 25 Jun 2004 16:54:09 +0000 (UTC):
[Sorry, skipped]
AK> А мне вот не кажется, что использование еще одного звена, в виде
AK> словаря, не упрощает работу. :о)
Если запросы используются повторно - упрощает. Да и централизация тоже порой
сильно упрощает жизнь - не надо помнить в каких же это формах я использовал
таблицу1 чтоб при изменении структуры поменять и объекты доступа.
??>> Это сильно накладно IMHO. Практически никакого ООП - значит масса
??>> ручной работы :(
AK> Не вижу в чем ручной работы больше чем при использовании словаря.
В том что надо ходить по куче форм а не по одному словарю, что надо повторно
вводить одни и те-же запросы/параметры, если разные формы имеют одинаковые
источники данных (источник то может быть не один, так что часть из них
вполне нормально будет дублироваться в разных формах).
AK> Форму все равно рисуем в дизайнере, тут сразу и объекты доступа под
AK> бочком.
При начальном создании - да, но при последующем сопровождении - нет. И как
правило на сопровождение падает более 50% всех затрат на программу, так что
удобство там очень важно.
AK> А для изменеия в словаре нужно дополнительно его открыть, найти
AK> соответвующую запись по к-л идентификатору... Не вижу преимуществ. Опять
AK> же - не дай бог помрет словарь - все запросы и настройки тю-тю. :о) А
AK> все формы убить - надо еще постараться. ;о)
Какой же программист не делает Backup? А если винт сдохнет? Или вирус злой
Format C: сделает?
AK> Хотя для некоторых случаев и подойдет такая организация, не спорю. Но
AK> мне пока нет. :о)
Наверное ты мало занимаешься "ведением" т.е. сопровождением своих программ.
Ессно если прога написана один раз и потом ты про неё забыл - тебе это и не
нужно, а вот если надо постоянно вносить какие-то изменения (способ расчёта
поменялся, законы поменяли, новый директор решил по новой схеме работать и
т.п. причин к тому миллион) - тогда раскиданный по куче форм код запросов
отслеживать сложнее.
AK> А при чем тут ООП? Чем мои объекты, наследники одного класса, хуже
AK> одного твоего объекта, наследника тоже одного класса? :о)
Я имел в виду что для "повторности" надо либо прописывать "всё" в отдельных
классах - наследниках базового и на форму ложить уже именно эти классы, либо
делать схему со словарём - чтобы класс сам смог себя настроить. Опять-же
цель - вынести возможно повторный код из форм (в классы либо в словарь).
[Sorry, skipped]
AK> Это понятно. Но где-то в объекте надо хранить источники данных для
AK> множества колонок. Визуально свойство-массив не заполнишь...
Ну можно скажем в Tag колонок прописывать... Хотя многие тебе могут
небезосновательно посоветовать делать это именно невизуально (через код - а
там заполнить саммив не проблема).
--
WBR, Igor