ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Вьюха
10 сообщений из 10, страница 1 из 1
Вьюха
    #33289397
Тупой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тупой
Участник
Создал вьху, орисание такое.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
SELECT Depts.dpt_code, Depts.dptname_ru, Depts.dptname_en, Depts.uid,;
  Depts.tcomment;
 FROM ;
     PLANING!DEPTS

DBSetProp(ThisView,"View","SendUpdates",.T.)
DBSetProp(ThisView,"View","BatchUpdateCount", 1 )
DBSetProp(ThisView,"View","CompareMemo",.T.)
DBSetProp(ThisView,"View","FetchAsNeeded",.F.)
DBSetProp(ThisView,"View","FetchMemo",.T.)
DBSetProp(ThisView,"View","FetchSize", 100 )
DBSetProp(ThisView,"View","MaxRecords",- 1 )
DBSetProp(ThisView,"View","Prepared",.F.)
DBSetProp(ThisView,"View","UpdateType", 2 )
DBSetProp(ThisView,"View","UseMemoSize", 255 )
DBSetProp(ThisView,"View","Tables","planing!depts")
DBSetProp(ThisView,"View","WhereType", 3 )

DBSetProp(ThisView+".dpt_code","Field","DataType","C(10)")
DBSetProp(ThisView+".dpt_code","Field","UpdateName","planing!depts.dpt_code")
DBSetProp(ThisView+".dpt_code","Field","KeyField",.F.)
DBSetProp(ThisView+".dpt_code","Field","Updatable",.T.)

DBSetProp(ThisView+".dptname_ru","Field","DataType","C(40)")
DBSetProp(ThisView+".dptname_ru","Field","UpdateName","planing!depts.dptname_ru")
DBSetProp(ThisView+".dptname_ru","Field","KeyField",.F.)
DBSetProp(ThisView+".dptname_ru","Field","Updatable",.T.)

DBSetProp(ThisView+".dptname_en","Field","DataType","C(40)")
DBSetProp(ThisView+".dptname_en","Field","UpdateName","planing!depts.dptname_en")
DBSetProp(ThisView+".dptname_en","Field","KeyField",.F.)
DBSetProp(ThisView+".dptname_en","Field","Updatable",.T.)

DBSetProp(ThisView+".uid","Field","DataType","C(4)")
DBSetProp(ThisView+".uid","Field","UpdateName","planing!depts.uid")
DBSetProp(ThisView+".uid","Field","KeyField",.T.)
DBSetProp(ThisView+".uid","Field","Updatable",.T.)

DBSetProp(ThisView+".tcomment","Field","DataType","C(10)")
DBSetProp(ThisView+".tcomment","Field","UpdateName","planing!depts.tcomment")
DBSetProp(ThisView+".tcomment","Field","KeyField",.F.)
DBSetProp(ThisView+".tcomment","Field","Updatable",.T.)
В командном окне выполняю команды:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
= CURSORSETPROP('Buffering', 5 , "VDEPTS")   
INSERT INTO Vdepts (uid) VALUES (GetNewHexId("VDEPTS","UID",.T.))
INSERT INTO Vdepts (uid) VALUES (GetNewHexId("VDEPTS","UID",.T.))
INSERT INTO Vdepts (uid) VALUES (GetNewHexId("VDEPTS","UID",.T.))
INSERT INTO Vdepts (uid) VALUES (GetNewHexId("VDEPTS","UID",.T.))
INSERT INTO Vdepts (uid) VALUES (GetNewHexId("VDEPTS","UID",.T.))
INSERT INTO Vdepts (uid) VALUES (GetNewHexId("VDEPTS","UID",.T.))
? TABLEUPDATE(.t.,.t.,"VDEPTS")
Все происходит прекрасно.

Но как только я хочу сделать тоже самое в форме редактирования записи вьхи, вот так в форме по кнопочке сохранения данных:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Local  lcNewID
Select VDEPTS
If Thisform.nmode= 1 
	Append Blank   <- вот тут ругаеться
	m.lcNewID = GetNewHexId("VDEPTS","UID",.T.)
	Replace UID With m.lcNewID IN VDEPTS
Else
	m.lcNewID  = UID
Endif
With Thisform
	Select VDEPTS
	Scatter Name oVDEPTS
	oVDEPTS.UID = m.lcNewID
	oVDEPTS.DPT_CODE =  Alltrim( .tmnemo.Value )
	oVDEPTS.DPTNAME_RU =  Alltrim( .tNameRUS.Value )
	oVDEPTS.DPTNAME_EN =   Alltrim( .tNameENG.Value )
	oVDEPTS.TCOMMENT = Alltrim( .tcomm.Value )
	Gather Name oVDEPTS
Endwith
Thisform.Release()
Выкатывает ошибку:
СURSOR CANNOT CANNOT BE MODIFIED BECAUSE IT CONTAINS AN UNSAVED RECORD, где я накосячил ?

= CURSORSETPROP('Buffering',5, "VDEPTS") включен
...
Рейтинг: 0 / 0
26.09.2005, 18:07:21
| Ответить | Цитировать | Написать  
Вьюха
    #33289626
Тупой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тупой
Участник
Что-то я рано запаниковал :) Спасибо, все правильно. Работает... если конечно правильно обновлять грид.
...
Рейтинг: 0 / 0
26.09.2005, 22:01:29
| Ответить | Цитировать | Написать  
Вьюха
    #33290952
Тупой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тупой
Участник
А как правильно удалять записи во вьюхе , в 5 режиме буферизации ? И кстати, после добавления, как стать на нужную запись ?
...
Рейтинг: 0 / 0
27.09.2005, 14:32:51
| Ответить | Цитировать | Написать  
Вьюха
    #33291066
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВладимирМ
Участник
ТупойА как правильно удалять записи во вьюхе , в 5 режиме буферизации ?
Удаление - это тоже модификация. Просто модифицируется некое служебное (скрытое) "поле". Поэтому логика абсолютно такая же как и при модификации данных - TableUpdate() для сброса изменений в основную таблицу.

Если используется групповая команда (сброс изменений ВСЕХ записей), то настройка SET DELETED роли не играет. Если же сброс идет в цикле по одной записи за раз, то чтобы попасть на записи, помеченные как удаленные, естесственно, надо будет снять настройку SET DELETED

ТупойИ кстати, после добавления, как стать на нужную запись ?
Если значение ключевому полю присваивается через функцию, указанную в свойстве Default-поля, то надо просто перенести эту функцию в Default-поля самого View. Тогда добавляя запись во View сразу назначается новый код записи и по нему можно будет позиционироваться после обновления.

Если ключевое поле имеет тип Integer-Autoincrement, то здесь придется "выкручиваться".

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

Можно использовать двойную буферизаци. Наложить буферизацию на таблицу-источник. Тогда после сброса буфера из View имеем значение в буфере таблицы-источника. Потом сбрасываем буфер собственно таблицы-источника. Смысл в том, чтобы не спутать "свою" запись и запись, которая могла быть добавлена другим пользователем.
...
Рейтинг: 0 / 0
27.09.2005, 15:01:08
| Ответить | Цитировать | Написать  
Вьюха
    #33291208
Тупой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тупой
Участник
Вот удаляю я из вьюхи так :

Код: plaintext
1.
2.
3.
4.
5.
SELECT VDEPTS
DELETE 
With Thisform
	.GRD.SetFocus()
	.Refresh()
Endwith

Во 1. Происходит удаление ( вернее оно происходит) но в View не отображаеться с 1 раза.


Удалил я допустим 5 записей, выдал потом

Код: plaintext
1.
2.
3.
4.
5.
LOCAL llUpdate
SELECT VDEPTS
llUpdate = TABLEUPDATE(.T.,.T.,"VDEPTS")
........

REQUERY("VDEPTS")


Происходит удаление, ну мягко говоря не тех записей.
Вот в чем проблема.
Может мне удалять через SQL, типа Delete From .... Where .... ?

И кстати, вновь добавленные записи в буфере с "-", ведь, как мне прыгнуть потом на нужную ?
...
Рейтинг: 0 / 0
27.09.2005, 15:41:42
| Ответить | Цитировать | Написать  
Вьюха
    #33291817
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВладимирМ
Участник
1) У тебя View находится в 5 режиме буферизации. Это значит, что что бы ты ни вытворял со View, но пока не будет дана команда TableUpdate() никакие изменения View не будут "сброшены" в исходные таблицы.

2) Если вопрос стоит в отображении удаленных записей. Т.е. запись удалена, но она все еще отображается. То следует помнить, что настройка SET DELETED - это своеобразный фильтр. А фильтр вступает в силу, только после "передергивания" указателя записи. Следовательно, надо действовать примерно так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT VDEPTS
DELETE
SKIP
IF EOF()=.T.
	SKIP - 1 
ENDIF
ThisForm.Grid.SetFocus()

3) Удалять "не те" записи View не может. Когда ты создавал View, то указал какое поле (или набор полей) является ключевым (KeyField = .T.). В процессе сброса буфера и будут помечены как удаленные те записи значение ключевых полей которых совпадает со значениями ключевых полей записей, удаленных во View.

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

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

Ориентироваться на физический номер записи (Recno()) - бессмысленно. После перезапроса нет никакой гарантии, что даже "старые" записи остануться со старыми физическими номерами.
...
Рейтинг: 0 / 0
27.09.2005, 19:03:22
| Ответить | Цитировать | Написать  
Вьюха
    #33292012
Тупой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тупой
Участник
Да, ВладимирМ, именно к так как Вы говорите. У меня были проблемы именно с отображением удаленных записей во вьюхе , SET DELETED ON выставлен, все заработало как только передернул записи. Сенкс!
...
Рейтинг: 0 / 0
27.09.2005, 22:44:23
| Ответить | Цитировать | Написать  
Вьюха
    #33292017
Тупой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тупой
Участник
> автор Как ты вообще позиционируешся на запись в таблице? По ее идентификатору. Т.е. значению ключевого поля. Вот про это я тебе и говорил. Все ранее описанное относилось к тому, чтобы определить какое же значение получит ключевое поле таблицы в новой записи. После Requery() позиционируешся на запись с этим значением.

Ориентироваться на физический номер записи (Recno()) - бессмысленно. После перезапроса нет никакой гарантии, что даже "старые" записи остануться со старыми физическими номерами.

Особенно понравилось про бессмысленность Recno() после Requery(). Ну правильно, тоесть при добавлении 1 записи во вьюху она стала recno() =-1, вторая Recno()=-2. Соответсвенно для 1 записи я знаю ID, допустим 1, для второй ,допустим 2. Как же мне после Requery() по ID стать на эту запись ? SEEK"M ?, LOCATE ? Только как-то я не встречал информации о том что для View можно строить индекс. Просвятите, плиз, еще на счет этого вопроса ?
...
Рейтинг: 0 / 0
27.09.2005, 22:53:44
| Ответить | Цитировать | Написать  
Вьюха
    #33292102
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Korolyov
Участник
Hi Владимир!

> Если же сброс идет в цикле по одной записи за раз, то чтобы попасть на записи, помеченные как удаленные, естесственно, надо будет снять настройку SET DELETED

Не обязательно - зависит от того КАК идёт переход если с циклом по GetNextModified() + GO - то без разницы (т.к. GO становится и на "отфильтрованную" запись)

2 Тупой

1) Забудь про RECNO()
2) ЧТО у тебя вводится в эти записи перед "сбросом" из в собственно таблицу? Если есть поле уникально идентифицирующее запись - то можно после перезапроса сделать LOCATE по нему. Если нету - то либо ты делаешь как сказал Владимир (т.е. получаешь ID записи ещё при вставке в буфер, т.е. ДО сохранения - и тогда после перезапроса LOCATE по этому ID) - либо банально "забиваешь" на эту проблему - т.е. после перезапроса становишься НЕ на ту запись где был в момент начала сохранения. Кстати строго формально новой записи в курсоре может и не оказаться - например она не подойдёт по параметрам запроса (а ввести "неподходящую" фокс не помешает - только твой код проверки может помешать :) )

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
28.09.2005, 02:22:47
| Ответить | Цитировать | Написать  
Вьюха
    #33294417
Тупой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тупой
Участник
автор...либо банально "забиваешь" на эту проблему - т.е. после перезапроса становишься НЕ на ту запись где был в момент начала сохранения
Мне идея понравилась :) Так и сделал. Спасибо.
...
Рейтинг: 0 / 0
28.09.2005, 20:06:21
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Вьюха
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=41&msg=33291208&tid=1593399]:
 0ms
get settings:
 6ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 269ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 36ms
get tp. blocked users:
 1ms
others: 199ms
total:  534ms
созд. / загр.: 534ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]