Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» InterBase и FireBird: вопросы по работе и их решение

Автор: Odysseos
Дата сообщения: 22.03.2010 12:43
JohnSilver182

А !! Тоесть на каждую USER TABLE можно повесить событие , которое пишется в
RDB$LOG (Если менялась структура таблицы )???


Не совсем так - разработчику самому ничего никуда повесить будет нельзя, и ничего он в RDB$LOG не найдёт. Но IBExpert сам создаст некоторое количество таблиц с префиксом IBE$, в которые он будет записывать все изменения в метаданных, которые сделает разработчик.
Автор: JohnSilver182
Дата сообщения: 22.03.2010 13:02
Odysseos ААААААА . Так таблицы префиксом IBE$ таблицы ни разу не системные .
Автор: Odysseos
Дата сообщения: 22.03.2010 14:58
JohnSilver182

Они не системные - но также и не участвуют в схеме данных создаваемой БД, и используются только самим IBExpert'ом, потому удалить их при ненадобности этого функционала можно без опасений.
Автор: OXDBA
Дата сообщения: 22.03.2010 16:03
X11

Цитата:
Если зачем нужны таблицы логирования, то они предназначены для просмотра всех изменение метаданных.

Не для метаданных, для данных.
JohnSilver182
Создаются 4 таблицы
IBE$LOG_TABLES
IBE$LOG_KEYS
IBE$LOG_FIELDS
IBE$LOG_BLOB_FIELDS.



Добавлено:

Цитата:
Они не системные - но также и не участвуют в схеме данных создаваемой БД, и используются только самим IBExpert'ом

Ну почему же, очень даже используются отдельными ленивыми разработчиками
Автор: Odysseos
Дата сообщения: 22.03.2010 17:37
OXDBA

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

Ну, этак можно и на таблицы RDB$... ссылаться Но зачем выдумывать себе такой изощрённый геморрой?
Автор: OXDBA
Дата сообщения: 22.03.2010 20:29
Odysseos
Еще раз повторяю - лог изменения данных(он же лог наката, он же лог DML, он же протокол действий оператора и т.д. и т.п.), а не метаданных. Отсюда вопрос - в какой системной таблице FB хранится лог Insert/Update/Delete как в IBE$LOG_TABLES?
Автор: JohnSilver182
Дата сообщения: 22.03.2010 21:59
Кстати !!! А я так понял в FIREBIRD почемуто нет игнорирования Регистра букв ??

т.е. так не работает
select * from drug_list where drug_name like '%АсПирИн%'

так работает
select * from drug_list where upper(drug_name) like '%АСПИРИН%'
Автор: Odysseos
Дата сообщения: 22.03.2010 22:12
JohnSilver182

А я так понял в FIREBIRD почемуто нет игнорирования Регистра букв ??

А что, где-то есть?

...Все пользуются при сравнении строк без учета регистра конструкцией upper(field_name) like '%' || upper(:param) || '%'
Автор: JohnSilver182
Дата сообщения: 22.03.2010 22:51

Цитата:
А что, где-то есть?


?? Ну есть точно в MS SQL , Access , MY SQL
Просто куча upper неэлегантно .

Автор: Odysseos
Дата сообщения: 23.03.2010 00:15
JohnSilver182

Там оно есть в виде чего? В виде заранее указанного для столбца collation order? Для Firebird'а - теоретически - можно написать свою dll с интерфейсом, аналогичным fbintl.dll (исходники которого в наличии, и пример можно посмотреть), и создав его описание в fbintl.conf, добавив соответствующие charset и collation order'ы в Firebird. Но, видимо, не особо оно надо, раз никто так и не сделал.
Автор: OXDBA
Дата сообщения: 23.03.2010 09:57

Цитата:
Кстати !!! А я так понял в FIREBIRD почемуто нет игнорирования Регистра букв ??

select * from drug_list where drug_name containing 'АсПирИн'
Автор: JohnSilver182
Дата сообщения: 23.03.2010 10:03
OXDBA Шаман !!

З.Ы. А вобще меня это высаживает что недостаточно просто знать SQL язык. Надо еще знать местные расширения .
Автор: Odysseos
Дата сообщения: 23.03.2010 12:46
JohnSilver182

Учтите, что containing поможет, только если надо искать '%' || <искомое> || '%' - для поиска в начале или в конце строки, или со сложной маской, он не поможет.
Автор: JohnSilver182
Дата сообщения: 23.03.2010 13:11
Odysseos Вот засада !!!

Автор: Odysseos
Дата сообщения: 23.03.2010 14:46
JohnSilver182

А в чем засада-то? Ну да, upper'ы несколько засоряют код - но это их единственный минус, в остальном - все работает.
Автор: kolyas
Дата сообщения: 26.03.2010 16:43
подскажите, плизз,.. как можно из рабочей базы interbase получить sql скрипт создания базы
так как с Interbase не знаком, хочу воссоздать схему с потоком данных в Workbench
Автор: JohnSilver182
Дата сообщения: 26.03.2010 16:50
kolyas IBExpert http://ibexpert.net/ibe/index.php?n=Main.Download
Автор: volser
Дата сообщения: 26.03.2010 16:51
kolyas
Скачать IBExpert - инструмент для работы с БД здесь.
Автор: kolyas
Дата сообщения: 26.03.2010 17:08
JohnSilver182, volser
IBExpert есть, а что там дальше?
Автор: AvGSoft
Дата сообщения: 26.03.2010 17:19
kolyas
Настройки->Извлечение метаданных
Автор: kolyas
Дата сообщения: 26.03.2010 17:23
AvGSoft
в смысле Интсрументы - >Извлечение метаданных
понятно спсб..

Добавлено:
AvGSoft
а кроме таблиц, я так понимаю извлекать больше ничгео не надо ? ..
Автор: X11
Дата сообщения: 26.03.2010 17:33

Цитата:
а кроме таблиц, я так понимаю извлекать больше ничгео не надо ? ..

Это ты у нас спрашиваешь, что ТЕБЕ надо? Выбери объекты, которые тебе нужны или все сразу, полный дамб метаданных.
Автор: kolyas
Дата сообщения: 26.03.2010 17:50
X11, AvGSoft, volser, JohnSilver182

всем спасибо, все извлек.. буду играться дальше.


Добавлено:
вопрос.. а нельзя как нибуль экспортировать чтобы форма запис и была не interbase а более стандартная запись sql
Автор: emo
Дата сообщения: 27.03.2010 08:47
kolyas

Цитата:
вопрос.. а нельзя как нибуль экспортировать чтобы форма запис и была не interbase а более стандартная запись sql

А что означает стандартная запись sql?
Экспортируются в виде скрипта, который можно выполнить. Чем не "стандарт"?
Автор: jonikDk
Дата сообщения: 27.03.2010 09:35

Цитата:
вопрос.. а нельзя как нибуль экспортировать чтобы форма запис и была не interbase а более стандартная запись sql

вопрос ... а может доку пойдем покурим
Автор: JohnSilver182
Дата сообщения: 27.03.2010 10:01

Цитата:
вопрос.. а нельзя как нибуль экспортировать чтобы форма запис и была не interbase а более стандартная запись sql

АА . Меня это тоже высаживает . Как таковых стандартов SQL общих я так понял на практике нет и не будет .
Автор: kolyas
Дата сообщения: 27.03.2010 16:33
emo, jonikDk


Код:
CREATE TABLE ADDRESS (
INDE_ VARCHAR(6) CHARACTER SET NONE,
STR_NO VARCHAR(10) CHARACTER SET NONE,
KORPUS VARCHAR(20) CHARACTER SET NONE,
STROENIE VARCHAR(10) CHARACTER SET NONE,
PODJEZD VARCHAR(10) CHARACTER SET NONE,
PAVILON VARCHAR(10) CHARACTER SET NONE,
OFIS VARCHAR(20) CHARACTER SET NONE,
KVARTIRA VARCHAR(10) CHARACTER SET NONE,
ADRESS VARCHAR(72) CHARACTER SET NONE,
CITIES_ID INTEGER,
RAJONS_ID INTEGER,
STREETS_ID INTEGER,
ROUT_NAME VARCHAR(10) CHARACTER SET NONE,
USERCREATOR VARCHAR(20) CHARACTER SET NONE DEFAULT user,
CREATINGDATETIME DATE DEFAULT "now",
ORDERS_ID INTEGER,
ADDRESSU_ID INTEGER
);
Автор: AvGSoft
Дата сообщения: 27.03.2010 20:15
kolyas
Я чет не пойму, зачем тебе это все? Если базу перевести с Interbase на MySQL то все равно прийдется, что-то руками подправлять, а если схему воссоздать то то можно в том же IBExpert'e через дизайнера БД или Interbase&Firebird Development Studio (но опять же схему прийдется потом к божескому виду приводить, не все хорошо размещает).
Автор: kolyas
Дата сообщения: 28.03.2010 01:37
AvGSoft
да в итоге перевести на mysql. понятно раз надо ручками .. будем ручками ..
Автор: JohnSilver182
Дата сообщения: 01.04.2010 13:39
Hi All
Проблема в следующем
Контора XXX раставляет свое "гениальное" творение под F 1.5
У меня под F 2.1
Что бы не испортить этот зоопарк , я просто поставил на своей домашней машин F 2.1 как приложение , и просто скопировал каталог клиенту.
У клиента все заработало , но только там, где непосредственно стоит F 2.1 ( как приложение скопированное с моего компа) .
Порт я выбрал 3097 . Подключение типа : 192.168.0.1/3097
Но вод что странно , что по сети у клиента не хочет !!!!!!

Страницы: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465

Предыдущая тема: Сравнение двух строк


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.