Владимир, вы меня удивляете, я только что перечитал топики, именно я FoXXX и не отказывался от ордер, вам и впрямь лень разобраться в дискуссии..

/*Ну, наконец-то Вы согласились с тем, что нужен ORDER BY. Хоть какой-то сдвиг. До сих пор, Вы утверждали, что ORDER BY не нужен о чем свидетельствует последний приведенный Вами пример*/ я несколько раз говорил о упорядоченном RV!!! Вы просто игнорируете мои посты и продолжаете меня критиковать, начиная с поста 2435474 я открытым текстом пытаюсь говорить вам о ORDER RV но вы игнорируете мои слова и продолжаете мне расказывать и физическом расположении данных в таблицах SQL..

Я не соглашался с тем, что нужен ORDER т.к. RV у меня всегда ордер по id... зачем мне с этим соглашаться?? если иначе и не делаю?

/*Да при чем здесь скорость?! Главное, что требуется, это получить ID именно той записи, которую добавил данный конкретный пользователь. Метод с GO BOTTOM - этого НЕ ОБЕСПЕЧИВАЕТ. Кстати, о каком таком "моем методе" Вы говорите?*/ - ID последней записи наибольший, не вы ли утверждали что go bottom это max?
теперь о вашем методе:

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

2) Если у RV есть возможность ОДНОЗНАЧНО идентифицировать запись по ДРУГИМ полям, то после перезапроса надо найти запись с ранее запомненными значениями этих других полей. В найденной записи и прочитать значение ID.
*/ - вот в этом ваш метод, я не делаю так, который раз вам повторяю,
зачем мне номер соединения? requery сделает вставку новой записи из буфера (сбросит ее), пакетом выполняется select c с условиями RV , я получаю новую запись в RV с заполненным ID (ident), в RV order по id, где по вашему должна быть новая (последняя) добавленная запись клиента??? вам не кажется в конце курсора RV?

Ув. ВладимирМ

вот такой эксперемент:

открываем RView

use rasp
append blank
=requery()
go bottom

в поле id появляется значение, в этот момент на сервере (SQL Profiler) происходит следующее:

RPC:Completed /
exec sp_executesql N'INSERT INTO dbo.rasp (date_reg,data_ot,dsk) VALUES (@P1,@P2,@P3)', N'@P1 smalldatetime,@P2 smalldatetime,@P3 smalldatetime', NULL, NULL, NULL

SQL:BatchCompleted /
exec sp_executesql N'INSERT INTO dbo.rasp (date_reg,data_ot,dsk) VALUES (@P1,@P2,@P3)', N'@P1 smalldatetime,@P2 smalldatetime,@P3 smalldatetime', NULL, NULL, NULL

если между первой и второй командой возможна вставка... то вы меня УБЕДИЛИ!!! СДАЮСЬ!!!

Ув. ВладимирМ

вот такой эксперемент:

открываем RView

use rasp
append blank
=requery()
go bottom

в поле id появляется значение, в этот момент на сервере (SQL Profiler) происходит следующее:

Извиняюсь, была допущена опечатка!

RPC:Completed /
exec sp_executesql N'INSERT INTO dbo.rasp (date_reg,data_ot,dsk) VALUES (@P1,@P2,@P3)', N'@P1 smalldatetime,@P2 smalldatetime,@P3 smalldatetime', NULL, NULL, NULL

SQL:BatchCompleted /
SELECT Rasp.vhod_num, Rasp.date_reg, Rasp.control, Rasp.otv_kontr, Rasp.n_kart, Rasp.data_ot, Rasp.isp, Rasp.type_doc, Rasp.tema_doc, Rasp.contests, Rasp.visa, Rasp.rassilka, Rasp.rez, Rasp.dsk, Rasp.pd FROM dbo.rasp Rasp ORDER BY Rasp.vhod_num

если между первой и второй командой возможна вставка... то вы меня УБЕДИЛИ!!! СДАЮСЬ!!!

автор/*P.S. Не вы первый, не вы последний - довольно часто неопытные программисты
(и как ни жаль именно Fox программисты) неверно понимают принципы
физического хранения данных в "больших СУБД", и заодно принципы работы
оптимизаторов (как раз в части того в каком же порядке будут выдаваться
записи) - во многом из-за стереотипов, привитых работой с dbf-ами. Вот
совсем как и вы, считают что последовательно добавляемые записи будут так-же
последовательно храниться, и соответственно так-же последовательно
выдаваться при запросах (хотя стоит отдать вам должное - все-жё Order By ID
вы добавили - видимо когда-то "попали" на ту самую ситуацию когда позже
добавленное оказалось не в конце выданного курсора). автор*/

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

2.напрасно вы думаете что это является новостью.. вставка записей на место удаленных, это на сколько я помню применялось в кларионе в 90м году.. я уже говорил и еще раз говорю, работа MSSQL в данном случае вообще не имеет значения, тем более хранение его данных, это все флуд. Ордер бай добавил по умолчанию, автоматически лет 5 назад, т.к. считал id ключевым полем

автор/*- если данные добавляемые разными клиентами разделены - т.е. мы ни при каких
условиях не получим "чужие" записи (в условиях отбора есть параметр
отделяющий "свои" записи от "чужих" - типа Owner_Id - и конечно под одним и
тем-же ID в системе не могут одновременно работать более 1 пользователя). автор*/

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


автор/*Так что мне скажем
более приятна концепция Sequence в Oracle - или её фоксовый аналог NewId -
по крайней мере можно получить очередное значение, ничего на сервере не
сохраняя - и не маяться с "перекодированием" временно присвоенных значений
для полей внешних ключей автор*/

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

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

? FoXXX
…если между первой и второй командой возможна вставка... то вы меня УБЕДИЛИ!!! СДАЮСЬ!!!

ДА! И про это вам все время писали, но вы НЕ ХОТИТЕ ЧИТАТЬ !!!

Aleksey-K из [2420236]
// …Пока вы раздумываете, что делать с этим новым значением ID, другой процесс может вставить эту запись.. Ну не таблицу же всю блокировать при вставке записи.//


ВладимирМ из [2420313]
//Создание новой записи таблицы может вызвать срабатывание триггера, внутри которого будет выполнено также создание новой записи.//

ВладимирМ из [2425249]
// TableUpdate() - это команда на модификацию, Requery() - команда на чтение. Две разные команды. Почему между ними не может "втиснуться" другая команда?//

PaulWist из [2426204]
// .. обоснуйте почему во время TableUpdate или во время Requery невозможно добавить запись удовлетворяющую условию отбора или модификации.//

ВладимирМ из [2426312]
// Это все к тому, что вставка другим пользоваителем между вставкой первого пользователя и считыванием текущего состояния - вполне реальная возможность, которую просто необходимо учитывать.//

Igor Korolyov из [2433013]]
//Ну про то что "я никогда не видел как в базу параллельно вставляется
несколько записей в течении одной секунды" - уже сказано - это порочная
логика - то что девелопер не в состоянии достаточно синхронно нажать 2
кнопки на 2-х клавиатурах не означает что это невозможно в принципе.//

уважаемый ?

все приведенные вами ответы относились к конструкции tableupd() requery(), если вы посмотрите внимательно - во втором сообщении я поправился и отказался от tableupd() ... потому что между этими командами действительно возможна вставка..

Aleksey-K[quot FoXXXHi Алексей!
с ходу не могу придумать такой ситуации, подскажите, отвечу..
о каких операциях речь?

Да сколько угодно. Напишите с помощью RV например:
1. Корреляционный запрос
2. Запрос с подзапросами
3. Запрос с UNION
4. Запрос с использование UDF сервера.
...
...
Или вы можете обойтись без всех этих возможностей сервера? Я, например, нет.
А как, например, с помощью RV выполнять сложные расчеты в базе данных? Переводить их на клиента!? Увольте. В этих процедурах бывает у меня до несколько тысяч строк, задействовано до 20-30 таблиц и все это гнать на клиента!?
С уважением, Алексей.[/quot]

вы правы Алексей, какой смысл тащить это на клиента, всему этому место на сервере, там создаю необходимые view и все что вы спрашивали, базу ведь на SQL всеравно создавать нужно, вот и пусть там это все лежит и работает, RV позволяет обращаться ко всем обьектам MSSQL. Также использую на сервере тригеры и т.д. Это впринципе можно сделать в любой базе, хоть ORACLE хоть MSSQL..

Да и еще Игорь,

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

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

Да ребята, убедили! Вы правы! Мой метод работы с базой вами не применим!!!

У вас это работать не будет!!! Потому что вы нарушаете основы построения систем, не используете идентификацию, не ведете журналов безопасности, и не делаете всего того что надо бы делать... Время экономите? Упрощаете процесс создания программ? Удешевляете продукт путем выхолащивания?
И что? Ни один клиент не спросил: А кто и когда перекинул наши деньги в офшор??? Кто почистил мой счет? Кто удалил накладную?? Да и вообще, кто печатал документ?
Везет... блин, здесь без этого шагу не ступить.. а они шлепают и продаю, шлепают и продают.. мечта..
Убедили.. ваши методы наиболее правильные.. наиболее применяемые..

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

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

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

Удачи в освоении PC..!

Уважаемый господин ?

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

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

1. авторвы предполагаете, что между командами append blank и =requery() вставка другой строки чем-то (кем-то) – не возможна ? Я правильно вас понял? сообщение №2439783

отвечаю: предполагаю, полагаю и знаю.. обьяснять нужно? обьясняю append работает с буфером, на сервере ничего не происходит, запустите SQL Profiler и убедитесь!

2. авторПро то, что REQUERY( ) сбрасывает в базу – буфер нет ни слова. Не для этого она предназначена! №2439870

отвечаю: не предназначена! но она не может выдать новые данные без новых данных находящихся в буфере, она сбрасывает буфер на сервер, запустите SQL Profiler и убедитесь!


3. авторВы конечно, извините, но на основании каких постов, вами был сделаны эти бредовые выводы ?
№2440230

эти по вашему мнению бредовые выводы были сделаны на основании сообщения №2439646 где было сказано следующее: авторразве вы указали в самом начале,
что у вас идёт строгое разделение записей по признаку "владельца"? Что у
вас в принципе невозможно чтобы для некоторого одного определённого Owner_ID
были добавлены записи с РАЗНЫХ работающих экземпляров программы? Т.е. по
сути система получается во многом однопользовательская - ибо нет
"пересечения" с конкурирующими пользователями - по сути вы вполне можете
разделить данные по разным таблицам - это ничего не изменит в работе
программы - и так и так никто не видит "чужих" записей.

следовательно owner_ID не применяется, следовательно он и у остальных не используется.. если бы он использовался, то не возникало бы столько вопросов о том как это не вставляется в RV после requery() записи других клиентов???? Вот и у вас такой же бредовый вопрос.. Я вам отвечаю: НЕ ВСТАВЛЯЮТСЯ!!!!

4. автор..И что? Ни один клиент не спросил: А кто и когда перекинул наши деньги в офшор??? Кто почистил мой счет? Кто удалил накладную?? Да и вообще, кто печатал документ?...

Вот вам и пытались показать (к сожаленью, я понял - безуспешно), что ваша методика получения ID как раз и может привести к таким вопросам! И если их еще вам не задавали, то это - только вопрос времени…. №2440230

каким образом вы связывает ID ident и owner_ID???

5. авторТут порой не знаешь, пока идешь к клиенту, на чем у него база будет лежать, какой у него сервак.. а у вас все под T-SQL заточено и отлажено..

А какое это имеет отношение к выбору правильной методики получения ID?


отношение описано в сообщении №2439062, 2438557 и др.



Теперь ВладимирМ

1.В вашем сообщении №2440006 вы сказали:
авторесли говорить об ident - он является ключевым полем, потому го боттом ориентируясь по нему пойдет на последний id, а рекьюри сделает пакетом апдейт и селект, го боттом передвинет указатель на последний id, готоры к тому времени в вью появится..

ГДЕ здесь "открытый текст" про то, что Вы используете конструкцию ORDER BY? Вы делаете ПРЕДПОЛОЖЕНИЕ, что "поскольку поле ключевое, то..."


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

вами сказано:
ПРЕДПОЛОЖЕНИЕ, что "поскольку поле ключевое, то..." в моем тексте слова "поскольку" - нет.. и предположения нет, текст - утверждение..

2. авторСамый последний Ваш пример, где Вы приводили тест по вставке кучи записей через RV, начинается с собственно запроса

в примере речь шла о принцыпах хранения данных, т.е. это уход от основной темы - флуд, поэтому там нет order.

3. авторFoXXX 2438093
Залезть в BOL оно конечно можно, но чесслово - лень..
ну не в этом суть.. пример вам я прогнал, впринципе порядок соблюдается, зачем копать MSSQL если используется кей по id?
он используется везде по умолчанию, на мой взгляд это логично, нужен другой порядок -пжалуста ORDER.. в select..

ЭТО заявление сделано на основании приведенного примера БЕЗ ORDER BY


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

4. авторДа сколько можно повторять! ДА! ВОЗМОЖНА! Это основа основ ЛЮБОЙ серверной базы данных. Как раз то, что Вы так упорно НЕ ЖЕЛАЕТЕ ЗНАТЬ!

Более того, возможна вставка В ПРОЦЕССЕ выполнения команды SELECT. Т.е. на момент начала выполнения SELECT новой записи еще не существует, но в процессе выполнения Select произошла вставка другим пользователем и эта новая запись попала в результат работы SELECT

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

удачи в освоении pc!

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

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

В общем, учту на будущее...


Резюме:

имею RV order id , параметр по owner_id;RV2 order id , параметр по id

открываю форму
select RV
append blank
repl owner_id with m.owner, data with date()
requery()
thisform.(grid1)refresh
работаю с новой записью,
добавляю запись в зависимую таблицу (RV2)
sele RV2
append blank
repl rv2.id with rv.id,owner with m.owner,date with date()
requery()
thisform.(grid2)refresh
работаю с записью

ухожу из формы
tableupd(rv)
tableupd(rv2)
thisform.release

выигрыш:
RV - к любой базе, нигде нет привязки к серверу, ведется протокол работы клиента

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

на сервере для ведения отдельного проткола использую тригеры типа таких:

CREATE TRIGGER [ind] ON dbo.rabota
FOR insert
AS
insert protokol (log,app,host,nt,op) values(suser_sname(),app_name(),host_name(),'rabota','ins')

CREATE TRIGGER [rd] ON dbo.rabota
FOR DELETE
AS
insert protokol (log,app,host,nt,op) values(suser_sname(),app_name(),host_name(),'rabota','del')

CREATE TRIGGER [ins] ON [dbo].[zadan]
FOR INSERT
AS
insert protokol (log,app,host,nt,op,nz) select suser_sname(),app_name(),host_name(),'zadan','ins',inserted.name from inserted

CREATE TRIGGER updet ON [dbo].[zadan]
FOR UPDATE
AS
IF update ( gob ) insert into updat (iid,pole,tab,npole,spole) select inserted.id,'gob','zadan',inserted.gob,deleted.gob from inserted,deleted
IF update ( zak ) insert into updat (iid,pole,tab,npole,spole) select inserted.id,'zak','zadan',inserted.zak,deleted.zak from inserted,deleted
IF update ( zz ) insert into updat (iid,pole,tab,npole,spole,nn) select inserted.id,'zz','zadan',inserted.zz,deleted.zz,inserted.name from inserted,deleted

if update(zz) update zadan
set datz=getdate()
from deleted
where zadan.id=deleted.id

CREATE TRIGGER [zd] ON [dbo].[zadan]
FOR DELETE
AS
insert protokol (log,app,host,nt,op,nz) select suser_sname(),app_name(),host_name(),'zadan','del',deleted.name from deleted


по поводу - понимаю, непонимаю.. особенно заниматься теорией некогда.. там где нужно читаем, обьем работ большой, много предметной информации приходится изучать, да и серверов разных полно, MSSQL, ORACLE9i, INFORMIX, PROGRESS, как вы думаете, если бы я разбирался дотошно с каждым сервером, много бы програм написал? Нужен был универсальный подход, я его достиг избежав прямого обращения к серверам, работаю с RV.

Без притензий и обид. FoXXX

__Владимир__ FoXXXРезюме:

имею RV order id , параметр по owner_id;RV2 order id , параметр по id

открываю форму
select RV
append blank
repl owner_id with m.owner, data with date()
requery()
thisform.(grid1)refresh
работаю с новой записью,
.
.
и т.д.
FoXXX
Значит в ваших задачах невозможно видеть документы других пользователей?
Я правильно понял?
А вот заказчику понадобится видеть журнал документов всех пользователей и одновременно вводить новые и так для каждого пользователя. Тогда ваша схема рушится. Или придётся делать дополнительные телодвижения для поиска вашего последнего ID документа, например такие:
go bottom
do while !bof()
if owner_id=m.owner
exit
endif
enddo
и тд
не спорю, можно и так.
Но можно проще используя SQLEXEC()
А заказчик может попросить чтобы журнал документов отображался не в порядке очерёдности ввода а в другом, тогда как найти последний ID документа?

Владимир!

RV - это всего лишь строчка "select * from * for *=* " и т.д.

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

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

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

тут вопрос в другом, может вы подобное делали, нужен метод работы с любыми базами! системе должно быть все равно где лежат данные, она должна знать только свои view.. или RV. вот такую цель я преследую, конечно если ваш продукт строго под MSSQL, то да можно использовать функции. а если данные в ORACLE? как себя поведет конструкция SQLEXEC(h,'Select @@identity','ident') ? Oracle может и не понять..

__Владимир__Действительно интересный метод получения последнего ID пользователя.
Если иметь дополнидельный (невизуальный) RV например с таким запросом
SELECT TOP 1 ID FROM MyTab WHERE owner_id=??? ORDER BY ID DESC
,то получение последнего ID будет довольно быстрым и всего лишь одной командой.
Думаю некоторые возьмут данный метод на вооружение.
Но нужно очень чётко отслеживать за тем, чтобы в системе небыло одновременно работающих по одними owner_id пользователей.

Привет Владимир!

еще здесь не упоминалось то что кроме where в RV можно использовать команду:
set filter to owner_id=m.owner_id тогда вообще видно всех, или только овнера..

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

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