Пришлось тут править старые чужие программы,
которые годами исправно работали,
и вдруг стали выдавать кучу ошибок
Фирменными приемами там были
copy to
total
create vtable
Все такие исполняемые модули имели по умолчанию
рабочие папки на локальных дисках,
хотя источником были сетевые данные
Естественно, как принято в бухгалтерии,
все пересчитывалось по нескольку раз
Так вот, сутью правок стало удаление файлов,
если они были, куда пишут операторы
copy to, total итд
Причем, кроме ошибок, программы еще и сильно замедлили свою работу
Ошибки типа файл занят другим пользователем и другие были как раз
на упомянутых операторах
Все исправили в нескольких проектах
Ошибки ушли. Остается вопрос.
Что такое могли сделать и чем

Антивирус?

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

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

Цитата:

то логично предположить внешнее влияние

Закладки в ПО тоже к ним относятся.

Владимир
Или я плохо объяснил или вы не правы
Вот пример
Можем его сколько угодно раз запускать,
в set step on не попадет
А в том случае, как я описал
как раз валилось с ошибкой и на создании индекса
и на copy to
Избавление от ошибки как раз и состояло в том, чтобы до
создания индекса и команды copy стирать файлы
Например, delete file tmr.dbf
delete file tmr.cdx

Ниже пример, который работает и без таких строк,
но это у меня, не на работе в тех проектах, что пришлось ремонтировать

Set Safety Off
Create Cursor tmr (aa c(2))
Insert Into tmr Values ('ab')
TRY
INDEX on aa TAG aa
Copy To tmr
Catch To loexp
Set Step On
Endtry

Я тоже иногда бываю уверен, что знаю, что делает та или иная настройка. Но неожиданно оказывается, что настройка делает не совсем то, о чем я думал ;)

SET SAFETY

Цитата:

Определяет, выводит ли система Visual FoxPro диалоговый бокс, содержащий варианты подтверждения пользователем следующих действий

Перевод неудачный, в оригинале более понятно

Цитата:

Determines whether Visual FoxPro displays a dialog box before overwriting an existing file

Т.е. эта настройка всего-лишь определяет, а будем что-то спрашивать у пользователя или нет? Соответственно, если OFF, то работаем ничего не спрашивая. Но! Эта настройка никак, никоим образом, не предотвращает (не подавляет) какие-либо ошибки. Это просто ответ на вопрос: уточним у пользователя или действуем по умолчанию?

Ага, а "не спрашивая" (по умолчанию) - это какое действие означает? Ну, наверное, все-таки перезапись существующего файла. Если файл занят другим процессом, то, очевидно, будет ошибка. И совершенно не имеет значения, будет предварительно диалог с пользователем или нет

Для проверки, я бы сделал настройку SET SAFETY ON и потом соглашался бы с предложениями о замене файла. Подозреваю, что это ничего не изменило бы. Те же ошибки остались бы

boba
Или я плохо объяснил или вы не правы

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

проблема в том,
что файл , который перекрывал
copy to
или index
или total
при не первой попытке никогда открыт не был
И именно на этих командах
появлялись ошибки
Причем, не всегда одни и те же
Например, файл занят другим пользователем
доступ к файлу запрещен. файл уже существует и еще несколько других сообщений
Такое могло бы быть, если рабочая папка не была локальная,
а сетевая, и работали в одном режиме одновременно
несколько пользователей.
Сам прием написания именно этих команд не ко мне,
а к древнеримским авторам.
Причем, все эти программы проработали исправно несколько лет,
и вдруг, бамц, повалилась куча ошибок
Я один проект переписывал днйе 10

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

Может, железные проблемы, или антивиря (уже упоминали).
Проверить проблемный файл (который не удаляется) удалить руками, т.е. проводником.
Проверить, не автономный" ли этот файл (страшная зараза в винде, и фик поймешь, что файл автономный)
Скопировать все это на другой комп, как там будет работать.
Вынести удаляемые файлы в сеть
...

так правка в том и состояла,
перед каждым проблемным оператором
поставить delete file
Поскольку в проекте есть обработчик ошибок,
то он бы тогда должен словить ошибку
на этом операторе, если он раньше ловил
ее на copy to итд
Однако, лечение с помощью кучи
delete file помогло, ошибок не стало
эти операторы ошибок не дали, а по логике должны бы дать
прежние ошибки но уже на этом операторе.
Задача решена, но понимания причbн проблемы нет

boba
так правка в том и состояла,
перед каждым проблемным оператором
поставить delete file
Поскольку в проекте есть обработчик ошибок,
то он бы тогда должен словить ошибку
на этом операторе, если он раньше ловил
ее на copy to итд
Однако, лечение с помощью кучи
delete file помогло, ошибок не стало
эти операторы ошибок не дали, а по логике должны бы дать
прежние ошибки но уже на этом операторе.
Задача решена, но понимания причbн проблемы нет

Володя, да мы так же решаем проблемы. От наших системщиков - только название, ничего не решают - самый популярный ответ "это ошибка в программе". Хотя НЕОДНОКРАТНО валилась сеть, глючили порты роутера, были битые HDD и пр.

Вот тоже пример приведу. Работает вполне стабильно модуль формирования DBF-файла - берется некий прототип и дополняется на лету полями. Они потом заполняются. На REPLACE - выскочила ошибка. До этого ВСЕГДА стабильно работало. Пожал плечами, дописал в-какой-области-заменить на всякий случай, пересобрал проект, запустил - все работает. До этого, разумеется, проверил, что репласе - в нужной области (в нее селектом перешли!).

И да. по возможности стараюсь забрать с сервера и обработать локально. Жизнь показывает, что так проблем меньше.

boba
Задача решена, но понимания причbн проблемы нет

Если система не ХР, а Win7 или тем паче 10 - очень высока вероятность работы ОС в качестве "умной лошади". Ограничивая например везде где можно и где нельзя права программ. Аналогично могут себя вести и антивирусы - сегодня это те же самые "умные лошади".
Напомню старый анекдот, для понимания использованного "термина":

sphinx
самый популярный ответ "это ошибка в программе"

Так потому что это и есть самая вероятная причина ошибки.

sphinx
На REPLACE - выскочила ошибка. До этого ВСЕГДА стабильно работало.

У ошибки наверно был и текст, и номер, по которым автор обычно и "догадывается" о возможных причинах.
В этой теме я пока кроме "куча ошибок" так ничего конкретного и не увидел.

sphinx
Пожал плечами, дописал в-какой-области-заменить на всякий случай, пересобрал проект, запустил - все работает.
До этого, разумеется, проверил, что репласе - в нужной области (в нее селектом перешли!).

Без знания номера (текста) ошибки эти действия выглядят как шаманство или попыткой попасть пальцем в небо.
Обычно всё же действия по устранению ошибки зависят от ее причины, а в твоем описании такой связи я не увидел.
Поэтому твой пример мне остался непонятен - при чем здесь были ваши системщики?

(а рабочая область легко может и "потеряться", если за гридом не следить)

Абсолютно так же описывает и решает проблему и Володя:

boba
как раз валилось с ошибкой и на создании индекса
и на copy to
Избавление от ошибки как раз и состояло в том, чтобы до
создания индекса и команды copy стирать файлы

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



Исправлено 2 раз(а). Последнее : akvvohinc, 17.12.20 14:12

Crispy

boba
Задача решена, но понимания причbн проблемы нет

Если система не ХР, а Win7 или тем паче 10 - очень высока вероятность работы ОС в качестве "умной лошади". Ограничивая например везде где можно и где нельзя права программ. Аналогично могут себя вести и антивирусы - сегодня это те же самые "умные лошади".

Понятно, кобыла виновата.

-Неужели "стирать файлы" или "дописать в-какой-области-заменить" - два универсальных способа исправления любых ошибок?
Не замечал такого раньше, но теперь попробую.-
нет конечно
Просто идет речь о конкретных приемах программирования,
которых в указанных проектах было море
Я даже и не слышал про оператор total
, а тут это любимый прием.
Ошибки были совершенно конкретные
Нет доступа к файлу, файл занят, файл только для чтения, отказано в доступе
Естественно грешишь именно на ошибку программы.
Пусть и не сам ее писал.
Но тут не так . Проекты работали годами, и стали валиться
месяца два назад
Ну, допустим, была ошибка -файл открыт другим пользователем
То есть алиас при втором запуске был открыт.
Тогда и delete file перед ошибочным оператором
должен дать ошибку, но не давал.
Причем, при повторных проходах
на одном и том же операторе и ошибка
могла быть другой.
Обработчик ошибок все пишет в файл
протокола ошибок. Там все видно.
Тип антивируса не меняли, не знаю, что там его версия,
менялась или нет.

boba
Задача решена, но понимания причbн проблемы нет

Можно предположить, что механизмы в обоих случаях разные.
С Delete:
- удаляется старый файл
- создается новый файл
Без Delete:
- где-то создается временный файл
- переименовывается старый файл
- переименовывается временный файл.

Цитата:

sphinx
самый популярный ответ "это ошибка в программе"

Так потому что это и есть самая вероятная причина ошибки.

Серег, при всем уважении к тебе - нет. Я уже пользователям объяснял, что мы, разрабы, не умеем чинить программно мышки и роутеры. Работал бы у нас - язык не повернулся на комментарий. Мы как раз ВСЕ решаем. Да, порой здесь, коллективно. Ну точно же не все.

lulgu

boba
Задача решена, но понимания причbн проблемы нет

Можно предположить, что механизмы в обоих случаях разные.
С Delete:
- удаляется старый файл
- создается новый файл
Без Delete:
- где-то создается временный файл
- переименовывается старый файл
- переименовывается временный файл.

Да. Но очень сомневаюсь, что Журавлев до этого при всем своем опыте не доходит. Да он точно побольше знает. Чем я.

Цитата:

sphinx
На REPLACE - выскочила ошибка. До этого ВСЕГДА стабильно работало.

У ошибки наверно был и текст, и номер, по которым автор обычно и "догадывается" о возможных причинах.
В этой теме я пока кроме "куча ошибок" так ничего конкретного и не увидел.

РАЗУМЕЕТСЯ! Если первести с древне-штатского - не могу писать в несуществующее поле. В отладчик не веришь?

Если сырое - то косяк. Ан нет. Посмотрим. ;)





Исправлено 1 раз(а). Последнее : sphinx, 17.12.20 14:49

sphinx
Поэтому твой пример мне остался непонятен - при чем здесь были ваши системщики?
(а рабочая область легко может и "потеряться", если за гридом не следить)

Серег, ну ты чего? Про системщиков я к слову... А все сохраняю обычно. Есть привычка - перешел в процедуру - сохрани область. Уверен, и ты предохраняешься.

sphinx
А все сохраняю обычно. Есть привычка - перешел в процедуру - сохрани область. Уверен, и ты предохраняешься.

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