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

Не важно у кого свет вырубят! А если у клиента? s.e.r.g.e.y. промолчал на мой вопрос, так мождет Вы мне приведете ссылку на документации об архитектуре "транзакций" фокспро?

IMHO оба неправы....
s.e.r.g.e.y. промолчал = видимо есть на это причины...
К сожалению ссылку на документации
об архитектуре "транзакций" фокспро я привести не могу... ибо, либо
то, что я приведу ниже есть незадокументированно, либо...
ну не знаю... не читал я подобного...

итак вот механизм... код НЕ МОЙ, код почерпнут на этом форуме,
но тестировал я его СПЕЦИАЛЬНО из-за недоверчивых высказываний
о том, что фокс дескать дерьмо.. и базы его падают...
итак:
В моем, живом кстати, примере, идет работа с накладной, а именно
вставка данных, или модификация оных в 2-х таблицах, буфферизация
которыз установлена в 5
1 - накладная
2 - товары в накладной

INSERT INTO Nakladni (cNakladniNum, nType, ;
nClientId, dDate, cDovNum, cDovSer, dDovDate) ;
VALUES (cNumOfNakl, 1, nClientForNakl, dDateOfNakl, ;
cDovNum2, cDovSer2, dDovDate2)

INSERT INTO GoodInNak (cIdNakl, cIdGood, nPrice, nQuantity, ;
nTax, nSumAndTax, nSumma) ;
VALUES (TNakId.NextId, GInNakTmp.nTmpGoodId, GInNakTmp.nTmpGPrice, GInNakTmp.nTmpGQuant, ;
GInNakTmp.nTmpGTax, GInNakTmp.nTmpSumP, GInNakTmp.nTmpNaSum)

(вместо INSERT естественно может быть и UPDATE)
затем идет собственно транзакция

BEGIN TRANSACTION

**************
* *
* точка № 1 *
* *
**************

* Сброс буфера первой таблицы
IF m.llSuccess = .T.
llSuccess = TableUpdate(.T.,m.llIsOtherWrite,'Nakladni')
ENDIF

**************
* *
* точка № 2 *
* *
**************

* Сброс буфера второй таблицы
IF m.llSuccess = .T.
llSuccess = TableUpdate(.T.,m.llIsOtherWrite,'GoodInNak')
ENDIF

IF m.llSuccess = .F.

**************
* *
* точка № 3 *
* *
**************

* прекращаем транзакцию
ROLLBACK
* анализ причины неудачи
LOCAL laError(1)
=AERROR(laError)
IF m.laError = 1585
= MESSAGEBOX("Пока данный пользователь редактировал другой внес изменения",48, "")
ELSE
* Анализ кода ошибки и, возможно, повтор попытки изменений
* Если решили повторить попытку сохранения НИЧЕГО НЕ МЕНЯЯ
llReSave = .T.
ENDIF
ELSE

**************
* *
* точка № 4 *
* *
**************
END TRANSACTION
ENDIF

итак, в тех местах, которые я пометил как "точка № 1,2,3,4"
я искусственно затормаживал действие программы и....
1 - в случае база данных находится на сервере, а сама программа
на клиентской машине - я ГРУБО выдергивал сетевой шнур (не
электрический, а сетевой), что ДОЛЖНО было очевидно привести
в крэшу таблиц, ведь доступ к ним физически исчезал....
2 - дома (нету ж сети) я, нет, не вырубал свет (жаль так издеваться
над компом). Я просто по CTRL-ALT-Del снимал задачу в этих точках

Каков результат?
Ни в одном из случаев НИКАКИХ проблем не наблюдалось....
опыт сей я провел, ну примерно 5-6 раз...
ВСЕГДА транзакция откатывалась, и... записи попросту не были модифицированны
(или вставлены)

То есть сделал вывод: "отключили свет у файл-сервера - ничего страшного,
если ФС написан с умом...."

Конечно каюсь - попробовав работать в связке VFP + Oracle
модификацию данных провожу посредством Оракловых Stored Procedure
все, что я привел выше оказалось ненужным....
Ну, либо Оракл сам откатывает транзакцию в случае неудачи.. либо
я чего-то попросту не понимаю
VFP + Oracle нравится НАМНОГО больше, но увы.. не каждый клиент способен
купить себе Оракл... посему приходится работать и с
VFP + DBC(DBF)
Ну можно конечно и там заюзать Stored Procedure, пробовал как-то на
досуге - работают они и там...

вот так..
надеюсь мой ответ исчерпывающий?

pkarklin FM32YO aka KIDвот так..
надеюсь мой ответ исчерпывающий?

Более чем! :) Но он не раскрывает сути проблемы файл-серверной СУБД. Точнее сказать, Вы совсем не то тестировали! То, что пока Вы не сказали END TRANSACTION фокс тем или иным образом "буфферизирует" изменения понятно. Но самое интересное не здесь.


ну я тестировал от нападок - дескать "упадет..."
Лога транзакций в фоксе я полагаю нету.. это же не сервер, хотя в 9-ке может и есть не в курсе...
pkarklin[
Вернемся к примеру с апдэйтом 500 000 записей. Пусть фокс забуффирезировал все изменени и вы сказали END TRANSACTION.
.............

ну в этом случае конечно.. самое, что приходит в голову = ВИЛЫ базе.. но....
если честно я не мыслю видать такими масштабами.. я не понимаю КАК это апдейт сразу таким количеством???
Я такого никогда не делал... в моем понимании, один клиент в определенный момент делает 1 изменение в 1-2-3-5-ти таблицах.. но никак не в 500 000 одновременно..
впрочем, раз Вы о таком говорите - такие задачи имеют место, и, что греха таить файл-серверу они не по зубам..... ИМХО тогда берем тот же фокс + Оракл и дерзаем... хотя, думаю, что если сервак оракла в такой момент отрубится, я, как разработчик но не админ - ничего тут не подулаю :)


Согласитесь, чтобы применить такой буффер к файлу на диске нужно довольно-таки длительное время. Меня интересовал что будет, если аппаратный сбой произойдет в интервал времени между началом и концом файловой операции применения изменений из буффера? Особенно интересно, что будет, если после такого сбоя, к файлам бд первым подключиться клиент отличный от того, что применял изменения? В каком состоянии будет бд? Именно по этому я просил привести ссылки на документацию об архитектуре "лога" фокса.

Ибо, в моем понимании, реализация процесса восстановления бд после таких сбоев невозможна без централизованного ядра бд и соответствующей архитектуры ведения лога и его применения к бд.

Что происходит, например, у MS SQL сервер:

A SQL Server 2000 checkpoint performs these processes in the current database:

1.Writes to the log file a record marking the start of the checkpoint.
2.Stores information recorded for the checkpoint in a chain of checkpoint log records. The LSN of the start of this chain is written to the database boot page.
3.One piece of information recorded in the checkpoint records is the LSN of the first log image that must be present for a successful database-wide rollback. This LSN is called the Minimum Recovery LSN (MinLSN) and is the minimum of:
3.1 The LSN of the start of the checkpoint.
3.2 The LSN of the start of the oldest active transaction.
3.3 The LSN of the start of the oldest replication transaction that has not yet replicated to all subscribers.
4.Another piece of information recorded in the checkpoint records is a list of all outstanding, active transactions.
5.Deletes all log records before the new MinLSN, if the database is using the simple recovery model.
6.Writes to disk all dirty log and data pages.
7.Writes to the log file a record marking the end of the checkpoint.

Вот меня как раз и интересовало, что будет с бд, если сбой произойдет между 6 и 7?

У MS SQL за эти операции отвечает одно централизованное ядро, а что у фокса?[/quot]

pkarklin FM32YO aka KIDвот так..
надеюсь мой ответ исчерпывающий?

Более чем! :) Но он не раскрывает сути проблемы файл-серверной СУБД. Точнее сказать, Вы совсем не то тестировали! То, что пока Вы не сказали END TRANSACTION фокс тем или иным образом "буфферизирует" изменения понятно. Но самое интересное не здесь.


ну я тестировал от нападок - дескать "упадет..."
Лога транзакций в фоксе я полагаю нету.. это же не сервер, хотя в 9-ке может и есть не в курсе...
pkarklin[
Вернемся к примеру с апдэйтом 500 000 записей. Пусть фокс забуффирезировал все изменени и вы сказали END TRANSACTION.
.............

ну в этом случае конечно.. самое, что приходит в голову = ВИЛЫ базе.. но....
если честно я не мыслю видать такими масштабами.. я не понимаю КАК это апдейт сразу таким количеством???
Я такого никогда не делал... в моем понимании, один клиент в определенный момент делает 1 изменение в 1-2-3-5-ти таблицах.. но никак не в 500 000 одновременно..
впрочем, раз Вы о таком говорите - такие задачи имеют место, и, что греха таить файл-серверу они не по зубам..... ИМХО тогда берем тот же фокс + Оракл и дерзаем... хотя, думаю, что если сервак оракла в такой момент отрубится, я, как разработчик но не админ - ничего тут не поделаю :)

Gluk (Kazan) FM32YO aka KIDно....
если честно я не мыслю видать такими масштабами.. я не понимаю КАК это апдейт сразу таким количеством???
Я такого никогда не делал...

заметно

смысл сказанного тобой, я что-то не пойму :)
хочешь уколоть?? но на куя???
мне необоснованное мнение собственно сам знаешь где :)
Я понимиаю ты написал в одиночку биллинг для общереспубликанских операторов мобильной связи.. или нечто подобное.. ну и что???
Много денег? медаль? флаг?
Шютка...

tygra
Хоть и 10 записей - вдруг посередине операции записи информации в файл сбой в сети - и все, кирдык.

-- Tygra's --

ну дык ясен пень - СВЕТ мигать на сервере НЕ ИМЕЕТ права!!!! :) ведь так?

с другой стороны, я что-то не пойму...
BEGIN TRANSACTION

**************
* *
* точка № 1 *
* *
**************

* Сброс буфера первой таблицы
IF m.llSuccess = .T.
llSuccess = TableUpdate(.T.,m.llIsOtherWrite,'Nakladni')
ENDIF

**************
* вот тута вырубили свет - сеть пропала
**************

* Сброс буфера второй таблицы
IF m.llSuccess = .T.
llSuccess = TableUpdate(.T.,m.llIsOtherWrite,'GoodInNak')
ENDIF
.......

**************
* или здесь
**************

* Сброс буфера 10-й таблицы

разве это не проверка того, о чем ты спросил в своем посте?
Хотя конечно, я не спорю - нет ничего сверхнадежного.... вероятность, что база таки сдохнет не исключена.. просто в моем опыте не сдохла.... я только об этом тут говорил (ни слова о супернадежности фокса как файл-сервера)
как я сказал ВФП + Оракл понравилось БОЛЬШЕ...

tygra
Хоть и 10 записей - вдруг посередине операции записи информации в файл сбой в сети - и все, кирдык.

-- Tygra's --

tygra сорри!!!! мой ответ выше не о том... конечно если сбой в момент физической записи в файл, а не транзакции.. то будет ХЗ что..
но, почему-то мне кажется, что в подобном случае НИКТО не знает наверняка, что быдет с тем же Ораклом... ведь читать книги это одно, надо ж еще поэкспериментировать......

pkarklin FM32YO aka KIDно, почему-то мне кажется, что в подобном случае НИКТО не знает наверняка, что быдет с тем же Ораклом... ведь читать книги это одно, надо ж еще поэкспериментировать......

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

ну дык так и должно быть в любом ИМХО сервере БД.....
вот думаю как бы попробовать, так как ты советуешь поиздеваться на фоксом.. ради интереса...
но как поймать тот момент... момент именно физической записи в файл...
то есть пока момент не пойман утверждать ничего и нельзя.. только предполагать