v7: Прямой запрос: Syntax error #709213

delete from     ra4674 as Рег where     Рег.sp4671 in ( select Жур.iddoc from      1sjourn as Жур ...ТЕЛЯ.ERT}: FAILED! ICommandText::Execute: Syntax error. где? (ибо неграмотен). спсб.

Так работает? SELECT * from     ra4674 as Рег where     Рег.sp4671 in ( select Жур.iddoc from      1sjourn as Жур where  (Жур.iddocdef = ' 1W9') )

а проще если? Жур.date >= 01.07.11 and Жур.date < 01.01.12

from     ra4674 as Рег where     Рег.sp4671 in поменяй на from     ra4674 where     ra4674.sp4671 in либо from     ra4674 where     sp4671 in

from      1sjourn as Жур   а должно быть _1sjourn as Жур

Это DBF

Если уж выепывотся то по полной ...

У тебя же есть скллайт?

сколько спецов столько блин мнений...

не ругнулось, ушло на выполнение

мне кажется в датах накуярил, туплю что-то, давно с дбф не возился

ошибка получается где-то вкуске . and           (dtos(Жур.date)+Жур.time+Жур.iddoc

и что? все спят?

Я ж написал как в случае склайт idx_date_time_iddoc

у мну на VFP выполняется вроде как...

в VFP вроде так BETWEEN(field,low value, high value)

сейчас попробуем... хотя в других местах вроде работало так как записано (?)

вот так выполняется     | between(dtos(Жур.date)+Жур.time+Жур.iddoc,dtos({d '2011-07-01'})+'      '+'         ',dtos({d '2011-08-30'})+'ZZZZZZ'+'ZZZZZZZZZ')

вот так выполняется все ок вроде .     |where     $Рег.ЗаявкаПокупателя in . если изменить на удаление .     |where     $Рег.ЗаявкаПокупателя in . - ругается syntax error..???

Пишите еще!! ушел домой, приду почитаю!!!

спсб. вот так вот прошло . А почему не проходит delete from     ra4674 as Рег where     Рег.sp4671 in .. ?

и дальше: вот удалил движения по регистру, теперь хочу удалить точно также тупо записи с итогами Простой заменой в этом работающем запросе $Регистр на $РегистрОстатки получаю "бешеный" запрос, который вываливается с ошибкой (ну и фиг с ней) . чисто для примера . delete from     ( select rg4674_vt.sp4668 as Фирма, rg4674_vt.sp4669 as Номенклатура, rg4674_vt.sp4670 as ДоговорПокупателя, rg4674_vt.sp4671 as ЗаявкаПокупателя, rg4674_vt.sp4672 as КоличествоРасходОстаток, rg4674_vt.sp4673 as СтоимостьРасходОстаток from rg4674 as rg4674_vt (nolock) where rg4674_vt.period={d '2014-05-01'} select rg4674_vt.sp4668 as Фирма, rg4674_vt.sp4669 as Номенклатура, rg4674_vt.sp4670 as ДоговорПокупателя, rg4674_vt.sp4671 as ЗаявкаПокупателя, rg4674_vt.sp4672 as КоличествоРасходОстаток, rg4674_vt.sp4673 as СтоимостьРасходОстаток from rg4674 as rg4674_vt (nolock) where rg4674_vt.period={d '2014-05-01'} ) ) as ЗаявкаПокупателя in ( select Жур.iddoc from      1sjourn as Жур between ( ) ) Запрос.ВыполнитьИнструкцию(ТекстЗапроса); ...ЛЯ.ERT}: FAILED! ICommandText::Execute: Syntax error.

. вот так: delete from     ( select rg4674_vt.sp4668 as Фирма, rg4674_vt.sp4669 as Номенклатура, rg4674_vt.sp4670 as ДоговорПокупателя, rg4674_vt.sp4671 as ЗаявкаПокупателя, rg4674_vt.sp4672 as КоличествоРасходОстаток, rg4674_vt.sp4673 as СтоимостьРасходОстаток from rg4674 as rg4674_vt (nolock) where rg4674_vt.period={d '2014-05-01'} select rg4674_vt.sp4668 as Фирма, rg4674_vt.sp4669 as Номенклатура, rg4674_vt.sp4670 as ДоговорПокупателя, rg4674_vt.sp4671 as ЗаявкаПокупателя, rg4674_vt.sp4672 as КоличествоРасходОстаток, rg4674_vt.sp4673 as СтоимостьРасходОстаток from rg4674 as rg4674_vt (nolock) where rg4674_vt.period={d '2014-05-01'} ) ) as ЗаявкаПокупателя in ( select Жур.iddoc from      1sjourn as Жур between ( ) ) ...ЕЛЯ.ERT}: FAILED! ICommandText::Execute: Syntax error. . фиг с ней с ошибкой .

итоги - это $РегистрИтоги

Собственно вопрос: вот оттранслированный запрос на удаление, все ок delete from     ra4674 where     sp4671 in ( select Жур.iddoc from      1sjourn as Жур between ( ) ) . как получить (нормальной записью с 1с++) аналогичный запрос, только во второй строке чтобы было не from ra4674 //движения а from rg4674 //итоги . ??? . понятно, что можно написать впрямую, что сейчас и планирую забульбенить, но хотелось бы с использованием метаимен как-то...? (вот тупо удалил rg4674 - все получилось как хотел...)

точно!! ты великий колдун!!! а регистр Остатки - это получается виртуальная таблица (я правильно выразился)..?

да, я такой да, Остатки - это ВТ, но в dbf не поддерживается

вот еще вопрос: . работающий запрос на удаление движений: . . все понятно, но он - "неправильный" - ставишь период побольше - и 1Ска сжирает памяти под гиг и вылетает (вложенный селект как я понимаю). . собственно - как написать "правильно" - чтобы запрос хренячил с датаН по ДатаК - ПОРЦИЯМИ...?

Вопро снепринципиальный - работа разовая, переколбашу "ручками", но просто инетересно

..вот почему я туп в прямых запросах. ленивый потому что. нужны они весьма эпизодически, поэтому и въезжать лень (да и стар ужо ;-) . вы кто по запросам помогает мну регулярно - как в МСК будетет - хоть объявитесь, посидим пива попьем, проставлюсь за помогалки.

Класс ПрямойЗапрос поддерживает и в dbf

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

Всем спасибо (но я еще вернусь, так просто вы меня не отделаетесь ;-), полез в ванну и спать, через неделю запуск большой WMS, вся жпс в мыле ;-)

классу ПрямойЗапрос уже не мало времени, очень серьезная разработка, да есть косяки но куда без них, мне очень нравится на нем писать, удобно. А главное что и для скл и для дбф почти одинаково все.

+34 И за доку к классу автору отдельный респект и уважуха.

так попробуй

угу, я смотрел его. тоже понравился. по кранйе мере осовив - будет будобно привыкать к 8-ым запросам ;-) 9если я когда нить до снеговика доберусь)

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

отличается индексом как мне помница, в vfp, для того чтобы работал составной индекс, нужно писать выражение этого индекса

+ выражение - вот это: Жур.iddocdef+dtos(Жур.date)

можно вмешаться с левым вопросом, а IN (...) и INNER JOIN ... одно и тоже или в дбф нельзя?

не одно и тоже но эту задачу, например в t-sql можно было бы решить и через inner join а в vfp - нет, синтаксис delete несколько другой, судя по документации (могу ошибаться, vfp у меня знания только теоретические)

понятно, все равно спс, последнее время тож прямыми увлекся, писать не удобно))) но использовать нравится

+ в vfp9 тоже можно через join

правда пользую исключительно select, до update, delete не вырос (ссыкотно как то)

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

не-не не.. лучше уж по индексу doctype бегать: IDDOCDEF+DTOS(DATE)+TIME+IDDOC

Хотя не ясно, чегой-то моя конструкция в у Чебура ошибку вообще выдает.

ну и да, с индекс нужно было не acdatetim использовать, а doctype , писал на коленке

там нет такого индекса

Не совсем понял смысл условия (dtos(Жур.date)+Жур.time+Жур.iddoc between ) ведь если вам нужно все документы за определенный интервал дат, не касаемо позиций документа в течение одного дня, то зачем городить огород с dtos(Жур.date)+Жур.time+Жур.iddoc Просто сделайте BETWEEN для поля Жур.date и в выборку попадут все документы за выбранный интервал дат.

Спасибо, просветился. Так вам надо что бы не только правильно но еще и быстро :). С дбф сталкивался последний раз лет 5 назад. Сейчас все как-то на скуле.

ну так я его и имею ввиду выражение же является _стартовой_ частью ключа, или VFP этого не сечет?

надо бы проверить, как нить (обычно всегда достраивал до "целого" индекса, даже не думая) :)

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

ну, снимать rf и не обязательно :) ну будет там галка.. самих движений то нема..

+57 ну и в табличке итогов, автор тоже хочет прибить все записи с этим измерением. Их тоже, пересчитывать не обязательно будет

обязательно 1.при перепроведении документа будут проблемы 2.ну и как бы без этого нарушена структура бд прочел внимательно 58 тогда после удаления у этого документа может остаться движения по этому регистру если их было несколько. т.е. нужно правильно расчитывать этот флаг rf. (из 0 я считал  что хочет удалить все движения за период ). PS ну да еще вроде есть поле appcode в котором храниться общее число движений и проводок документа это поле тоже желательно при subj корректировать. Вообщем чтобы все было ок надо тщательно разбираться во всех деталях

1. Ну, какие например проблемы ? примерчик бы..

Да на флагдвижения и апкоде.. можно вообще начихать и забыть :)

базу(даже тестовую) корежить не буду так что примера не будет. просто валиться 1с при пероведении документа( речь об sql версии ) - как бы из-за таких проблем и был написан отчет проверка регистров. не знаю может когда есть или нет УРБД 1с ведет себя по разному особено при подгрузке документов и самых движений вот тут то и нужны и appcode и rf

Не appcode (там флаги, в каких подсистемах участвует документ), а  actcnt (action count) на rf можно реально начхать. хотя при ТиИ будут диагностка, что "количество движений не соответсвует заявленному" структура БД в принципе не нарушается (логическая целостность только, да и то - условно) да ничего не валится. Ни с УРБД, ни без нее.

не-не-не.. проверено, не валится (по крайней мере, на дбф это вообще ни на что не влияет На счет уриба, не скажу с -ходу :)

ну да, счетчик движений, на него тоже можно положить :)

Только те, кто лезет вот так вот в кишки - уже практически не пользуются штатной ТиИ

В общем, я никогда спецом 1sjourn Не правил (один раз только "красоту наводил", но потом, как то подзабил на это, совсем)

на сиквеле тоже ничего не падает.

Ну .. штатную ТиИ можно конечно делать, только не на всех табличках, а только нужных, так.. для забавы :)

подменяя остальные таблички "пустышками"

а что ты хочешь этим достичь? :-) основная проблема с регистрами - так это решается контролем и выборочным пересчетом итогов...

ну да    actcnt  пишу по памяти. чихать на rf можно не всегда если по каким то причина  rf = 0 и есть движение то произойдет следущее при проведении движение не удалиться и при вставке движения 1с валится при insert ( если по новым данным документа нужно движение по этому регистру). по твоей логике поля rf вообще не нужны. ну вообщем каждый сам себе решает тщательно или не тцательно нужно разбираться в деталях когда делаешь что-то типа subj.

на счетчик движений тоже класть нельзя в 2009 или в 2010 году на 1сpp ветка на 66 страниц и там у товарища были большие проблемы с базой в том чиле и из-за неправильного счетчика, только достигал он нарушение целосности базы при проведении одного документа из модуля другого документа а в subj мы сами себе кладем грабли

для 68

запись движений "снаружи" - достаточно редкий случай. Я такое только у Садовниковва видел. а в иных случаях, как у ТС - будет строго наеборот: флаг стоит, счетчик не пуст, а движений нуль. А насчет ССЗБ - согласен. "каждый - сам кузнец своего геморроя...."©

прочитал. впечатлился. задумался. герои - среди нас. изначально все задумывалось для тотального уничтожения заявок клиентов за период большой. штатно - практически нереально. . теперь когда подчищаются все движения с заявками покупателей (а это ТиС, Регистр.ЗаявкиПокупателей, Регистр.ОстаткиТМЦ) - сами заявки можно и не удалять. Тем более что при перепроведени документов они у меня не перепроводятся. . так что все должно быть чики-пуки. . спасибо. . пишите еще - буду черпать из неисчерпаемой кладези мудрости (пока мудрецы-аксакалы живы, 8-ков таких глубококопателей - ваще наверное нет... расстраивает меня 8-ка и программеры на ней с которыми встречаюсь... как-то не могут они сделать также красиво как я на клюшках... зашорены они вдребезги попалам. расстроен я... ;-)

Я тоже делал движения скулем...

в 77, разумеется

как-то сомнительно... в журнале заявлены вот такие индексы #----Indexes------ # Name     |Descr         |Unique|Indexed fields                                              |DBName     I=IDDOC    |Id Doc        |0     |IDDOC                                                       |IDDOC       I=ACDATETIM|Date+Time+ID  |0     |DATE,TIME,IDDOC                                             |ACDATETIME I=DOCNO    |Prefix+No     |0     |DNPREFIX,DOCNO(UPPER)                                       |DOCNO       I=DOCTYPE  |Type+Date+Time|0     |IDDOCDEF,DATE,TIME,IDDOC                                    |DOCTYPE     I=JOURNAL  |Journal+Date+T|0     |IDJOURNAL,DATE,TIME,IDDOC                                   |JOURNAL

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

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

фиг его знает это ЧЯ? удалял за полгода - картинка была такая, сейчас запустил на 2 года - загрузка под 100%... нипанятна... . шарашить будет где-то минут 20-25

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

во, ваще отбабахало за чуть больше 10 мин...

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

состав индексов можно посмотреть и в dd, реальное выражение нужно смотреть в спец редакторе либо текстовый редактором посмотреть cdx

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

отличается индексом Давай немног по другому Предположим  у тебя в базе 1000 000  документов И всего  10  документов заявкапокупателя В случае 26  будет перебор из милионна документов В случае 36  будет перебор из 10  документов trad  все это написал но  может не очень понятно для тебя Твой вопрос очень важный и если поймешь отличия 26  от  36  то сможешь  писать более оптимальные запросы

не, это-то понятно. Непонятно почему перебор отжирает столько памяти в случае он что - сначала выбирает всю выборку, фильтрует ее по условиям, а потом по полученной подвыборке начинает делеты делать? или как..?