Igor Korolyov
Это исторически сложилось - на самом деле в FPD всё было точно так-же.

Igor Korolyov
1) Должен - это его прямая обязанность.
2) Я неправильно выразился - не FLUSH вызывает снятие блокировки, а наоборот - снятие блокировки с записи вызывает её запись на диск (это не совсем FLUSH т.к. записывается только текущая запись). Явно наложенные блокировки FLUSH не трогает, так что повода для беспокойства нету!

Sergey Fadeev
Если я хочу сбросить буфера, то я должен иметь такую возможность без всяких побочных эффектов типа снятия блокировок.

Igor Korolyov
Ты не прав - единственное видимое отличие - SELECT в FPD вызывает перед своим исполнением неявный FLUSH.

Igor Korolyov
Сложно сказать - поведение SELECT SQL было таковым ещё в FPD (происходило чтение с диска, даже мимо файлового кэша фокса) - сделать "по умолчанию" отличающееся поведение в VFP - значит нарушить принцип обратной совместимости. Поэтому и было оставлено старое поведение.

Igor Korolyov
Это не обходные манёвры - насколько я понимаю так работают все среды - пока что-то "набивается" в поле - ни о каком сохранении данных речи не идёт - и лишь при выходе из поля, или нажатии каких-то специальных клавиш происходит "сброс" данных из буфера контрола куда-то дальше...

Владимир Максимов
В FPD не было такого понятия как "буфер таблиц" (точнее, были, но не явные и практически неуправляемые пользователем). Т.е. говорить о какой-то совместимости в этом плане не имеет смысла. Не с чем "совмещать".

Владимир Максимов
Если же в VFP не использовать буфер таблиц, т.е. работать "как в FPD", то совместимость налицо. Все работает также как и в FPD.

Владимир Максимов
Есть на форме TextBox. Ты начинаешь модифицировать его данные. В какой момент, то, что ты внес должно быть сброшено в поле таблицы? После каждого символа? Не думаю. Логично завершить ввод поля целиком и только потом сбросить то, что ввели.

Владимир Максимов
Как определить тот момент, когда ввод данных в TextBox завершен?

Владимир Максимов
Чтобы описать все "подводные камни" и возможные "рабочие ситуации", которые могут возникнуть при определении момента завершения ввода в поле и запись надо написать огромную "простыню". Разработчики FoxPro проделали огромную работу по их обработке. Но всего учесть не смогли. Даже не потому, что не заметили, а потому, что не всегда ситуация однозначна. Т.е. не всегда можно однозначно сказать, что вот он момент завершения ввода. Поэтому "правило хорошего тона" - это дать FoxPro понять, что процесс ввода был завершен. Таким индикатором и является явный переход на другой объект ввода.

Цитата:

Игорь и Владимир, вы согласны, что это действительно простая и понятная концепция? И максимально совместимая по исходному коду с любым кодом, начиная с dBASE II?

Цитата:

И что она должна быть активной по умолчанию?

Цитата:

Поэтому я и не согласен со значением по умолчанию для WITH (BUFFERING=lExp)

Цитата:

Когда я столкнулся с этим, то для меня в первую очередь было удивительно, что SELECT-SQL <fieldname> игнорирует результаты выполнения предшествующей REPLACE <fieldname>. Так не должно быть - по-крайней мере по умолчанию...

Цитата:

если в FPD ты получал один результат, а в VFP точно такими же
командами получаешь СОВЕРШЕННО ДРУГОЙ, то о каком "точно так же" и
"исторически сложилось" может идти речь

Цитата:

Прочитав эти 2 пункта, я не совсем понял

Цитата:

Важно, что результаты - разные...

Цитата:

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

Цитата:

где ты видишь мое недовольство тем, что значение Textbox.Value
проигнорировано? Да мне в данном случае вообще без разницы, записалось оно
или нет

Цитата:

Вопрос касался игнорирования команды REPLACE

Цитата:

в том примере специально были исключены такие действия ... начало и
конец редактирования

Цитата:

команда REPLACE работает с полем, которое вообще никак не
представлено на форме

Цитата:

В FPD было единое адресное пространство ...

Цитата:

игнорирует результаты выполнения предшествующей REPLACE <fieldname>.
Так не должно быть - по-крайней мере по умолчанию...

Владимир Максимов
А от нас то, ты что хочешь? Мы при всем желании не можем изменить этот режим по умолчанию. Так есть. С этим остается только смириться.

Владимир Максимов
Лично меня сильно удивляет такая горячая "привязанность" к команде Select-SQL. Какой глубокий смысл изменить одну (несколько) запись и тут же делать выборку по ВСЕЙ таблице? Лично мне это кажется неправильным. Почему нельзя один раз получить выборку, а потом заниматься только ее модификацией? Тем не менее, так поступают. Вот как в данном примере.

Igor Korolyov
У тебя в FPD был объект Form с вложенным объектом Textbox привязанным к этому полю, да ещё и с выполнением Textbox.Value = '' ? Естественно что нет!
GET поля и READ CYCLE ну никак не могут служить аналогом того что есть у тебя сейчас в VFP. Тогда какие претензии?

Igor Korolyov
У тебя как минимум стартовые условия разные...

Igor Korolyov
Конечно я про "обычную" программу - если у тебя вдруг в реальной программе проводятся подобные действия с невидимой формой и невидимым текстбоксом - то даже не знаю чего и посоветовать...

Igor Korolyov
Не было там этого. Я уже написал как можно проверить работу кэша и SELECT SQL в FPD... И получить именно то что тебя так напрягает - РАЗНЫЙ результат "прямого" обращения к полю, и SELECT SQL.

Igor Korolyov
- У меня кошка вчера сдохла...
- А что ты с ней такого делал?
- Да ничего, как обычно накормил, напоил... А она сдохла, ничего не понимаю...
- Ну а ДО того что ты делал?
- Ну до того я ей хвост отрезал - но какое это имеет значение?

Так что не надо ломать причинно-следственную связь. Проблема не в REPLACE и не в SELECT, и даже не в .Value = '' а в том что ты не понимаешь (пока) всей совокупности данных действий.

Цитата:

У меня вызвало неудомение то, что REPLACE и SELECT-SQL работают в разных адресных пространствах. А эти команды в FPD были (это по поводу разных стартовых условий) и работали в одном адресном пространстве

Цитата:

если указанный код писать не в форме, а в процедуре, то неприятный эффект отсутствует

Цитата:

поведение совершенно одинаковых последовательностей команд REPLACE и SELECT-SQL различается в зависимости от ситуации

SELECT table1
REPLACE str4base WITH '1234'
? str4base

Цитата:

А можешь ты привести пример, когда в FPD делается REPLACE, а после него SELECT-SQL не видит измененных данных, причем в это дело никто не вмешивается

SELECT table1
REPLACE str4base WITH '1234'
SELECT * FROM table1 WHERE !EMPTY(str4base)

Цитата:

Я, прочитав ваши объяснения, высказал свое ОТНОШЕНИЕ к этому эффекту

Цитата:

P.S. Жаль, что в моем сильно упрощенном примере исчезла разница между работой VFP8SP1 и VFP9. Видимо, я где-то что-то упустил

Igor Korolyov
Эти команды работают в FPD и VFP одинаково.

Igor Korolyov
Никаких "адресных пространств" нету.

Igor Korolyov
SELECT (в FPD всегда, в VFP по умолчанию) читает данные с диска, REPLACE же МОЖЕТ помещать их в фоксовый "файловый кэш" - т.е НЕ доводить до диска. Твой пример лишь один из случаев, когда данные НЕ ДОШЛИ.

Igor Korolyov
Другой пример - вызов из BROWSE скажем по ON KEY LABEL - тогда ТОЖЕ данные не успевают дойти до диска - т.е. то что было "набрано" в текущем поле (если из него не выходить конечно!) в SQL запросе не будет видно.

Igor Korolyov
Не замечал такого - если просто перенести кусок кода с REPLACE и SELECT в процедуру и её вызывать из той-же точки, то НИЧЕГО не изменится.

Igor Korolyov
Как по твоему отработает вот этот код:

SELECT table1  
REPLACE str4base WITH '1234'  
? str4base

100% что ты ответишь неправильно, поскольку я не указал что выполнялось ДО этих строк, а не зная этого ответить правильно НЕВОЗМОЖНО.

Igor Korolyov
Почему же ты считаешь возможным в предыдущем примере оторвать команды от контекста (причём НЕВОСПРОИЗВОДИМОГО в FPD контекста!) и заявлять что что-то работает "не так"?

Igor Korolyov
Ты всё ещё не понял в чём суть наблюдаемых результатов, и по прежнему твердишь что "в FPD REPLACE и/или SELECT работал иначе", тогда как это совсем не так.

Igor Korolyov
Для того я и говорил про всякие "житейские правила" - это ЗАМЕТНО упрощает жизнь - т.е. отсекается целый пласт сложных/нестабильных состояний системы, когда трудно сказать к чему приведёт банальнейший REPLACE...

CREATE TABLE T1 (C1 C(10))
APPEND BLANK
USE

lc1 = "Q:\test\"
CLEAR
SET TALK OFF
IF !USED("t1")
 USE (m.lc1 + "t1") SHARED IN 0
ENDIF
DO WHILE LASTKEY() # 27
  REPLACE c1 WITH STR(SECONDS())
  FLUSH
  =INKEY(0.5)
ENDDO

lc1 = "Q:\test\"
CLEAR
SET TALK OFF
* Чтобы не томится, поставим на 2 секунды
SET REFRESH TO 0, 2
IF !USED("t1")
 USE (m.lc1 + "t1") SHARED IN 0
ENDIF
IF !USED("t3")
 USE (m.lc1 + "t1") SHARED IN 0 AGAIN ALIAS t3
ENDIF
DO WHILE LASTKEY() # 27
  GO 1 IN t1
  SELECT *, 33 FROM (m.lc1 + "t1") INTO CURSOR t2
  @ 1,1 SAY t1.c1 + " , " + t2.c1 + " , " + t3.c1
ENDDO

Цитата:

Цитата:

Как по твоему отработает вот этот код:

SELECT table1
REPLACE str4base WITH '1234'
? str4base

100% что ты ответишь неправильно

Покажет 1234

Цитата:

это ПЛОХО!

Цитата:

Для тебя что главнее - конкретный контекст или ясная и удобная общая концепция

Цитата:

Программист будет перед каждой командой проверять сотни предусловий и в конце концов махнет на все рукой

Igor Korolyov
Да уж, неверно поставленный эксперимент приводит к неадекватным выводам

Igor Korolyov
Ну вот видишь, ты практически попался А теперь скажи что будет
1) Если стоим на EOF() или если в таблице НЕТ записей (что равноценно)
2) Если тип поля C(1)
3) Если такого поля вообще нету или оно несовместимого типа
4) Если поле/таблица заблокированы другим пользователем
5) Если прописан триггер, или хитрый Rule меняющий значение поля при вводе
И так долго можно продолжать

Sergey Fadeev
Только, надеюсь, это будет реальный код, а не шутка типа eof('table1')=.t. или read-only table1 и т.п.

Igor Korolyov
Это замечательно! Это так и должно быть! И это не шутка - я лишь хочу показать, что "оторванный" от контекста код никак не может работать "одинаково" везде и всегда!

Igor Korolyov
Давай даже проще - ты считаешь что по команде QUIT ВСЕГДА происходит закрытие приложения? Я же утверждаю что не всегда, и это ПРАВИЛЬНО!

Sergey Fadeev
Для тебя что главнее - конкретный контекст или ясная и удобная общая концепция?

Igor Korolyov
Концепция описана в хелпе - SQL НЕ берёт данные из открытых алиасов, а делает внутри себя нечто типа USE AGAIN.

Igor Korolyov
Возможно она не "ясная" (насчёт удобства спорить не стану - мне удобно так как ЕСТЬ, а не так как оно было-бы, если бы брались данные из какого-то из имеющихся курсоров - с учётом тамошних FILTER/ORDER и т.п.)

Igor Korolyov
Ты же пишешь цельную программу, а не бездумный набор команд! Ты должен знать в каком состоянии может оказаться среда исполнения в каждый конкретный момент - и если тебя это состояние почему-то не устраивает - изменить его!

Цитата:

Посмотри код моего примера и заметь, что команды работают в ОДНОЙ РАБОЧЕЙ ОБЛАСТИ

Цитата:

t1 и t2 изменяются абсолютно так же, как я написал для FPD

Цитата:

В VFP команды ? fieldname и SELECT-SQL могут давать разные результаты даже когда: - эти команды расположены в одной рабочей области

Цитата:

чувствуешь разницу между НОРМАЛЬНОЙ работой команды и ЕЕ РЕАКЦИЕЙ НА СИТУАЦИИ, МЕШАЮЩИЕ нормальной работе?

Цитата:

В моем тестовом примере была хоть одна нестандартная ситуация, мешающая нормальной
работе?

Цитата:

пример не подходит

Цитата:

работа идет в одном адресном пространстве, как в FPD

Цитата:

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

Цитата:

Цитата:

У тебя как минимум стартовые условия разные...

Т.е. поведение совершенно одинаковых последовательностей команд REPLACE и SELECT-SQL различается в зависимости от ситуации

Цитата:

Если он в зависимости от каких-то предусловий покажет что-то другое, то это ПЛОХО!

Цитата:

Надо было подумать и поэкспериментировать. В частности подумать ЗАЧЕМ в примере стоит GO, убрать его, сделать GO в t3 и т.п.

Igor Korolyov
И поменяй термин - "адресное пространство" имеет своё чётко определённое значение. Тут можно применить термин курсор - понимая под ним у совокупность внутренних структур среды исполнения, которые обеспечивают доступ к какому-то источнику данных.

Цитата:

В VFP команды ? fieldname и SELECT-SQL могут давать разные результаты даже когда:
- эти команды расположены в одной рабочей области (об этом я уже сказал)
- корректировка идет в этой же области!
- таблица никем больше не корректируется и даже не открывается!

 ** create.prg - Процедура создания тестовой таблицы
 set safe off
 create table t1 (c1 c(10), c2 c(1))
 append blank
 use in t1

 ** fpd.prg - запуск теста из FPD
 set echo off
 set talk off
 set esca on
 clear all
 close all
 clear
 set refresh to 0,2
 use t1 in 0 share
 do cycle.prg

 ** vfp.prg - запуск теста из VFP
 set echo off
 set esca on
 clear all
 close all
 clear
 set refresh to 0,2
 _myForm=NewObject("myForm")
 define class myform as form       
        proc Init()
             use t1 share 
             This.NewObject('tb2','textbox')
             with This.tb2
                  .ControlSource = "t1.c2"
                  .Value='' 
             endwith
             do cycle.prg
        endproc
 enddefine

 ** cycle.prg - процедура тестирования поведения команд
 priv _plSame, _plDiff, _lnCount
 store 0 to _plSame, _plDiff, _lnCount
 do while .t. 
    _lnCount=_lnCount+1
    sele t1
    replace c1 with str(_lnCount,10)
    select *, 33 from t1 into cursor t2
    if t1.c1==t2.c1
       _plSame=_plSame+1
    else
       _plDiff=_plDiff+1
    endif
    @ 1,1 say 'Same='+str(_plSame)+',    Different='+str(_plDiff)
 enddo

ГАИшник останавливает машину и спрашивает водителя:
- Если лобовое стекло разбить, колёса сдуются?
А водила ему в ответ:
- А если я тебе монтировкой по голове дам, шнурки развяжутся?

Igor Korolyov
Да, в FPD я не знаю как можно создать такую конфликтную ситуацию, чтобы REPLACE в одном курсоре не повлиял на остальные курсоры открытые (или "якобы открываемые автоматически", как в случае с SELECT SQL) на базе этой-же таблицы (именно в рамках одного процесса) - но и утверждать что такого состояния в FPD невозможно достигнуть тоже не стану.

Igor Korolyov
В частности сделать FLUSH в процедуре с REPLACE, ну и/или выполнять увод фокуса с "привязанного" к полю текстбокса в форме - при условии что намечается какая-либо работа с данным курсором.

Цитата:

когда ? fieldname, REPLACE и SELECT-SQL в рамках одного процесса работают не в одном адресном пространстве

Igor Korolyov
Ещё раз - SELECT SQL и REPLACE ВСЕГДА работают в РАЗНЫХ курсорах (или "адресных пространствах" если тебе так угодно)

Igor Korolyov
Есть отличия в "распространении" изменений вносимых REPLACE. Если они не доходят до ОС (грубо говоря не записываются на диск), то и внутри фокса в РАЗНЫХ курсорах мы увидим РАЗНЫЙ результат. Т.е. получим "несинхронизированные" курсоры.
И тут дело не в "виновности" REPLACE, а в том что она ДОЛЖНА учитывать разные "внешние условия" - в т.ч. и "подвисшую" блокировку получившуюся в результате того самого "незаконченного ввода".

Цитата:

Есть отличия в "распространении" изменений вносимых REPLACE

CREATE TABLE test (c1 C(10))
INSERT INTO test (c1) VALUES ("test")
CLOSE ALL
USE test SHARED IN 0 ALIAS t1
USE test SHARED IN 0 ALIAS t2 AGAIN
SELECT t2
REPLACE c1 WITH "t2"
SELECT *, 'new' FROM t1 INTO CURSOR t3
? t1.c1, t2.c1, t3.c1

Цитата:

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