Sergiy DiakКоманда SQLEXEC(nHandle, lcSelectCommand, lcCursorName) под VFP9.0 вернёт курсор с именем lcCursorName и поставит ему по умолчанию свойство buffering = 3. При попытке поменять его получается изменить только на 5. Есть ли возможность скинуть его в 1?
Нет. Невозможно.

Генетический мусорВ клиент-серверных системах буферизация не нужна
Сильное замечание. Отсюда следует логичный вывод, что FoxPro писали, мягко говоря, не очень умные люди. Зачем-то прикрутили совершенно не нужный функционал от которого невозможно избавится...

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

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

Генетический мусорЛюди писали сложнейшие клиент-серверные системы задолго до появления курсор-адаптеров и прочей мути. Значит как-то выкручивались, умели делать, знали как нужно было работать.
Если посмотреть, что же именно они сделали, то окажется, что они создавали свой собственный класс CursorAdapter. Только не общего назначения, а "заточенный" под конкретную задачу со своей спецификой.

Ключевое слово здесь "выкручивались". То, на что раньше требовалось писать кучу кода сейчас делается "штатными" средствами.

Генетический мусорЕсли полученный с сервера курсор не избавить от буферизации, и начать фоксовскими командами править в нем данные (REPLACE,UPDATE,GATHER и т.д.) - то изменения в курсоре иногда визуально не отражаются, пока не выполнить принудительно tableupdate(), что не очень удобно
Если Вы используете для модификации прямые команды REPLACE, UPDATE и т.п., то дописать после них TableUpdate() - не проблема. Командой больше, командой меньше - не принципиально. Несколько неудобно, это да, но не настолько, чтобы "крик поднимать"

Генетический мусорСколько раз уже доказывали что в реальных системах записью одних только изменений в курсоре недостаточно. Классический пример - документ + фактура. Изменяем данные в фактуре и пересчитываем суммы по документу, все в одной транзакции. Как тут tableupdate обойдешься ?
Насколько я заметил, с этим утверждением никто и не спорил. Буферизация и транзакция - это РАЗНЫЕ вещи и предназначены для РАЗНЫХ целей. Ведь даже если Вы исключите буферизацию запись БЕЗ транзакции делать не будете.


Понимаете, Вы точно также как и alex11100 рассуждаете исходя из собственного опыта и личных предпочтений. Логика примерно такая: если я этим не пользуюсь или в моей задаче это мешает, то это вредно и не нужно. То, что этим пользуются другие люди и создают успешно работающие программы с негодованием отвергается.

alex11100Логичное - простое.
Чем сложнее суждение (к программировании применимо алгоритм),
тем больше ситуаций когда суждение или алгоритм неверен(ошибочен).

Возражайте.
Возражаю.

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

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

Теория дифференциальных уровнений логичная? Безусловно! А простая? Ну, для кого как.

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

На практике, самым трудным для понимания оказываются самые простые вещи. Нормализация - отсутствие дублей. Просто. Но кто-нибудь, когда-нибудь приводил ТАКОЕ определение? Нет! Все время вокруг "накручивают" море слов, через которое надо "продираться" к пониманию элементарных вещей.

Сложность и ошибочность - опять РАЗНЫЕ понятия. Здесь под термином "сложность" подразумевается именно "сложенность", т.е. конструкция из многих слагаемых. Не случайно, Вы тут же вспомнили "вероятность" (разные ситуации)

"Ритуал" может быть очень сложен, но выполняется без ошибок. Для программиста, роль "ритаула" выполняет его стиль программирования. Т.е. некий способ написания кода, который выполняется "на автомате" и позволяет избежать ряда ошибок. Уже не задумываясь над тем, что именно программируется. В результате, следование стилю позволяет писать очень сложные вещи без ошибок.

alex11100Основной принцип, который позволяет избежать ошибок
при построении сложных суждение - АБСТРАКЦИЯ.

Возражайте.
Возражаю.

Абстракция - это ИНСТРУМЕНТ. Как любой другой инструмент, он применим при определенных условиях. Использовать микроскоп в качестве молотка можно, но, может все-таки лучше взять другой инструмент? Более подоходящий в данных условиях для решения данной задачи?

Универсальных инструментов НЕТ.

При построении сложных суждений, используют РАЗНЫЕ инструменты. Если Вы привязываетесь к какому-либо одному инструменту, то вероятность ошибок резко возрастает. И не имеет никакого значения, какой именно инструмент Вы используете. Сложная проблема потому и сложная, что состоит из разных частей. К каждой части нужен свой подход. Свой инструмент.

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

Сейчас очень сильно рекламируют NET-технологию. Но означает ли это, что данный инструмент самый удобный для решения вообще ВСЕХ задач? Разумеется нет.

alex11100ну давайте. напрямую

выясним, что лучше, и с точки зрения Логики.

ООП или тупое и слепое набивание прг и лепление форм.
Дайте ссылку, где я такое говорил. А также укажите граничные условия при которых будет проводится сравнение. "Лучше" при каких условиях и для решения каких задач?

Проблема в том, что Вы никогда не говорите при каких условиях то или иное решение будет лучше или хуже. Вы говорите что это есть хорошо, а это есть плохо. Но КОГДА? Ах "всегда"? Т.е. чтобы перейти на другую сторону улицы мне надо построить самолет? А просто пешком нельзя?