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

И в чём конкретно будет состоять "переделка" программы, если поместить свободный dbf в dbc контейнер Сколько строк кода потребуется поменять

Ну и да, делать копию (ага, для совместно используемой таблицы, особенное если её размер хорошо так за сотню Мб перевалил, и сама она на файл-сервере лежит), сравнивать один dbf с другим после "завершения работы" (опять же ОЧЕНЬ весело если таблица в это время использовалась другой копией программы - наверное предложишь делать ЕЩЁ одну копию, и сравнивать их между собой, хотя от смеси "своих и чужих" изменений и это не поможет). И это всё как-то всовывать (другого слова не подберу) в написанную уже программу, неизвестно куда... Неизвестно как работающую с таблицами (может там и места то нет куда это можно засунуть - если таблицы открываются в одних формах, используются в других а закрываются вообще в третьих - особенно с учётом того что для некоторых приватные датасессии это "зло", и открытие/закрытие таблиц равномерно размазано по всей "логике" работы программы)... Решение на пятёрку - только не баллов а щелбанов

Сколько програмёров, столько и кривых убогих, Игорь. (А преподавателей - хоть отбавляй...)

of63
Имеется ввиду, что произвольную прогу с БД в виде таблиц, просто так в контейнер не втащишь, надо код переделывать.

И с какого это перепугу? ЧТО переделывать?

Открыть, например

Ну давайте уже срач

of63
Открыть, например

Что открыть? Таблицу? Как было Use так и осталось? В чем проблема?

А OPEN DATABASE ?

of63
А OPEN DATABASE ?

Еще раз - с какого перепугу?
Ты НАСТОЛЬКО плохо знаешь фокс?

А разве не заметно?

Доб. (да, открывается без OPEN DATAB... зараза... это я себе)



Исправлено 1 раз(а). Последнее : of63, 29.12.17 15:23

vodaic

vnkor

vodaic
Подскажите, пож, как определить, корректировалась ли запись таблицы dbf в текущем сеансе работы с этой таблицей?

А в чем, собственно, проблема?

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

А можно по-подробнее? Что это за таблица такая? Какие в ней поля? Какие поля нужно контролировать? Кто осуществляет контроль? Периодичность контроля? Пример можно?

Да, он, автор, он свои желания так и не изложил, в понятном виде. Скорее всего ему это уже не нужно, возможно )

of63
Доб. (да, открывается без OPEN DATAB... зараза... это я себе)

Это какое-то чудо. ;)

vnkor
А можно по-подробнее? Что это за таблица такая? Какие в ней поля? Какие поля нужно контролировать? Кто осуществляет контроль? Периодичность контроля? Пример можно?

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

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

Igor Korolyov
И в чём конкретно будет состоять "переделка" программы, если поместить свободный dbf в dbc контейнер Сколько строк кода потребуется поменять

Вообще-то, довольно много. Это "в принципе" другой способ работы с данными.

Ну, вопрос про несовместимость версий опустим. Предположим, что автор вопроса работает все-таки с Visual FoxPro, а не с FP2.x

1. Нужна "обвязка" открытия DBC на предмет возможных ошибок.

Вот ни за что не поверю, что для открытия таблиц используется напрямую команда USE без "обвязки" в виде какой-либо процедуры на предмет перехвата возможных ошибок открытия. Это я все время говорил, что можно и просто Data Environment использовать, но, почему-то, всех это дико возмущало. Одной из причин возмущения была именно невозможность прикрутить обработчик ошибок к процессу открытия таблицы

Ну, то, что при автоматическом открытии базы данных будет использована текущая настройка SET EXCLUSIVE, вообще упоминать не стоит. Мелочь...

2. Вопросы администрирования базы данных

Как минимум, если выполняется копирование в архив по расширению файлов, надо не забыть про DBC. Если есть программы "ремонта" заголовков DBF, опять не забыть про DBC. "Ремонт" путем создания таблицы заново и заливки в нее данных из "проблемной" потребует переделки

2.1. Довольно распространенный прием работы в старых версиях FoxPro - это (пере)создание таблиц. Создать обычную DBF-таблицу для хранения временных данных, а потом ее удалить. Если открыт DBC, то будут проблемы. Новая таблица создается сразу в контейнер. Ее удаление - это проблема

Это то, что "на вскидку" вспомнил. Наверняка есть еще куча подобных мелких "заподлянок". Не то, чтобы это все было неразрешимо, но и говорить, что в рабочем приложении, построенном на свободных DBF-таблицах включить эти таблицы в контейнер базы данных - просто. Я бы не стал.

По моему, это сопоставимо с тем, что сказать, что для переделки монопольного приложения в многопользовательское, достаточно сделать настройку SET EXCLUSIVE OFF. На первый взгляд, действительно, а что еще надо-то? Но начинаешь делать и выясняется, что надо еще много где "подклеить и подмазать"

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

Цитата:

Вообще-то, довольно много. Это "в принципе" другой способ работы с данными.

Есть что-то хорошее для "совсем новичка", условно. Ему - это способ для "научиться ходить на своих ногах в Фоксе".
Ну, я считаю, что этот уровень прошел (IMHO).
Для меня "dbc контейнер" - это типа Formset, здесь типа неудачная попытка "косить" под Ораклы.
И это, IMHO, надо просто похоронить, если уже попробовал на серьезном.
Там на 2 пальца удобств, и на 1 палец неудобств. Но это разные пальцы.
Каждый решает сам, какие у него пальцы.
Я работаю на коллектив, мне dbc контейнер не подходит.
Я могу спокойно добавить таблицу при переходе на новый период и мне это нужно по моему сценарию.
И я могу это делать, по-фиг, что я с DBF или нормальным SQL работаю!
Еще аварийные копии автоматом делаются.
А тут тебе скажет, что таблица не из этого контейнера.
Зачем мне это? На 2 пальца удобств не стоят одного пальца неудобств.

Если б я был одиночным программистом, я бы не писал Framework.
Если б я работал на бюджете, наверно, с возрастом, тоже писал.
С возрастом борются, там не гавкай, там ждешь только под зад коленом.
И амнистии не жди, там уже диагноз - "старпера выгнали". Святое.
И в целом, правило хорошее и оправданное.

Поэтому, отнеситесь к тому, что сказано выше, как можно оптимистичнее.

Цитата:

Что русскому хорошо, то немцу еще хуже

Исправлено 10 раз(а). Последнее : Ydin, 02.01.18 20:58

Ydin
Для меня "dbc контейнер" - это типа Formset, здесь типа неудачная попытка "косить" под Ораклы.
И это, IMHO, надо просто похоронить, если уже попробовал на серьезном.

Если стоит выбор фоксовая dbc или оракл/мсскл/мускул/постгре - тогда да, dbc "не нужен".
Если стоит выбор dbc или куча dbf - то тоже нет вопроса. Кучу dbf - на свалку истории.

Ydin
Я могу спокойно добавить таблицу при переходе на новый период и мне это нужно по моему сценарию.
И я могу это делать, по-фиг, что я с DBF или нормальным SQL работаю!

И это печально. Т.к. я могу сделать БД где НИКОГДА не потребуется "добавлять таблицу на новый период". И таковой сценарий, уж извини, для меня просто дурно пахнет. Да, я могу "простить" его при работе с dbf-ами - если ПО писалось на FPD/Clipper, ну или "переводилось в VFP автоматом". Есть ещё оправдывающее исключение - гигабайтные массивы данных - когда просто не помещается всё что надо в фоксовый лимит 2Гб на таблицу.
Всё прочее - лично для меня - признак незнания и неумения пользоваться инструментом. Ещё раз извини... То что было "нормально" 20-30 лет назад для FPD, стало абсолютно неадекватно уже 10-15 лет назад для VFP.

Ydin
Еще аварийные копии автоматом делаются.
А тут тебе скажет, что таблица не из этого контейнера.

Резервная копия, вообще-то, должна включать в себя ВСЕ компоненты БД - как ВСЕ dbf/fpt/cdx (ну, возможно, за исключением "абсолютно ReadOnly" таблиц - но они обычно гораздо меньше по размеру нежели "рабочие" таблицы, и смысла "экономить" на них как-то не видно), так и все dbc/dct/dcx. Можно, конечно, для систем где структура БД (включая все индексы!) уже давно устаканилась и потому неизменна, исключать из "основной" резервной копии dbc/dct/dcx и даже cdx - но держать их в отдельной резервной копии (эти файлы тоже могут сломаться/удалиться/занулиться/зашифроваться вирусом-вымогателем) - а если туда же добавить и пустые dbf (ну или заполненные лишь статическими справочными данными), то получим хорошую резервную копию "чистой/пустой БД" - очень удобно для начальной установки, кстати.
Пути там относительные, и нет решительно никаких проблем в подсовывании к "старым/эталонным" dbc dbf-ов из "последней резервной копии" - никаких сообщений о том что "я из другого dbc" не будет - конечно же если соблюдать относительное расположение файлов - в 99.9% случаев это тупо "одна папка", и ничего иного "городить" не следует. И даже cdx можно брать "пустые"/эталонные - только не забывать в этом случае делать REINDEX после восстановления... Всяко проще, надёжнее и быстрее нежели тонны INDEX ON ... в коде "переиндексации/починки".
Естественно для систем где структура таблиц меняется по 5 раз на день это не подойдёт - там только полная копия включая dbc...

Впрочем, каждый сам себе злобный буратино - пишет как умеет, и чужим опытом пренебрегает

Игорь, не только ты один лишь добрый "буратино", ты словами все же не матку режешь...

Доб. (и опять до... много текста...)



Исправлено 1 раз(а). Последнее : of63, 02.01.18 21:14

Igor Korolyov
Всё прочее - лично для меня - признак незнания и неумения пользоваться инструментом

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

Цитата:

я могу сделать БД где НИКОГДА не потребуется "добавлять таблицу на новый период"

Вообще, не делаю БД! Делаю какой-то софт. И, если вдруг, сказали надо добавлять таблицы на новый период...

Цитата:

Резервная копия, вообще-то, должна включать в себя ВСЕ компоненты БД

Чего это вдруг?
У нас разные.
В одной моей реализации они 3-х видов с разной периодичностью:
- капитальная копия (должна включать в себя ВСЕ компоненты БД) - делается долго
- средняя (объем зависит от последней капитальной) - делается быстрей
- оперативная (объем зависит от последней средней) - еще быстрей
И есть описание периодичности этих копий. Можно настроить.
Откатиться полностью можно на любую из копий по ее дате.
Но наши руководители проектов еще свое имеют.

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

Цитата:

Веселый разговор, что на свете есть любовь

Песня народная


Исправлено 3 раз(а). Последнее : Ydin, 02.01.18 21:51

Igor Korolyov
Впрочем, каждый сам себе злобный буратино - пишет как умеет, и чужим опытом пренебрегает

Эх если бы себе... добрым людям,
которые его программой пользуются делает добро.;)

Каждый делает не так как надо а как умеет.

Ydin
И, если вдруг, сказали надо добавлять таблицы на новый период...

И это хорошо а ведь могли бы сказать добавляй новую программу на новый период...;)