Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Давайте подымем вопрос о.... !!!!
|
|||
|---|---|---|---|
|
#18+
Привет всем!!! буду рад услышать все предложения и пожелания... дело обстоит в следующем: есть база на сервере, и приложение на фоксе, т.е. работают 5-8 пользователей ... почему иногда, а точнее хотя бы 1-2 раза в месяц база рушится, это явление в фоксе очень распространенное и ведет зачастую к не желательным последствиям, а именно , Например работали работали и в конце дня поставили на архив, на следующий день поработали и где то среди дня Ху..кс и пошли ошибки... база запортилась, исправить ошибки уже не удается, так как народу на приеме очень много и никто не желает просто ждать пока пограммист исправит ошибки в базе и из - за этого просто данные предыдущие потерялись.... вот как с этой проблемой бооться... ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 07:32 |
|
||
|
Давайте подымем вопрос о.... !!!!
|
|||
|---|---|---|---|
|
#18+
не понятно, база фокса? хотя лучше иметьь базу SQL, но по фоксу скажу сбои бывают изза разрушения индексов, их нужно переодически делать реиндекс. потом, архив чем делаете? в этот момент база используется? какого рода ошибки? потеря записей или портится сама информация в полях? т.е. тут больше вопросов чем ответов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 08:19 |
|
||
|
Давайте подымем вопрос о.... !!!!
|
|||
|---|---|---|---|
|
#18+
архив делаю обыкновенным WinRar, просто в меню встроенный, в программе, ну и конечно же перед архивом все пользователи отдыхают.. т.е. не работают Ошибки следующего рода, база заполняется аброкадаброй, т.е. вообще леве данные, либо просто наборы например 232342орорордлдлдлшшшшшшшiiiiiiiiiiiifdgvfdvdevgey3424fjhfeufvre что то вреоде этого, просто портится информация... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 08:58 |
|
||
|
Давайте подымем вопрос о.... !!!!
|
|||
|---|---|---|---|
|
#18+
2МихаилВаси Купмть нормальный сервер, а не простой десктоп. Поставить на него серверную операционку, проверить все сетевое железо - карточки, свичи, провода - гдето глюк. Правильно работающая сеть не должна себя так вести. Да и не ведет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 09:10 |
|
||
|
Давайте подымем вопрос о.... !!!!
|
|||
|---|---|---|---|
|
#18+
15 лет с фоксом, ваш случай редкий однако, но, что смотреть: кодовую страницу таблицы (в таблицу вписывается код страницы, его можно обнулить и назначить например 1251), это если вся таблица- абракадабра, обычно происходит при некорректном переходе из дос формата в винд. ну и вирусы... есть нелюбители формата дбф, именно их и портят... больше в голову ничего не приходит... может у вас какая-нибудь защита используется? типа кодирование данных в базе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 09:12 |
|
||
|
Давайте подымем вопрос о.... !!!!
|
|||
|---|---|---|---|
|
#18+
Описанная ошибка может возникнуть в случае сбоя питания (разрыва соединения) в момент внесения изменений в таблицу. Причины - в ненадежности железа или тупости пользователя (нажал на кнопку питания в момент внесения изменения у себя же). Вероятность появления такой ошибки можно существенно снизить за счет стиля программирования. 1) Отказаться от прямого редактирования таблиц. Любое изменение только через буфер (или копии данных - SCATTER\GATHER) 2) Свести к возможному минимуму время блокировки данных. Т.е. отказаться от пессимистической буферизации и ручных блокировок. Только через оптимистическую буферизацию 3) Ни в коем случае не ждать реакции пользователя, если данные заблокированы. Т.е., например, нельзя при открытой транзакции спрашивать пользователя вроде "Продолжить - Отменить?" Т.е. смысл всех этих модификаций свести к возможному минимуму время непосредственной модификации данных. Ведь именно аварийное прерывание этого процесса и может привести к описанной ошибке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 09:41 |
|
||
|
Давайте подымем вопрос о.... !!!!
|
|||
|---|---|---|---|
|
#18+
Полностью поддерживаю вышесказанное. VFP тут не причем. У моих клиентов многие программы работают по 10 лет 24*7*365 - без проблем... В вашем конкретном случае наиболее вероятно: - полохой контакт в сетевом соединении - бракованная сетевая карта (или очень дешевая с обрезанной длиной пакета, без повторного запроса пакетов и CRC контроля и т.п.) - плохая оперативная память на сервере или одной из рабочих станций... Да и вообще, купили бы нормальный сервер - ушла бы куча проблем. А SQL Server тут не поможет с плохим harwre (стоит только зайти в форум SQL - "Помогите, упала база!" (на пол вместе с сервером :)) Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 10:49 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=32616050&tid=1596106]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 344ms |

| 0 / 0 |
