v8.1 Плиз , приведите пример запроса на T-SQL к регистру остатков "Остатки" (измерения=Склад,Номенклатура, ресурс=Количество)- получить актуальные итоги..(т.е. на текущий момент)
Спасибо большое

А зачем на 8.1 использовать СКЛ?

запусти Enterprise Integrator и трассирни запрос

up

dn
ответа так и не получил

А зачем на 8.1 использовать СКЛ?

(4,5) Есть один тяжеловесный процесс , который хотелось-бы реализовать на T-sql .
Хотите сказать , что на 8.1 все оптимизировано так , что в этом нет нужды ?
Спасибо

(6) Может, стоит показать запрос и поинтересовать можно ли его оптимизировать?

(7)То что процесс тяжелый - проверено , да и без проверки ясно. На складе есть некие емкости , в которых содержится товар (от 10 до 500 наименований). Емкостей около 500 штук. На склад поступают заявки от клиента со списком товара (в заявке около 3000 штук товара). Надо оптимизировать выбор емкостей со склада для отправки клиенту согласно определенным задаваемым критериям. Это я делал на Access (ADP)(сейчас перевожу базу на v8) - процесс один из самых тяжелых в базе. Так что вот хочется на t-sql сделать.
В профайлере запрос получил - смотрю. Хотелось бы примерчик или ссылочку на запрос к регистру остатков на T-SQL
Спасибо

(8) В 8-ке нет Toy-SQL.
Можно делать прямой запрос к SQL-базе, если знать имена таблиц (для этого есть методы)

(8) В смысле, вы хотите использовать процедурное расширение T-SQL, реализовав на нем сложные алгоритмы промежуточной итерационной обработки, чтобы не тянуть большие объемы промежуточных данных на клиента и обратно?
Это единственный вариант, когда вы можете получить существенную оптимизацию.
Я бы все-таки попытался оптимизировать алгоритм таким образом, чтобы избежать такой схемы. В большинстве случаев всё-таки можно извернуться с временными таблицами.

(9) помимо той-скл был еще т-скл он же транзакт-скл, придуманный микрософтом(или еще кем то)

+11 а той - это лишь аддон

полагаю большой глупостью использование T-SQL для чтения таблиц 1с8

(13) кажется также утверждали многие, когда появились той-скл, 1срр и т.п.
иногда надо

Регламентные задания!!!

Скорее всего можно оптимизировать запрос или структуру базы до приемлемой скорости !

(11) Я обычно встречал T-SQL как сокращение от тоя.
К (0) Пример не поможет, т.к. разные наименования SQL таблиц.
Если 8.1, то ПолучитьСтруктуруХраненияБазыДанных - там найти интересующую таблицу, а дальше самостоятельно.
Имхо.

(10) +
Как вариант, можно еще попробовать извернуться через СКД. Там в запросах вроде можно использовать пользовательские функции. Будет гораздо быстрее чем альтернативные варианты (хоть и не настолько быстро, как на T-SQL).
Ну и само-собой весь ваш тяжелый алгоритм должен отрабатывать на сервере, а не на клиенте (в серверном модуле).
В общем, T-SQL это крайний вариант. В большинстве случаев на приемлемую производительность можно выйти штатными средствами.

Речь не идет не о каких Toy-sql и т.д. - речь идет о стандартном Transact-SQL , (SQL Server 2005). Вообще практика показывает , что использование хранимых процедур повышает скорость работы, и иногда значительно...

Предлагаю написать алгоритм на языке 8-ки и потом его уже оптимизировать.

Обращаться напрямую к SQL базам 8.1 вещь полезная и кое в каких задачах даже необходимая. Например интеграция, синхронизация между различными базами, программами и т.п.
Если такие обращения нужны на постоянной основе, то рекомендую найти обработку "Просмотр метаданных 8.1" (ищется в инете на раз) и на ее основе сделать свою, которая генерит скрипт создания view для каждой таблицы в БД. А затем красиво обращаться напрямую к данным практически как в языке запросов.
Вот, например, запрос по остаткам выглядит примерно так:
SELECT
   N.Наименование Наименование,
   SUM(Кол)       Количество
FROM
(
SELECT
   Номенклатура Ном,
   Количество   Кол
FROM    IОстаткиНоменклатуры I
WHERE    I.Период = CONVERT(DATETIME, '2009-01-01 00:00:00', 102)

UNION ALL

SELECT
   Номенклатура    Ном,
   (1-2*A.ДБ)*A.Количество Кол
FROM    AОстаткиНоменклатуры A
WHERE    A.Период between CONVERT(DATETIME, '2009-01-01 00:00:00', 102) AND CONVERT(DATETIME, '2009-01-13 23:59:59', 102)
) O    
JOIN RНоменклатура N ON N.Ссылка = O.Ном
GROUP BY N.Наименование
HAVING (SUM(Кол)<>0)

(20)Спасибо , сейчас посомтрю. Обработку по просомтру метаданных я сделал.
Сейчас смотрю запрос , полученный в профайлере -Почему в запросе передает параметр {ts '3999-11-01 00:00:00'} - это типа "самая максимально возможная дата" что-ли ?

(21) Это актуальные итоги.

(22)спасибо, ясно, уже разобрался с этим
(алл) Каков смысл вот этих SUBSTRING ниже ? Спасибо
===============        
SUBSTRING(MAX(_InfoReg7_IR2._RecorderTRef + _InfoReg7_IR2._RecorderRRef), 1, 4) AS _MAXRECORDERTRef,
SUBSTRING(MAX(_InfoReg7_IR2._RecorderTRef + _InfoReg7_IR2._RecorderRRef), 5, 16) AS _MAXRECORDERRRef

(23) По-моему нет смысла долбиться напрямую. Если только делать UPDATE.
Кардинального ускорения врядли получится получить, а вот поддержку такой конфы осуществлять сложнее.

(24) Я думаю , что сначала сделаю все на 8-ке , а потом посомтрю - если производительность не будет удовлетворительной , то буду дорабатывать. При том сделанные запросы пригодятся - посредством профайлера легче будет писать SQL-ные. При том в устройстве регистров еще надо будет подробнее разобраться.
Подскажите , плиз , почему если мы например создаем измерение типа "Документ" в регистре накопления , то в основной таблице регистра и в таблице итогов создаются три поля :
1)__Fld333_TYPE , binary(1)
2)__Fld333_RTRef , binary(4)
3)__Fld333_RRRef , binary(16)

? Для однозначной идентификации ? Разве нельзя будет однозначно идентифицировать по полю __Fld333_RRRef , binary(16) ?  Может кто нибудь объянить поподробнее , что это за поля 1) и 2) ?(может ссылку какую дадите; насколько понимаю - __Fld333_RTRef - это тип регитсратора (?)- но для чего его вводить , разве __Fld333_RRRef не будет однозначно идентифицировать регистратор ? )
Спасибо большое.

(23) Очевидно, получение координат регистратора (типа и ссылки). Почему именно так - мне отсюда не видно (вы же не привели полный текст запроса).
(25) TYPE - идентификатор типа данных, RTRef и RRRef  - это если тип данных агрегатный. RTRef - по сути номер таблицы, RRRef - ссылка в ней.
Такая хрень городится для составных типов данных.
Если тип - ссылка на конкретный вид дока, будет создаваться только одно поле (RRef).

(26) +
Самая жесть, если составной тип данных может содержать примитивные типы.
Тогда к перечисленным трём полям добавляются дополнительные поля по количеству примитивных типов (соответствующих типов).
Поэтому не рекомендуется использовать подобные измерения регистров (составные с примитивными типами). Потому что с таблицами итогов веселуха начинается, а особенно с индексами. Но на регистрах накопления еще куда ни шло.
Вот с бухгалтерскими итогами полная торба происходит - там это категорически не рекомендуется (добавлять в план видов характеристик для субконто примитивные типы).