v7: Как можно получить бухгалтерские итоги через прямой запрос 1С++ база DBF #500173

Утро доброе! Продолжаю грызть гранит науки! Собственно весь вопрос в теме данной ветки! На форумах пишут что в ДБФ это сделать не возможно. но может кто то сталкивался и решил подобную задачу. подскажите кто знает!

Утро доброе! Продолжаю грызть гранит науки! Собственно весь вопрос в теме данной ветки! На форумах пишут что в ДБФ это сделать не возможно. но может кто то сталкивался и решил подобную задачу. подскажите кто знает!

"На форумах пишут что в ДБФ это сделать не возможно" - это на каких форумах такое пишут?

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

Кстати, а как БЕЗ этого класса к бухитогам обратиться? Обычным прямым запросом то есть. Для примера, получить остатки по номенклатуре по кол-ву и сумме на определенную дату.

точнее пишут все примеры если СКУль стоит. именно для ДБФ ниче не находил

Давно-давно писал. Даж не помню - точно ли рабочий запрос. Работаем с регистрами. Set NoCount On Declare @НачДатаДляОборотов Char, @КонДатаПлюс1 Char, @НачКвартала DateTime Declare @ИдСчета Char, @ИдСубконто2 Char Select ID ИдСчета Into #Табсчетов From _1SACCS (NoLock) Where PlanID = 46364 And Left(SCHKOD,9) = '    1.  2' From ( --Итоги    Select SC0 ИдЦФО, SC1 ИдСубконто2, VSC1 ВидСубконто2, ACCID ИдСчета    Where ACCID In (Select ИдСчета From #Табсчетов (NoLock))    And [Date] = @НачКвартала And Kind = 1 --Сумма по аналитике    Where ACCDTID In (Select ИдСчета From #Табсчетов (NoLock)) --По дебету    And Date_Time_DocID >= @НачДатаДляОборотов And Date_Time_DocID <= @КонДатаПлюс1    And ACTIVE = '' And PROVKIND = '' And PlanID = 46364        Select KTSC0 ИдЦФО, KTSC1 ИдСубконто2, VKTSC1 ВидСубконто2, ACCKTID ИдСчета, -SUM_ Сумма    From _1SENTRY (NoLock)    Where ACCKTID In (Select ИдСчета From #Табсчетов (NoLock)) --По кредиту    And Date_Time_DocID >= @НачДатаДляОборотов And Date_Time_DocID <= @КонДатаПлюс1    And ACTIVE = '' And PROVKIND = '' And PlanID = 46364 ) Итоги Group By ИдЦФО, ИдСубконто2, ВидСубконто2, ИдСчета Drop Table #Табсчетов

И в чем именно сложность запросы под dbf переделать?

никакой принципиальной разницы нет.

только вчера с ними столкнулся... я пока не совсем понимаю чем они отличаются. понял что разница в названиях полей таблиц. и то не уверен что это так

Интересно... Спасибо. Надо будет изучить на досуге.

спасибо за ссылки подскажите что не так делаю! пишу запрос не могу получить остаток на дату. без условия по дате вываливает список по квартально, или по месяцам, в общем в каком то периоде. и получается после выполнения запроса я получаю не одну строку с остатком, а несколько строк по каким то периодам1 Что не так делаю?

вверх

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

Ужас ! На ккие ухищрения надо идти в 7.7 !!

сдается мне нужно куда то в условия капать?

сайчас условие такое стоит    |WHERE но на мой взгляд - это тот же х, ток в другой руке

Там выше пост под номером есть. Покури его чуток.

подскажите что такое (NoLock) и PlanID

(NoLock) - хинт для SQL. PlanID - идентификатор плана счетов.

додумался до дает ошибку FAILED! ICommandText::Execute: SQL: Aggregate on non-numeric expression. подумать дальше?

нельзя суммировать не числовые поля. кастани их перед этим.

+21 ну  и то, что этот запрос радугу покажет, тебе , скорее всего пофик..

Тоесть, скурить ты так и не хочешь?

что значит костантить? что за радуга? это пока все что вынес из

1.cast 2.На небе радугу когда нибудь видел после дождя ? Она тебе о чем нибудь говорит ? Нет ? Вот и твой запрос "ни о чем" в данном виде.

у Kind тип char ^)

А чем временные Бухитоги не устраивают?

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

Ёпрст3, Sadovnikov огромное вам спасибо. Разродился вот таким вот запросом. на серваке выполняется порядка 4-ех секунд.((( Буду рад критике, что то мне подсказывает что через задницу как то все работает в нем, раз так медленно. Что не так сделал? Раскритикуйте!

Это ж какая бухгалтерия должна быть что б появилась необходимость в прямых

- см. в у кого нибудь есть какие нибудь идеи по ускорению данного в запросе?

покажи план запроса

в смысле план запроса?

складывать числа человека не учили?

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

35 пипец еще онид умник

покажи план запроса.

pit'a на тебя нет

1,получаю из таблицы остатков остаток по счету на опред контрагента с момента начала ведения учета по последнюю дату последнего полного квартала 2,с начала квартала (начКвартала(ДатаНаКоторуюХочуПолучитьОстаток)) по ДатаНаКоторуюХочуПолучитьОстаток получаю оборот по дебету и кредиту, что бы получить актуальные по сегодняшний день остатки. как то так примерно я и мыслю. Это и есть план? что там со сложением? чесно говоря не чему меня не учили, все как то сам и если кто пожет. таки учусь предлогал я им терминал... молчат

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

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

+* 2 другие машины. и получается что 2 машины висят по 3 минуты, а если все 15 то повисаю мин 10-15. в общем сделал запрос и сменло идешь куришь а тут посоветовали что прямые запросы избавят от этого. но у меня сомнения. запрос из на серваке выполняется 4 секунды...

Вот шматок из отчета по сверке остатков, мот помогет

Давно бы блин учебник по 1с++ написали бы

|) AS DT,BaseMxBuh.dbo._1SENTRY ENTRY    |WHERE PROVKIND<>'D' AND DATE_TIME_DOCID BETWEEN '" + ДатаНач + "' and '" + ДатаКон + "' AND ACTIVE=' ' AND ACCKTID=DT.ID AND ( ENTRY.VKTSC0=3989 OR ENTRY.VKTSC1=3989 OR ENTRY.VKTSC2=3989 OR ENTRY.VKTSC3=3989 )    |) AS DT,BaseMxBuh.dbo._1SENTRY ENTRY    |WHERE PROVKIND<>'K' AND DATE_TIME_DOCID BETWEEN '" + ДатаНач + "' and '" + ДатаКон + "' AND ACTIVE=' ' AND ACCDTID=DT.ID AND ( ENTRY.VDTSC0=3989 OR ENTRY.VDTSC1=3989 OR ENTRY.VDTSC2=3989 OR ENTRY.VDTSC3=3989 )    |WHERE DATE='" + ДатаНачКвартала + "' AND ACCID=DT.ID AND ( BKTTL.VSC0=3989 OR BKTTL.VSC1=3989 OR BKTTL.VSC2=3989 OR BKTTL.VSC3=3989 )

ну как сказать, "вылизаны".... пример из опыта: штатный оборотный бухзапрос с отбором по субконто по одному субсчету за период работал 20 минут, переписаный на sql-запрос - 20 секунд. Не все замечательно там.

+46 ну сессно не dbf.

: даже и пробовать не буду. у меня давно все юзера работаю "на сервере", а что 1с-ина в сетевом режиме гонят бешенные объемы данных - так то проблема не бух.итогов. : да так и сказать. я старый человек, и прежде чем чтио-то делать - соотношу цену и результат. так вот ни разу(!) при использовании бух.итогов мне не встречалось случаев, когда бы разработка вместо штатных (и довольно корректно и быстро работающих) бух.запросов "овчинка" более быстрого получения тех же данных стоила "выделки" (трудозатрат на, между нами говоря, не такое уж простое, очевидное и легкое ваяние универсальных или не слишком универсальных прямых запросов). как-то так. : а у меня много где "ну ессно" именно dbf. так, между прочим.

так я под знамена не зову, у каждого это дело личное и можно сказать интимное. Некоторые считают приемлимым ждать 20 минут, другим и 20 сек много. Ну, а когда в месяц от (1.5 - 3.5) млн. проводок, то выбор очевиден :)

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

+ а писал эти бух запросы мой шеф!)

Хорошо, а поднять новелловский файл-сервер это в рамках? Или попробовать на 2003 сервере, если он там, конечно, есть, настроить кеширование?

что такое новеловский файл-сервер? как настраивать кеширивание тоже слабо представляю...

Прямые запросы к ДБФ не поддерживают виртуальных таблиц. Например, чтобы получить значение периодического реквизита там надо писать два запроса в запросе. Так же формат даты другой. Физические таблицы могут быть немного другие. Плюс многие команды не работают, или работают по другому. Например уложитьвсписок там надо делать через временную таблицу, а не параметр запроса.

я тоже как то пол дня писал простенький прямой запрос к ДБФ, а по итогу он работал дольше запроса, написаного на встроенном языке. Больше я к теме прямых запросов к ДБФ не возвращался.

"Если уж пошла такая пьянка", просветите плс по такому вопросу. В инете пишут, что можно писать прямые запросы к ДБФ без всякого 1С++, через АDO.Connection к провайдеру ФоксПро, а как тогда обходят отсутствие метапарсера? Или он там всё таки как то прикручивается?

Без метапарсера вполне можно обойтись. Писать select * from sc33 вместо select * from $справочник.Номенклатура не так уж и сложно... Работали же люди с радугой, когда 1с++ не было

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

И что? Различия dbf и sql давно описаны, стуктуры бух.таблиц тоже. Может, дело в соотношении радиусов? Смотря что нужно получить.

Данные получать - через metadatawork Итоги - руками запрос писать.

Тогда смысл теряется. Да и проще тогда препроцессировать запрос, выполнить через АДО, результаты в таблицу, откуда их примитивным запросом достать с типизацией. Но в общем-то, возникает традиционный китайский вопрос...

всё зависит от радиуса

можно еще ускорить.. в разы, если почитаешь Это ну или пиши на 1sqlite - там автоматический подбор индекса.

спасибо конечно за помощь, но да ну его в баню. в терминал будем переносить. если с обычным 1Совским кодом, при условии что 2 компа в сети выполняют один и тот же запрос, операция выполняется 2 мин 40 сек. то с прямым запросом время возрасло до 7 минут.

запрос не оптимизирован по индексу - вот и долго

так ради интереса буду пробовать подскажите как оптимизировать такой запрос.не могу разобраться с датой   |    SELECT                                |       Проводки.KTSC0 as Котрагент,

условие в части WHERE нужно достроить слева и справа до подходящего индекса, например до DATETIME

сделал     по времени тоже самое выполняется, если не дольше

ну как тебе сказать помягче.. х..ню сделал :)

+70 читай внимательнее, там всё написано и с примерами.

+71 вот этим провершь потом, посмотрев план запроса

а как по другому? вот эту строку  никак ведь не преобразуешь? (DTOS(Остатки.DATE) BETWEEN DTOS(:ДатаОстатковНач~~) AND DTOS(:ДатаОстатковКон~~))

покажи, какие индексы есть у 1SBKTTL у тебя.

#----Indexes------ # Name     |Descr         |Unique|Indexed fields                                              |DBName     I=ACC1     |              |0     |DATE,KIND,ACCID,SC0,SC1,SC2,CURRID                          |ACC1

тип того должно быть: where DTOS(Остатки.DATE)+Остатки.KIND+Остатки.ACCID+Остатки.SC0+Остатки.SC1+Остатки.SC2 +Остатки.currid between  DTOS(:ДатаОстатковНач~~)+' '+:СчетОстатков+:Контрагент+ '         '+'         '+'         ' And DTOS(:ДатаОстатковКон~~)+' '+:СчетОстатков+:Контрагент+ 'ZZZZZZZZZ'+'ZZZZZZZZZ'+'ZZZZZZZZZ'

+76 должно быть сделано Запрос.Выполнить("EXECSCRIPT('SET ANSI OFF')"); перед этим.

отбор по контрагенту не отрабатывает... вываливает весь список контрагентов. нужно соединение наверно делать? или опять я не туда?

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

-- Сальдо по 62 счету SELECT FROM (        БИ.Kind=1 AND БИ.Date=$НачалоПериода.Квартал(:ДатаКон) AND БИ.AccID=:Счет_62                Пров.Date_Time_DocID BETWEEN CONVERT(char,$НачалоПериода.Квартал(:ДатаКон),112) AND :ДатаКон~ AND Пров.AccDTID=:Счет_62                Пров.Date_Time_DocID BETWEEN CONVERT(char,$НачалоПериода.Квартал(:ДатаКон),112) AND :ДатаКон~ AND Пров.AccKTID=:Счет_62 HAVING    SUM(Остатки.Сумма)<>0

кг. это если понадобится остаток на дату в 3-ем месяце квартала, оно у тебя будет суммировать проводки за весь квартал, вместо того, чтобы взять готовые обороты из _1sbkttl или считать от начала следующего квартала это была реклама AccountsRecordset ;-)

AccountsRecordset - только для SQL я не понимаю почему автор отказался от использования класса "ПрямойЗапрос" :).

рано еще.. пусть научиться сам писать..руками. А то понимашь, приучают сразу к ВТ и прочим удобствам, а как и что и откуда берётся - не в зуб ногой :)

есть подозрение что около 80% пользователей v8 не очень то понимают что да как там организовано. И вроде не парятся. Им что ВТ, что доступ к реквизиту через кучу точек. :))))))

спасибо конечно. но не отрабатывает. такое ощущение что по данному контрагенту и счету нет данных

счет то какой хоть?

662.1 субконто1 - контрагент субконто1 - Спр.Основания если поледняя проводка была в 2009 г. на начало сегодняшнего квартала он ведь должен показать сальдо?

Есть подозрения, что 95% "программистов 1с" не понимают, "что да как там организовано" - что в 7.7, что в 8.х

чесно говоря не понимал. и вот только сейчас кое что начинает складываться

+ проблема с периодом

да нет проблемы там никакой, есть проблема в твоём непонимании, что хранится в табличке 1sbkttl

в ней хранятся(или расчитываются???%) остатки на начала квартала и текущие обороты по месяцам за текущий квартал в разрезе счетов и субконто. Правильно? Но вот нсли я получаю остатки на Like  DTOS(:НачДата~~). это означает что всем остаткам в таблице "нравится" НачДата - начало квартала искомой даты. но если почему же нет отбора? пустой отбор получается. как будто на начало этого квартала нет ничего? я слабо разбираюсь как в таком запросе задать условия отбора вот это - '_________' - означает что там пусто?

like , Прилагательное - подобный

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

мой ответ был на , а там запрос именно к sql в 80% случаев запрос с ВТ будет эффективнее, чем написанный в лоб запрос без ВТ при тех же затратах времени на написание. + запрос без ВТ сложнее. в чем профит?

Профит в 20%...

с вот таким вот условием:    | DTOS(:ДатаОстатковНач~~)+'1'+:СчетОстатков+:Котрагент"; все работает. правда скорость вообще никакая. для ускорения нужно добавить все индексы таблицы в условие DTOS(Остатки.DATE)+Остатки.KIND+Остатки.ACCID+Остатки.SC0+Остатки.SC1+Остатки.SC2 +Остатки.currid - это все индексы. делаю так:    |    WHERE и результат запроса становится пустым. то есть нет никаких данных с таким условием. в той ссылке написано: " если значение отбора не задано, то при установке параметра достаточно передавать '_________'" но не отрабатывает у меня...

я не утверждал , что с ВТ медленнее..:) Имхо, писать надо уметь что так, что эдак..