вот для вас скинул IBExpert который сам юзаю - musicplan.nigmatec.ru



Исправлено 4 раз(а). Последнее : AndyNigmatec, 17.03.23 18:55

AndyNigmatec
Здесь нужно понимать что процедура на сервере при работе нагрузит только сервер, а клиенту уйдет только результат, а если какой-то расчет целиком в приложении - то он нагрузит в основном клиентскую машину (т.е. приложение), а сервер только чуть (поскольку данные то ему нужны).

Выбор большинство определяет с точки зрения ВОЗМОЖНОЙ миграции - если переезжаем на другую СУБД - то логику лучше хранить на клиенте. Если планируется/ожидается смена клиента (вместо Фокса - СиШарп, к примеру) - наверное лучше бизнес-логику реализовать на стороне СУБД.

Впрочем, это сугубо личное мнение, большинство реализуют на стороне сервера, как ты правильно заметил.

AndyNigmatec
дополнил там чуть про размещение логики

Да, так вот если у меня все через RDP, т.е. физически на одной машине, сервере (в смысле железа) , находится. И клиент (если я правильно понимаю, это будет VFP, много сессий разных пользователей), и сервер (в смысле БД ФБ). Что я больше нагружу? Рабочие места служат только для входа в терминал, на них ничего не выполняется.

в таком случае конечно нагрузка и так и эдак ляжет на одну машину (коль уж на ней все находится), НО

0. мы же вроде не про dbf а про firibird ...

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



Исправлено 1 раз(а). Последнее : AndyNigmatec, 17.03.23 21:37

AndyNigmatec
в таком случае конечно нагрузка и так и эдак ляжет на одну машину (коль уж на ней все находится), НО
0. мы же вроде не про dbf а про firibird ...

ну да, вместо dbc будет база данных ФБ.
Если я правильно понимаю, Фокс будет в качестве клиента, на нем формы, кнопки и какие-то процедуры-методы. А обращаться за данными и сохранять их будет в ФБ.
И все это добро на одном железном сервере, куча клиентов, запускаемых из разных сессий на сервере, и бд ФБ.

Ну это если еще доведу до конца, масштаб работы только начал проясняться, и то, что виднеется, пугает.

> как сам понимаещь тянуть такое на клиента и обрабатывать - ну такое себе ))

По-разному бывает. Бывает, (при наличии сложной процедуры обработки, мощного локального проца) затащить себе весь 1-10-100-Гб таблицу, набор таблиц, дешевле, чем писать аналогичную процедуру на ПЛ/2 каком-то, в которые нереально втащить свои какие-то мелкие хотелки, совершенно мелкие, но кодоемкие и напряжные. да, можно решить и на стороне сервера БД, но... а накуа... задачи бывают чисто однодневнее, например...

of63
задачи бывают

- таки о том и спич - нужно смотреть по ситуации

DmitryKn
Если я правильно понимаю, Фокс будет в качестве клиента, на нем формы, кнопки и какие-то процедуры-методы. А обращаться за данными и сохранять их будет в ФБ.

- примерно так, только кроме собственно данных в FB логично будет и кой-какую логику запхать - но это не обязательно делать сразу, сейчас то поскоку у вас файл-сервер вся логика в клиенте, ну пусть пока там и будет, потихоньку что нужно/хочется в бд перетащите.
Есть еще одна фича элементарно решаемая в FB - так называемые счетчики - позволяет (независимо от состояния транзакций) получить уникальный ID - вот это можно сразу реализовать.

DmitryKn
Ну это если еще доведу до конца, масштаб работы только начал проясняться, и то, что виднеется, пугает.

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

() Я придерживаюсь т.з. Максимова (и до него), что БД - это набор таблиц. Если отдаваться к хранилищу БД (SQL, постргре), то придется отдаться (заложиться) на их "ЯП", чего не хотелось бы в свете нестабильности света )

В мире вообще все временно

И отстоит, в пространственно-временных рамках, далеко за пределами наших срокОв жизни)
()Я о наших предположениях, и фантазиях, типа Г.Портера, и Суббота начинается в Пятницу

Доб. > в свете нестабильности света
() Нет стабильных ЯП, все превратилось в "фрейверки"... прогамеры получаются как индийцы - умеют писать (в каком качестве?) на каком-то ЯП... Не наша пробла. Есть С++, есть С, естьАссемблер. Воспитывать нужно програмеров на низкоуровневых ЯП. Заепали прогеры на хзкн "ЯП", есть банальные принципы програмерства - желание программировать забесплатно или за еду.



Исправлено 2 раз(а). Последнее : of63, 17.03.23 22:46

dimag

DmitryKn
Спасибо! Правда, я ведь не спрашивал, что почитать, но все равно, спасибо...

ClientServerVFP.pdf начни читать с 57 это твой случай

Внезапно чтение оказалось полезным, спасибо!

PaulWist
По простому:

1. В проекте фокса создать БД
2. В БД фокса создать соединение с "взрослой" СУБД
3. В БД фокса создать Remote View

При работу с RV устанавливать 5 буфферизацию.

Всё, дальше можно работать как с таблицами фокса.

С этим справился.

Не смог внести КАД в DE , что-то не так делаю, связь устанавливает, но то КАД не видит, то не находит курсор.

Если в методе Load КАД прописывать, как AndyNigmatec (отдельное спасибо!) пример приводил forum.foxclub.ru
то курсор заполняется, его даже могу открыть browse в том же load, а дальше затруднился, в Init формы select mycursor - нет открытых таблиц, не видит его.


Вот помимо КАД, вопрос :
изменяю RV myview, tablupdate(), а как в исходную таблицу в ФБ сохранить изменения?



Исправлено 4 раз(а). Последнее : DmitryKn, 18.03.23 14:22

>изменяю RV myview, tablupdate(), а как в исходную таблицу в ФБ сохранить изменения?
Вот в момент выдачи tablupdate() и происходит сброс информации на сервер

ЗЫ Но лично за CursorAdapter. Требует немного больше понимания для старта чем вьюха, но зато крайне гибкий и настраиваемый инструмент

Burn
>изменяю RV myview, tablupdate(), а как в исходную таблицу в ФБ сохранить изменения?
Вот в момент выдачи tablupdate() и происходит сброс информации на сервер

=TABLEUPDATE(.T.,.T.,'myview') обновит сервер(в смысле таблицу ФБ) ?

чего-то не хватает для сброса этого



Исправлено 1 раз(а). Последнее : DmitryKn, 18.03.23 20:17

Не хватает настроек RV. Что-то вы пропускаете
Давайте свое описание вьюхи. Я, конечно, с FB не работаю. Только с MS SQL. Но базовый набор должен быть общий
Как минимум должно быть указано что таблица редактируемая и указано какой первичный ключ используется для связи вьюхи и таблицы.

=CURSORSETPROP('SendUpdates' ,.t., <Имя RV>)
=CURSORSETPROP('keyFieldList', <Первичный ключ>, <Имя RV>)

Burn
Не хватает настроек RV. Что-то вы пропускаете
Давайте свое описание вьюхи. Я, конечно, с FB не работаю. Только с MS SQL. Но базовый набор должен быть общий
Как минимум должно быть указано что таблица редактируемая и указано какой первичный ключ используется для связи вьюхи и таблицы.

=CURSORSETPROP('SendUpdates' ,.t., <Имя RV>)
=CURSORSETPROP('keyFieldList', <Первичный ключ>, <Имя RV>)

Вы правы, не установил флажок "Send SQL updates". Спасибо!

Вот и славно

AndyNigmatec
для подключения/отключения под свои нужды делал себе простецкий класс-обертку (приложил)

А откуда бралась информация для createstringconnect ? имею ввиду, как в класс попадали юзер, пароль, БД и все такое?
В createstringconnect код продублирован - это имеет какое-то значение?

Какая логика подключения должна быть - один раз при входе пользователя в приложение, или при запуске формы каждый раз вкл-выкл, как коробка-автомат в городской пробке?



Исправлено 1 раз(а). Последнее : DmitryKn, 20.03.23 19:14

Коннект, дисконнект - это тоже ресурсоемкие операции, поэтому создал соединени и пользуешься им.
ЗЫ правда возникает вопрос про живость соединения, тут уже могут быть варианты.