Работа в сети | |
---|---|
Dron2003 Автор Сообщений: 81 Дата регистрации: 14.11.2008 |
Всем привет!
Ребята, опять нужна ваша помощь. В программе "предусмотрена" работа по сети. Комп1 -условно является сервером, комп2- клиентом. На сервере открыта таблица : SET EXCLUSIVE OFF use Comp1 SHARED на клиенте тоже самое. Запускаю эти 2 проги через .ехе файл. Клиент по таймеру в таблицу кидает запись. replace flag_komp with DATETIME( ) unlock Но сервер по своему таймеру из этой таблице эту запись не считывает. Если запускаю серверную программу в среде FoxPro, то она начинает считывать данные только после того, как я открою эту таблицу на просмотр. Помогите понять логику. Что я делаю не так? Спасибо. |
Re: Работа в сети | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Так бывает, на файл-сервере с разных компов пишешь/читаешь, так изменения, сделанные с одного компа, становятся видны другому компу не сразу, минут через 5 бывает, иногда приходится выйти зайти в прогу (переоткрыть таблицу). FLUSH ничего не меняет. Это ОС виновата, и фокс
|
Re: Работа в сети | |
---|---|
Dron2003 Автор Сообщений: 81 Дата регистрации: 14.11.2008 |
А как обойти эту хрень?
Для меня это очень важно. На клиентах ученики отвечают на тесты, а на "сервере" я вижу их результат ответа и актуальность сетевого соединения. И если будут подвисы в несколько минут, то за это время может произойти всё-что угодно. Пока откатываю на одном компе, на нем стоит вин7, а планируется перенос на XP. Исправлено 1 раз(а). Последнее : Dron2003, 17.01.18 11:36 |
Re: Работа в сети | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
Не знаю, в нашей задаче это не слишком критично, поэтому забил, рано или поздно данные прочитаются правильные...
Можно попробовать переоткрывать таблицу, хотя, вроде бы, даже это не дает гарантий наблюдения "истиного" состояния таблицы. Можно написать прослойку (на фоксе же), и пусть все читают/пишут в таблицу через нее, но это геморно. Можно SQL-сервер поставить, и БД держать в ней, но теряется прелесть фокса+DBF. Можно попробовать открывать таблицу экслюзивно, конкурируя с соседними компами за нее, попользовался (прочитал/записал), и закрыл таблицу... может это превратит таблицу в быстрый "мессенджер" ... |
Re: Работа в сети | |
---|---|
Dron2003 Автор Сообщений: 81 Дата регистрации: 14.11.2008 |
Если не будет других предложений, то , возможно, пойду по такому пути. Вообще то, жаль, что есть такие ограничения у FOXа. |
Re: Работа в сети | |
---|---|
AndyNigmatec Сообщений: 1550 Откуда: Волгоград Дата регистрации: 28.06.2015 |
- никакая прелесть не теряется ))) - совсем даже наеборот |
Re: Работа в сети | |
---|---|
Dron2003 Автор Сообщений: 81 Дата регистрации: 14.11.2008 |
SQL отметается сразу же! Компы в классе старые, еле работают. Не сетевой вариант на них работает на "ура", но мне приходится бегать между рядами и контролировать процесс сдачи. Хотел упростить себе жизнь.
|
Re: Работа в сети | |
---|---|
AndyNigmatec Сообщений: 1550 Откуда: Волгоград Дата регистрации: 28.06.2015 |
смотря какой sql ... я ваще из говна мамонта (целерон древний) типа "сервачек" сооружал - все работат на раз
|
Re: Работа в сети | |
---|---|
Dron2003 Автор Сообщений: 81 Дата регистрации: 14.11.2008 |
Этот сценарий заработал как надо. Спасибо. |
Re: Работа в сети | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Читать/искать в форуме про SET REFRESH (важен 2-й параметр), SYS(1104) и FLUSH (последнее нужно для "записывающей" стороны). По умолчанию фокс не читает одну и ту же запись чаще чем раз в 5 секунд. Кроме того, для собственно чтения "свежих" данных требуется выполнить переход между записями (достаточно GO RECNO() - т.е. переход "на саму себя" - это если данное поле не отображается ни в каких текстбоксах/гридах - иначе можно просто их рефрешить).
Кратко есть тут. Подробное обсуждение в FIDO тут и тут ------------------ WBR, Igor |
Re: Работа в сети | |
---|---|
spinz Сообщений: 5263 Дата регистрации: 21.01.2016 |
фидо в 2к18... о боже
|
Re: Работа в сети | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Сетевая программа на фоксе с dbf-ами. Приближенная к режиму "реального времени". Естественно всё что для этого нужно было описано ещё 20 лет назад. Ссылка на архив тех времён.
------------------ WBR, Igor |
Re: Работа в сети | |
---|---|
Sawradym Сообщений: 2244 Откуда: Винница Дата регистрации: 15.05.2007 |
Никода с подобными проблемами не встречался. До сих пор работает программа на FPD 2.6 в основе которой лежит следующий принцип - RLock() помимо всего прочего заставляет перечитать текущие значения записи с диска, Unlock записывает данные текущуей записи на диск. Думаю что для VFP, в принципе, тоже схема работает, хотя с файл-сервером я уже давненько не игрался. ------------------ |
Re: Работа в сети | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
С блокированием какая-то корреляция есть. Но иногда прога читает записи без блокирования каждой из них, SELECT-ом. Откуда она читает - прямо из сервера (там тоже есть буфер?), или из своего буфера на локальной машине - не в курсе. Бывает такое точно, т.е. одна машина записала, свои изменения она видит, другая машина не видит, полазишь по другим записям (или время пройдет какое-то, не выяснил) - изменения становятся видны. Блокирование спасает ситуацию - т.е. если я хочу изменить запись, то запись блокирую, вроде бы проблем не возникало, что исправляется недоисправленная другим компом запись. Поэтому дальше не копался.
|
Re: Работа в сети | |
---|---|
Sergievsky Сообщений: 133 Дата регистрации: 24.10.2000 |
Какие-то страсти автор рассказывает.
Никогда с таким не сталкивался, наверное потому что всегда LOCK/FLOCK перед записью и дергаю по recno() после записи. Потом UNLOCK. Иногда использую FLASH, но только если затронуто много записей и/или в разных таблицах. C SET REFRESH не игрался никогда. А вообще была такая штуковина у меня
... и конструкция:
|
Re: Работа в сети | |
---|---|
Dron2003 Автор Сообщений: 81 Дата регистрации: 14.11.2008 |
До этого было написано несколько сетевых программ для офиса. Никогда не сталкивался с этими проблемами, в большинстве хватало стандартных средств и только если кто-то блокирует таблицу при добавлении записи и происходил сбой компа, только тогда вводил доп. блокировки. А здесь получилось очень странное: клиент работает, вносит данные. Сервер их не видит. Открываю фокс, смотрю в реальном времени - клиент вносит данные, сервер не видит. Открываю сервер в фоксе не видит, а стоит открыть эту же таблицу на просмотр в фоксе, сервер начинает работать. Пока решил эту проблему переоткрытием этой таблицы.
|
Re: Работа в сети | |
---|---|
ssa Сообщений: 12999 Откуда: Москва Дата регистрации: 23.03.2005 |
В фоксе нет понятия "сервер". И отому он не может в принципе ничего "видеть". ------------------ Лень - это неосознанная мудрость. |
Re: Работа в сети | |
---|---|
Dron2003 Автор Сообщений: 81 Дата регистрации: 14.11.2008 |
Ну, я так, образно. |
Re: Работа в сети | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Это всё относится исключительно к "пишушей" стороне. Для "читающих" запись экземпляров программы это не применимо. Им как раз нужно задать правильный SET REFRESH, дёргать указатель записи по GO RECNO() (если мы просто стоим всё время на одной и той же записи, и хотим увидеть "свежачок"), ну и плюс к тому есть небольшой нюанс (я бы сказал что это баг фокса) для SELECT-SQL выполняющихся в приватных датасессиях, если та же самая исходная таблица уже была открыта в "соседней" датасессии (про что и была тема в FIDO в соответствующее время). В 99% случаев можно обойтись безо всяких настроек и телодвижений, т.к. НЕ КРИТИЧНО увидеть данные с небольшой задержкой, да и происходить это (получение "устаревших" данных) будет лишь в некоторых особых случаях. А что, SET REPROCESS в FPD разве не было? В принципе для большинства случаев не требуется ручное управление блокировками для записи данных - фокс и сам всё сделает. Достаточно настроить SET REPROCESS и прописать обработку ошибок (если всё же заблокировать объект не удалось за отведённое время, или при "бесконечном" ожидании пользователь его прервал по esc). "Вручную" имеет смысл блокировать целиком таблицу, если потом будет производится множество отдельных операций модификации данных, или же для избежания взаимоблокировок (тупиков aka deadlock) при использовании транзакций и изменении нескольких связанных таблиц в рамках этой самой транзакции. Т.к. в FPD в принципе транзакций не было, то там как раз явный FLOCK() нескольких таблиц позволял обеспечить хотя-бы минимальную "согласованность данных" для группы связанных операций... Фокс никогда не блокирует записи при чтении - хоть SELECT-ом в курсор, хоть обычным обращением к alias.field Да, используется целая система буферов (или кэшей) - при том достаточно чётко разделяются сторона пишушая данные в файл и читающая их оттуда. Для первой "пропихиванием" данных до файла через всю систему кэшей (фокс - ОС_клиента - сеть - сервер_с_файлами - кэш_контроллера_и_HDD - постоянное_физическое_хранение) управляют как раз UNLOCK/закрытие таблицы и FLUSH. Для второй (соответственно кэши в цепочке постоянное_физическое_хранение - кэш_контроллера_и_HDD - сервер_с_файлами - сеть - ОС_клиента - фокс) управляют прохождением данных (уже в плане "чтения") SET REFRESH, SYS(1104) ну и отчасти GO RECNO(). При этом, к сожалению, "принудить" всю систему таки дойти до физического файла фокс не может (даже для записи FLIUSH FORCE просто "просит" ОС пропихнуть данные до диска - как оно там уже на самом деле произойдёт - не всегда понятно) - но обычно ОС настроены вполне адекватно, и совсем уж "старьё" не будут держать в этой системе кэшей. ------------------ WBR, Igor |
Re: Работа в сети | |
---|---|
of63 Сообщений: 25161 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
> Фокс никогда не блокирует записи при чтении - хоть SELECT-ом в курсор, хоть обычным обращением к alias.field
Само собой, че ему блокировать без команды. Естественно речь идет о насильном RLOCK перед чтением, и тогда чтение этой записи оказывается правильным, вот о чем воспомнинания, начиная с FPD. Кто там и когда внутри ОС пропихивает - тоже понятно, что ничего не понятно. Эксперименты с FLUSH, SYS(1104), SET REFR ни к чему не привели (ситуация редкая, эксперименты далеко не всегда ее воспроизводят, опять же может не подобраны начальные условия, хз)... Мтк проблема где-то на стороне локальной машины, ее ОС она не хочет лишний раз лезть на файл-сервер, но блокировка RLOCK() мгновенно работает! Вот эта блокировка, может, и заставляет ОС насильно слазить на файл-сервер |
© 2000-2024 Fox Club  |