Поделитесь, пожалуйста, скриптом который позволяет обновить 1 периодический реквизит справочника, если нет - добавить новый (только пер. реквизиты с ручным вводом).
Планирую сделать ВТ в которой будет 3 колонки
Элемент Спр, Дата, ЗначениеРеквизита.

(0) Планируешь - делай! :-)

upadate
set val = 'вася'
from _1scons
where это мой периодический реквизит

(2) value :-)

(3) ну, что я вм, все константы помнить должен ?!
:)

(4) :-))

Update можно использовать только если точно есть такой рекизит, иначе надо делать insert.
Сначала у меня будет сформирована ТЗ с помощью выполнитьsql_из ТЗ, там может появится новая номенклатура, для которой цена не была задана.
Я так думаю что нужно сначала сделать Delete по данным из ВТ, потом  insert новых значений, без использования update.

может есть такой примерчик:
можно ли сделать 2-мя скриптами без использования курсора?

первый скрипт что то вроде такого:
delete from
_1sconst
Join #TempTab as Ceny
on _1sconst.date = Ceny.date AND
_1sconst.id = Ceny.id AND
docid = '     0   '

делаешь update, если роукоунт = 0 тогда инсерт. усё.

|UPDATE ...
|IF @@ROWCOUNT = 0
|   INSERT ...
©trad

так мне ВТ обходить через курсор тогда?

(11)Зачем?

ну так цикл же должен быть Update/Insert

(13) что в (10) непонятно?

например у меня 100 000 цен нужно поменять, чтобы блокировки не срабатывали на _1sconst загоняю в ВТ на скуле

(14) непонятно как прикрутить туда условие на пары из ВТ и потом поставить из ВТ новую цену

@@ROWCOUNT - относится к 1-му результата запроса, а мне нужно поставить разные цены разным номенклатурам в разные даты

(0) Нафиг этот гемор со штатной историей в 1sconst?!!
Сделай свою, нормальную.

какой тут гемор, цены номенклатуры - стандартный функционал?

(15) ВТ = это обычно виртуальная таблица...

(16) курсором обходи

(19) хреново он сделан в "стандарте"

(20) Delete старых  значений, insert новых без курсора не лучше с точки зрения производительности?

(23) ну разве что для самоудовлетворения...

ну вот я хочу понять что быстрее и правильнее

(25) если лопатить большие объёмы, и без блокировки - однозначно отказаться от штатного механизма, как минимум. Блокировка 1sconst - это даже хуже блокировки 1sjourn

сделай свои таблички, с какими надо колонками и индексами, и молоти их как удобно. так будет быстрее и правильнее :)

(26) справочник же? Эмуляция РС, а доступ на чтение - прямыми запросами...

+(26) 200% Полностью согласен!
1sconct это огромная клоака как и 1scrcdoc.

(27) Обычно справочниками и делаю. Но раз уж такая потребность писать туда что-то не из 1С, то я бы и таблички свои сделал.

А так, главное не 1sconst :)

(0) как то так:

update _1sconst
set value = Ceny.cena
from _1sconst
join #TempTab as Ceny on _1sconst.date = Ceny.date and _1sconst.id = Ceny.id and _1sconst.docid = '     0   '

insert into _1sconst
select
  .прочиеполя.
  Ceny.cena as value
  .прочиеполя.
from #TempTab as Ceny
left join _1sconst on _1sconst.date = Ceny.date and _1sconst.id = Ceny.id and _1sconst.docid = '     0   '
where _1sconst.value is null

+ в связях, разумеется, не хватает условия по objid
а также желательно добавить условия по time и row_id
и правильно привести цену к varchar

(31) большое спасибо как раз делаю по похожему примеру:
BEGIN TRAN

UPDATE t
SET t.Col1 = s.Col1, t.Col2 = s.Col2
FROM Target AS t
INNER JOIN Source AS s ON s.pkCol = t.pkCol



INSERT Target (Col1, Col2)
SELECT s.Col1, s.Col2
FROM Source AS s
LEFT JOIN Target AS t ON t.pkCol = s.pkCol
WHERE t.pkCol IS NULL

COMMIT TRAN

Нужно ли использовать конструкцию with (tablock),слышал что с ней insert быстрее ?

time - integer и вроде всегда 0.
Не пойму как сделать чтобы rowid присваивался автоматом инкрементно, какая то хранимка?
Тогда получается все равно курсор использовать...

(31) а зачем приводить цену к varchar?
1с++ вроде бы корректно обрабатывает numeric в отличии от com

М.б. использовать хранимую процедуру _1sp__1SCONST_MaxRowID? и от нее при insert делать increment rowid?
Нужно ли вручную перестраивать потом индексы?

(33) rowid - identity-поле его в инсерте упоминать не нужно. сервер сам его посчитает

(34) потому что _1const.value - типа varchar

(37) Спасибо огромное, буду пробовать!!!