FoXXXЕсли работать с базами не используя всю мощь RV, то чем тогда VFP лучше Дельфи?
Опять слушаем только себя?

Ведь никто не сказал, что RV использовать нельзя. RV - это инструмент. Как любой другой инструмент, он имеет достоинства и недостатки. Надо всего-лишь понимать его ограничения. При чем здесь "вся мощь", если эта самая "мощь" используется неправильно?

FoXXXВладимирМ!

В чем неправильность, не уточните?
Но не забывайте - ведение owner_id - у нас обязательно..
так в чем?
Еще раз! Да сколько можно!

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

Оговорки для Вашей задачи:

-) Два пользователя не могут (не должны) войти в приложение с одинаковым owner_id.
-) Пользователь не может (не должен) модифицировать (видеть) данные другого пользователя

Плюс ограничения, накладываемые на собственно способ хранения данных, синтаксис RV и механизм его использования. Т.е. собственно постановка задачи.

Как универсальное решение для любой задачи это не годится. Задач, когда Ваше решение не сработает достаточно много. Т.е. даже нельзя сказать, что Ваше решение сколько-нибудь распространенное. Очень уж оно узкоспециализированное. Очень частное.

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

FoXXXДавайте по существу
Давайте.

FoXXXп.1
а разве это допустимо? Для меня нет, в любой многопользовательской задаче.., если вы пишете однопользовательскую задачу, тогда да, один пользователь входит в систему сколько угодно раз..
"Разрешено все, что не запрещено".

Если Вы пишите однопользовательскую задачу, то программа вообще может быть запущено только один раз. Вне зависимости от того, с одним логином и паролем Вы входите или с разным.

Что значит "допустимо"? У Вас есть в программе перехват такой ситуации? Т.е. Вы можете отследить, что приложение было запущено дважды с логином и паролем одного и того же пользователя?

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

Другая "житейская" ситауция. Пришел новичек, а администратора (программиста) нет. Запускаем на его машине приложение с моим логином и паролем, а я продолжаю работать на своей машине.

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

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

FoXXXп.2
пользователь может, должен и обязан видеть, модифицировать, редактировать, использовать записи других пользователей, для этого существует другой RV, для этого существует тотже RV с "пустым" параметром, для этого существует set filter, для этого существует view на сервере, для этого достаточно возможностей, способов и методов работы с RV.
Ну, вот, начинается. Вы же сами пишете, что вместо одного RV для отображения одной и той же информации используется целый набор самых разных RV. Именно в силу того, что Ваш подход требует ряда серьезных ограничений на используемый RV.


FoXXXп.3
поясните какие ограничения я должен применять к способу хранения данных? в чем вы видете ограничения? дополнительное поле owner_id? или вы что-то другое имели ввиду? непонятно, уточните если сможете пожалуйста.
Если в RV не используется ORDER BY - это предполагает, применительно к MS SQL, использование кластерного индекса по полю Id. В противном случае, нет гарантии, что последняя запись выборки окажется последней созданной записью.

FoXXXп.4
универсальное для любой задачи.. не могу придумать многопользовательской задачи в которой отработанный годами (10 лет) метод перестанет работать.. если вы знаете такие задачи, озвучте их пожалуйста, возможно это поможет мне найти другие подходы в моей методике..
Пример в рамках Вашей задачи я уже привел. 2 пользователя вошли с одинковым owner_id.

Более экзотические случаи - это отсутствие кластерного индекса и отсутствие ORDER BY в RV.

FoXXXп.5
маштабируемость.. что вы имеете ввиду, увеличение клиентов? распределенные базы данных?
Нет. Прежде всего - это расширение функциональности программы. Новые модули, новые задачи, модификация старых задач и т.п.

Вы уже упоминали, что для решения разных задач Вам пришлось пойти на "размножение" RV. Хотя все они отображают одну и ту же информацию, но "чуть чуть по разному".

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

FoXXXМой (наш) метод решения задач выработан в течении последних 15ти лет как плавная миграция из FOXBASE в VFP9-SQL,ORACLE и др.

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

FoXXX
Интересно получается, когда Вы первый раз вышли со своей идеологией, то позиционировали ее как верную без ограничений.

Теперь выясняется, что у Вас есть в каждой записи каждой таблицы дополнительный идентификатор пользователя; используется ORDER BY по ключевому полю в RV; журнал активизации для исключения повторного входа с одним логином (кстати, если произошел аварийны выход - метка осталась, вход невозможен, зови админа); речь идет о банковской системе (определенная специфика работы); программа одновременно работает с несколькими серверными базами данных (SQL, PROGRESS, ORACLE). Ничего не пропустил?

Чувствуете разницу? Когда говорили о получении ID через SCOPE_IDENTITY(), то все это не имело никакого значения, поскольку решение было универсальное для любой задачи работающей с MS SQL. Никаких ограничений не накладывалось на систему.

А у Вас "чем дальше в лес, тем больше ..." не дров, конечно, но ограничений, о которых в самом начале дискуссии Вы скромно умолчали.

Более того, поскольку у Вас происходит одновременная работа с несколькими серверными базами данных, то разумеется, такой пожход не применим в принципе. Я не в курсе, но кажется, у Oracle просто нет полей типа Identity, т.е. бессмысленно пытаться применить синтаксис MS SQL в запросах к Oracle.

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


Насчет прав доступа.

Вообще-то я в курсе. Однако опять же, Ваша проблема в том, что Вы делаете универсальную систему под несколько баз данных. Существует своя собственная идеология разграничения прав доступа в самом MS SQL. Т.е. готовая . Подозреваю, что подобная система должна быть в любой серверной базе данных.

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


Насчет собственно использования RV и T-SQL

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

Весьма странно, что Вы так настойчиво выступаете против прямой работы через T-SQL. Для сколько-нибудь развитой банковской системы работать только и исключительно через RV - невозможно в принципе. Точнее, можно, если Вас не интересует производительность.

Вы как-то забываете, что RV - это всего-лишь надстройка над T-SQL. Т.е. нечто вроде визарда, для решения некоторых стандартных задач . Еще раз подчеркну - некоторых . По самой своей сути RV не может решить все возможные задачи.


Насчет способов хранения настроечной информации.

Во-первых, данный вопрос никак не относится к обсуждаемой проблеме.

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

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


PS: пожалуйста, не надо больше приводить код вида

append blank
=requery()

Как описание идеи - это еще сойдет, но как действующий код - он говорит о полной безграмотности разработчиков или об умолчании ряда допущений и ограничений.

FoXXX
"Ты, Мань, на грубость нарываешся"

Я могу поверить, что Ваш проект существует 15 лет, но как-то сомневаюсь, что Вы занимаетесь программированием столько же. Вопросы у Вас...

FoXXXя бы не называл все это ограничениями, я бы называл все это "вновь открывшимися возможностями!"
Которые имеют принципиальное значение для работоспособности предлагаемого кода.

FoXXXя в курсе, у ORACLE есть поля типа ident, там есть функция которая считает (счетчик)
Тогда Вы должны быть в курсе, чем отличается функция , от полей типа Identity. Функция может дать значение ДО момента физического создания записи. Поле Identity только ПОСЛЕ. Это два принципиально разных подхода.

FoXXXкак будем разводить клиентов в таблицах VFP? где эти таблицы будут лежать? это не лучший вариант..
Какое отношение имеет код записи к коду клиента? Вы вообще в курсе, что делает пример (форма) NewId.scx в стандартном примере Solution.pjx поставляемом с FoxPro?

Он формирует код записи ДО момента физического создания записи. Т.е. поля типа Identity вообще не используются, а код записи формируется на стороне клиента.

Напомню: назначение кода записи - это однозначная идентификация записи. Все.

Код клиента - это уже реквизиты записи. Они призваны решать другие задачи.

FoXXXда, привилегии есть везде, но как их использовать для блокировок кнопок на форме, опций меню и т.д.? в серверах привилегии по таблицам,полям, представлениям и т.д.
Не надо путать права доступа к данным и интерфейс. Это два разных направления. Да, они взаимосвязаны, но это не одно и то же.

FoXXXвы так думаете? почему тогда не надстройка над PL-SQL?
В данном случае, я неудачно выразился. Под T-SQL я подразумевал "прямой" доступ к данным по аналогии с SQLExec(). В литературе это называется "pass-through query"

Т.е. RV - это "обертка", некий "класс", который реализует часть задач обработки данных. Расширением этого "класса" в старших версиях FoxPro стал Cursor Adapter.

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

По сути Вы сказали: Программист не рашает задачи, он представляет (показывает) решения программы. А саму программу кто пишет?

Вы показывали то, что возвращает профайлер. Где этот код в RV? Надо думать, он его как-то сам сформировал. На основании чего? На основании тех данных, которые были введены и с учетом настроек сделанных при создании структуры RV.

Т.е. RV сформулировал (создал) запрос к серверу, передал ему этот запрос, получил ответ, трансформировал этот ответ в соответсвующий вид. Это еще не считая того, что делает RV на стороне клиента ДО формирования запроса серверу.


PS:

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

В том как Вы ведете дискуссию я не вижу стремления понять . Пока Вы просто цепляетесь к отдельным словам. Причем Вы демонстрируете потрясающую безграмотность и самоуверенность именно в программировании.

FoXXXВладимирМ!

у меня вопрос по вашей рекомендации:

автор1) Из открытого RV можно прочитать используемый им номер соединения. CursorGetProp("ConnectHandle"). Далее по этому номеру сделать запрос через SQLExec() и прочитать @@Identity или SCOPE_IDENTITY()


sqlexec(k,'SELECT @@IDENTITY as id','id')
sqlexec(k,'SELECT SCOPE_IDENTITY()as id','id')
дают NULL
после tableupd() дают результат, но в этот промежуток м-ду tableupd() и 'SELECT @@IDENTITY может вставиться чужая запись, не так ли?
Я уже объяснял в чем тут дело. Конструкция

append blank
Requery()

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

Эта конструкция будет работоспособна только и исключительно при строковой буферизации данных (3). Этот режим, в котором, по умолчанию, открывается любое View. Он характерен тем, что сброс буфера происходит автоматически в момент перехода на другую запись или при закрытии таблицы.

Другими словами, APPEND BALNK создает новую запись в буфере Local View. Поскольку сброса буфера не произошло, то и на самом сервере новая запись создана не будет и @@IDENTITY вернет NULL.

Команда Requery() первым делом "передернет" указатель записи. Т.е. произойдет автоматический сброс буфера (но только если RV в строковом режиме буферизации). Другими словами, автоматически даст команду TableUpdate().

Только после этого будет создана запись на сервере и возможно будет прочитать значение @@IDENTITY.

Т.е. на самом деле здесь не одна команда Requery(), а еще и неявная команда TableUpdate(). Проблема именно в том, что "неявная".