Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Принудительное изменение / 4 сообщений из 4, страница 1 из 1
22.02.2006, 09:31
    #33559888
M0r0
M0r0
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принудительное изменение
Прямо парадокс какой-то. У меня генерируются уникальные значения с помощью спец. таблице. Вставка осуществляется с помощью default значения поля ключа. Ниже приведен код.

Код: 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.
FUNCTION genrecid(tcAlias)
	
	LOCAL lcAlias
	IF TYPE("tcAlias")<>"C" OR EMPTY(m.tcAlias)=.T.
		lcAlias = UPPER(JUSTSTEM(DBF()))
	ELSE
		lcAlias = UPPER(AllTrim(m.tcAlias))
	ENDIF
	
	LOCAL l_arrValue
	DIMENSION l_arrValue[ 1 ]
	l_arrValue( 1 ) =  0 
	
	SELECT recid FROM ttables ;
		WHERE UPPER(ALLTRIM(tablename))=UPPER(ALLTRIM(lcAlias)) ;
		INTO ARRAY l_arrValue

	l_arrValue( 1 ) = l_arrValue( 1 ) +  1 
	
	UPDATE ttables ;
		SET recid = l_arrValue( 1 ) ;
		WHERE UPPER(ALLTRIM(tablename))=UPPER(ALLTRIM(lcAlias)) ;

	RETURN l_arrValue( 1 )
ENDFUNC

По какой-то причине, при выполнении команды APPEND BLANK эта функция берет старое значение ключа, т.е. команда UPDATE якобы не прошла, и получается две записи с одинаковым значением. Причем этот эффект повторяется с определенной периодичностью, т.е. добавил 1 запись, следующая уже будет дубль, а следующая уже нет. Даже перед RETURN l_arrValue(1) ставил TABLEUPDATE(.T.,.T.,lcAlias), но не помогло ((( Люди, поможите.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.02.2006, 09:58
    #33559948
Dima T
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принудительное изменение
На первый взгляд все правильно.
попробуй в конец TABLEUPDATE(.T.,.T., "ttables" )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.02.2006, 10:17
    #33559994
M0r0
M0r0
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принудительное изменение
Да заработало. Проглядел походу, вместо TABLEUPDATE(.T.,.T.,"ttables") вставлял TABLEUPDATE(.T.,.T.,lcAlias) .
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.02.2006, 01:32
    #33562070
Igor Korolyov
Igor Korolyov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принудительное изменение
Hi M0r0!

Учти, что ты не отслеживаешь возможного конфликта совместного доступа к
этому счётчику. Если не хочешь использовать явные блокировки, то добавь к
Update в условие "AND recid = l_arrValue(1) - 1" - т.е. мы проверяем что
значение счётчика не изменилось с момента выборки (то что выборка была всего
лишь парой строк выше роли не играет!). Естественно что после UPDATE надо
проверить _TALLY, и если там 0 - значит пока мы добавляли 1 кто-то успел
"влезть" - и нужно снова идти выбирать, наращивать, обновлять... Короче тут
нужен цикл.
ttables не нужно нигде явно открывать - тогда она не попадёт в режим
буферизации, и не нужен будет Tableupdate - а вот sys(1104) не помешает!

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Принудительное изменение / 4 сообщений из 4, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 451ms
Закрыть
start [/forum/topic.php?fid=41&mobile=1&tid=1592265]:
 0ms
get settings:
 7ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 170ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 28ms
get tp. blocked users:
 1ms
others: 217ms
total:  451ms
x
x
Закрыть


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