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

Получив такую ошибку я в последнюю очередь буду думать о системщиках, а в первую - о своей ошибке.
(а ошибка будет не про "писать в несуществующее поле", а про несуществующую переменную).

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



Исправлено 1 раз(а). Последнее : akvvohinc, 17.12.20 16:41

Цитата:

Серег, при всем уважении к тебе - нет.

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

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

Это еще что - у меня до сих пор нет понимания самой проблемы:

boba
проблема в том,
что файл , который перекрывал
copy to
или index
или total
при не первой попытке никогда открыт не был.
-----------------
Все такие исполняемые модули имели по умолчанию
рабочие папки на локальных дисках,
хотя источником были сетевые данные.
Естественно, как принято в бухгалтерии,
все пересчитывалось по нескольку раз

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

Я теперь тоже буду так делать - надо только выяснить, с какого пересчета будут получаться правильные данные - а уж тогда давить на системщиков и сносить антивир.



Исправлено 1 раз(а). Последнее : akvvohinc, 17.12.20 18:07

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

Если есть подозрение на сеть - проверить локально.
Если подозреваем железо (память в первую очередь) - сменить комп.
Антивирус? Временно отключаем.

Обычно по самим сообщениям примерно понятно, железная это ошибка или программная, то есть с чего начинать тестирование.



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

Имеется в виду вот, что
Вот есть какая-то конкретная форма,
где есть кнопочка для вызова процедуры
неких бухгалтерских расчетов
Ну, допустим расчет баланса.
Сосчитали утром. Не понравилось.
Добавили проводок, снова рассчитали итд.
Это самое обычное дело.
При пересчете есть в рабочей паке всякий мусор
после прошлых расчетов, это куда писались файлы
после total, copy to
Эти файлы на локальном диске расчетчика
в рабочей папке. А сами данные были на сети.
И так за день может быть 2-3 -4 пересчета.
Проектов с такими приемами - штук 6.
И ошибки описанного типа появились абсолютно
одновременно во всех них. Операторы,
когда появились, одни и те же.
Я их описал.
Есть всего две ситуации . Не было файла ( первый расчет)б и файл был
Смотрим всего одну команду copy to mysample
Обычно, если папка локальная, исполняй команду хоть сто раз,
она сама накроет старый файл новым.
И теперь вдруг эта команда начинает давать ошибки
описанного типа. Причем , текст ошибки может быть разным
Моя самая первая правка была чистить мусор при входе в форму с расчетами.
Это помогло, но частично.
Бухи иногда между расчетами ухитряются и не выходить из формы.
Не понравился баланс, открывают другой проект, там правят, удаляют,
добавляют проводки. Минимизируют его, открывают форму баланса, которая и не была открыта.
Снова считают.
Я сам никакими total , copy to никогда не пользуюсь
Эти проекты не упали.
Нужно сказать, речь идет о нескольких десятках мест
в нескольких проектах, которые стали валится. И писал их не один человек.
Понятно, что это тоже не особый аргумент, часто народ работает типа клипборда,
игнорируя ООП. То есть, сели была ошибка, могли и растиражировать.
Но тут и искать нечего.
copy to , total либо работает без ошибок,
либо дает ошибку.
Единственным обстоятельством для этого мог бы быть
не закрытый алиас той таблицы куда пишут описанные операторы
при следующем их применении. Но это не было причиной.
Я совсем не новичок, как говорят, собаку съел.
От своих ошибок не застрахован. Но , дело тут совсем другое
Ситуация с наличием ошибки программы, если бы она имела место,
давно бы уже была поймана и исправлена.

akvvohinc

Цитата:

Серег, при всем уважении к тебе - нет.

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

У нас - системщики. Не завидуй, и так тошно. Поверь, я из говна почти конфеты делаю.

Цитата:

Сосчитали утром. Не понравилось.
Добавили проводок, снова рассчитали итд.

Куда рассчитали? В локале - и потом перенесли? Или сразу по всей базе? К нас коллега тоже СЧИТАЕТ, но там приседания. Я не знаю схемы.

boba
Есть всего две ситуации. Не было файла (первый расчет) и файл был

Как я понимаю в первом случае всегда всё работает, а во втором - периодически ломается. Так?

boba
Единственным обстоятельством для этого мог бы быть не закрытый алиас той таблицы куда пишут описанные операторы при следующем их применении.

Не обязательно "не закрытый алиас" - это вполне может быть занятость файла внешним процессом. Т.к. вообще-то есть разница между созданием файла с нуля и записью в него данных, и ПЕРЕзаписью ранее существующего файла.
И да - первейшие подозреваемые тут это антивирусы, ну и иной системный софт, который может в фоне работать с файлами.

akvvohinc

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

Получив такую ошибку я в последнюю очередь буду думать о системщиках, а в первую - о своей ошибке.
(а ошибка будет не про "писать в несуществующее поле", а про несуществующую переменную).

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

Согласен. Ты был убедителен. Я перепроверю кодес. И да, как и ты говорю всегда - не фокс виноват, а кривык ручки. Проверю, может и найду "жучка". К тебе без обид, все норм.

Но про системщиков У НАС - все именно так. Слезы. Я бы Серегу Сизова взял... Но вряд ли ему интересно по деньгам, по региону и вообще.. И я не могу позвать. Увы.

Да, Игорь,
все так и есть.
Но это самое иногда стало настолько часто ( почти всегда так стало),
что просто стало невозможно работать с этим
Что не дает покоя, так это то,
почему добавление delete file
не привело на нем к точно таким же
ошибкам.
Допустим, это действительно антивирус
Вот проверяет он какой-то файл,
а мы его в это время стираем,
почему тут не появляется ошибка.
Повторюсь,
речь идет о файлах, которые появляются на
локальном диске пользователя.
Программу невозможно запустить второй раз,
если она запущена.
Поэтому непонятно, с чем идет конкуренция.

boba
Да, Игорь,
все так и есть.
Но это самое иногда стало настолько часто ( почти всегда так стало),
что просто стало невозможно работать с этим
Что не дает покоя, так это то,
почему добавление delete file
не привело на нем к точно таким же
ошибкам.
Допустим, это действительно антивирус
Вот проверяет он какой-то файл,
а мы его в это время стираем,
почему тут не появляется ошибка.
Повторюсь,
речь идет о файлах, которые появляются на
локальном диске пользователя.
Программу невозможно запустить второй раз,
если она запущена.
Поэтому непонятно, с чем идет конкуренция.

может там exclusive блокировка - может в конфиге не прописано.

можно код глянуть или config?



Исправлено 2 раз(а). Последнее : alex;, 18.12.20 10:58

это все с удаленки достать невозможно
config без exclusive ,

иначе была бы проблема совместного доступа к сетевым файлам.
То есть идея там такая-источник данных
на сети, а промежуточные мусорные файлы в рабочей директории
на локальном диске пользователя.
Код для меня местами мало читаемый,
древне фоксовые конструкции
Но ничего такого, в чем бы было
невозможно разобраться
Вот есть один файл с типа проводками это сделали copy to ,
подбиваем промежуточные итоги total ( образовался еще один файл)
открываем оба и сливаем.
Так вот, и на copy и на total стали вылетать ошибки
До этого никто этих проектов не трогал, авторы или на пенсии или в мире ином.
Перед copy и total проверка на открытие файлов, куда идет запись
Если открыты, закрываем. Самое смешное, в дебагере ошибки не появляются

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

Утилиты Русиновича? ;)

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

кста, думаю, современный Windows PowerShell
позволяет писать афигенные проги по администрированию.
В телеге есть группа там можно задать вопросы.

А административные вопросы - разделение доступа, очередь,
тут думаю, другая тема.

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

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

Почему не попробовали исключить влияние сети, запустив все локально? А если пробовали, то каков результат?

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



Исправлено 1 раз(а). Последнее : akvvohinc, 18.12.20 16:43

Да, проблема появилась практически у всех пользователей,
которые работают с проектами, где есть
приемы total, copy to итд
Конечно, на своем локальном компе я проверял.
Картина та же. В дебагере все супер, в исполняемом модуле-ошибки
У всех этих проектов свои рабочие локальные папки.

Я не так давно столкнулся с такой проблемой. Почему-то перестала работать функция Adir(), когда идёт проверка на существование конкретного файла на сетевом диске. То есть работало, работало, а потом вдруг перестало. Причём adir() вообще ничего не возвращала. При этом другие "точно такие же" по сути dbf-таблицы были видны для ADIR(). А вот конкретный файл, который таки на самом деле был на сетевом диске, стал невидимым. Но, в отличие от остальных файлов, этот конкретный файл создавался по Fcreate(), в него записывалось несколько байт, после чего файл закрывался по Fclose(). Проблема появилась после очередного обновления Win10. В общем, мне удалось это обнаружить, и я решил проблему так - стал создавать файл не на сетевом диске, а в рабочей папке приложения. Админ к моим претензиям отнёсся "холодно", и пришлось идти обходным путем, тем более что файл создавался всего в одном месте, и переделки кода были минимальны.

Быть может, здесь тоже происходит нечто подобное с файлом, в который "только что" писали данные?