alex_71
-
Публикации
26 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем alex_71
-
-
Еще раз обращаюсь с вопросом: Как из отчета изменять таблицы базы данных, если она в SQL формате? Я так понимаю, что запросы вида:
<~SET_SQL_PROG:_________ ~>
работают только на выборку, на изменение данных их не вывернешь. А вот конструкция вида:
<~MACROS:SET_SQL:___________~>
позволяет применять insert, update и др. Я знаю как это сделать в формате PARADOX, но какие закорючки надо поставить в предложении запроса, чтобы он обратился к конкретной таблице в какой-нибудь BASE.GDB – для меня загадка
Вопрос не праздный Профокна, хоть и халявные, но возможности огромные, в том числе - это программа сетевая. А если сетевая – д.б. SQL версия. И я хочу, к примеру, чтобы менеджер, работая в общей сети, запуская отчет, из него определял трудоемкость исполнения заказа и с учетом производственной мощности цеха устанавливал бы в таблице tListPrj реальные сроки изготовления.
Таблицы которые ты указываешь в запросах берутся из текущей базы(она написана внизу окна). Если запрос работает в программаторе просто перенеси его в отчет - должен работать.
-
Привет знатокам Профокон и любителям SQL запросов!!! У меня вопрос: есть ли возможность в Профокнах с базой в SQL формате модифицировать таблицы (SQL операторами insert, update)? Если кто об этом знает - покажите пару приемов.
Все это можно делать, в том числе и создавать свои таблицы. Запускаешь SQL-программатор и экспериментируешь в нем.
-
и всётаки, кто-нибудь знает, как прописать ограничения в размерах для глухой створки или для стеклопакета? Причом и максимум и минимум. Хотя, максимум прописала в комплектующих, по длине бруса. А вот минимум куда?
Мне кажется, что можно только сделать обязательную вставку в стеклопакет с предупреждением или сообщением. Но в этом случае придется прописать эту вставку в каждый! стеклопакет .
-
В системе есть створки поворотные, поворотно-откидные. Они прописаны и имеют разное обозначение на чертеже. Теперь необходимо добавить новый тип - откидное. Которое должно иначе обозначаться. Как это сделать?
Дык в описании сторон фурнитуры ставишь на 1-ю сторону "Ось поворота с петлями", на остальные "стандартное", сторона ручки 3 (хотя у меня во всех фурнитурах почему-то 2). Или ты о чем-то другом спрашиваешь?
-
В результате окно с рисунка маркируется как: ПО/ГЛ/ПВ
ОБАЛДЕТЬ! Сколько же ты разрабатывала и отлаживала все это? Да и сам текст отчета тоже наверно ого-го?!
Подскажи, пожалуйста, такую вещь. А ты не пробовала определять створки по заполнениям: т.е. проходим по заполнениям, смотрим какой профиль внизу, если створка - смотрим открывание. - или это тупиковый путь?
-
Алгоритм...
Берём окно, из таблицы соединений находим углы и соединения импост-коробка, анализируем по координатам, количество створок. Затем в нужном нам порядке просматриваем створки. Если к ним прикреплены створки-форточки, то через запрос к таблице фурнитуры определяем пворотность и записываеи её в формулу. Ну вот, примерно так.
Не совсем понял. У тебя во всех проемах створки, даже глухих? Створки ты просматриваешь по какой таблице и как определяешь наличие створки-форточки (кстати, что ты под этим понимаешь). Если можно выложи картинку с окном и перечнем его створок.
-
Ну вот. Кажется, заработало! А вы говорили, невозможно
Считаем теперь поворотность, в нужном порядке.
Спасибо всем за помощь
Поздравляю! Поделись, если можно, алгоритмом.
-
1) понятия не имею, но сегодня утром пришла, включила и всё заработало
2) можешь пояснить свой запрос? Команды left join я ещё где-то встречала, это соединени, но к каким таблицам ты обращаешься я разобраться не могу. Точнее, понятно к каким, но как?
1) А ты в программаторе смотрела таблицу соединений когда не получалось? там они были?
2) Значит так. Беру таблицу tSpecZlt (заполнения изделия) по полю aName привязываю к ней tArticls, по полю clNum таблицу tColors, сортирую все это по типу заполн, назв , цвету. В результате вывожу список заполнений в порядке (стекло, с/п, сэндвичи), назв по алфавиту, цвета по алф.
конструкцию left join применяю для однозначности заполнение -> соотв ему название и цвет. Т.е. берется запись из табл заполн и ищутся соотв ей записи в артикулах и цветах. Причем запись будет в результирующей таблице даже если нет соотв артикула или цвета. Это перестраховка, но все таки. Как использовать другие способы соединения не знаю. Такую конструкцию использую со времен работы с Access. Я и сейчас конструирую запросы с его помощью, там все проще и наглядней.
-
У меня как раз "3". Это уже не важно. Сегодня работает
А не было ли у вас необходимости писать запрос к нескольким таблицам? Это вообще поддерживается?
1.А в чем была заковырка? Почему не работало.
2.Запрос писал и он работает:
<~SET_SQL_PROG:select tartikls.aname, tcolors.clnam,zleng,zheig,nzapl,zpoin,zqtyz,tspeczlt.atypp,tspeczlt.clcod ~>
<~ADD_SQL_PROG:from (tspeczlt left join tartikls on (tspeczlt.anumb=tartikls.anumb) and (tspeczlt.pnumb=tartikls.pnumb)) left join tcolors on tspeczlt.clnum=tcolors.clnum ~>
<~ADD_SQL_PROG:WHERE (ounic=:^izd:) order by atypp,aname,clcod~>
он делает выборку заполнений в нужном мне порядке.
-
Изделие без угловых соединений - это нонсенс
Почему без угловых, наверно у тебя там соединения типа 2 (рез по биссектрисе)?
-
Спасибо. Рада, что хоть кому-то это всё доставляет радость.
Повеселю ещё
Запрос проще некуда, но не работает. Посмотрите, пожалуйста, со стороны:
<~SET_SQL_PROG:SELECT DISTINCT nE1 FROM tSaveCon~>
<~ADD_SQL_PROG:WHERE (pUnic=:^pUnic:)~>
<~ADD_SQL_PROG:AND(oUnic=:^oUnic:)~>
<~ADD_SQL_PROG:AND(typ=3)~>
<~LOOP_SQL_PROG~>
<~PROG:#nE1~>
<~END_SQL_PROG~>
А может там и нет данных удовлетворяющих твоему условию, у меня на твоем запросе именно так. Проверить можно в SQL программаторе ( кстати там же можно проверить запрос - сразу видно работает или нет, только надо задать конкретные punic и ounic) или запросом
<~SET_SQL_PROG:SELECT DISTINCT count(nE1) as cc FROM tSaveCon ~>
<~ADD_SQL_PROG:WHERE (pUnic=:^punic:) ~>
<~ADD_SQL_PROG:AND(oUnic=:^ounic:) ~>
<~ADD_SQL_PROG:AND(typ=3)~>
<~LOOP_SQL_PROG~>
кол-во=<~PROG:!cc~>
<~END_SQL_PROG~>
-
Возникло ещё несколько вопросов. Если кто знает ответы, хотябы на некоторые, помогите.
1) Есть ли в отчётах ограничение на количество запросов?
2) Есть ли в SQL - запросах ограничение на количество условий?
3) Есть ли возможность работы с массивами числовыми? Если есть, то как?
4) В отчёте пишется SQL-запрос. Он работает правильно. Затем пишется следующий запрос, не вложенный, просто следующий, даже не используются результаты предыдущего. В результате ничего не работает и ошибка в старом . Удаляется новый запрос. По-прежнему, ошибка в старом. С чем это может быть связано?
5) Как писать запросы к нескольким таблицам? Обычно обращение к полю в таком случае идёт как [имя поля].[имя таблицы]. Но так не срабатывает.
1) Насколько понимаю-нет. Чем больше одновременно открытых запросов тем больше требуется памяти, если ее не хватает система начинает работать с диском а это сильно тормозит работу. Например расчет большого заказа (много типов окон) у меня длился ~15мин. При этом прога как-бы зависает
2) По моему нет, но все должно быть в разумных пределах. Кстати, что по этому поводу говорит "SQL для профессионалов" ?
3) Не знаю. Никто об этом не упоминал и в отчетах нигде такого не было
4) Это полтергейст . Выложи текст, тогда можно будет что-то сказать.
5) по моему пишется наоборот [таблица].[поле]
-
Вопрос по запросам.
Пишу так:
<~SET_SQL_PROG:SELECT DISTINCT xyx FROM tSaveCon~>
<~ADD_SQL_PROG:WHERE (pUnic=:^pUnic:)~>
<~ADD_SQL_PROG:AND(xyx=(SELECT MIN(xyx) AS qwer FROM tSaveCon WHERE (xyx>=0)AND(xyx>ugol)AND(pUnic=:^pUnic:)AND(oUnic=:^oUnic:)))~>
<~ADD_SQL_PROG:AND(typ=4)~>
<~LOOP_SQL_PROG~>
ugol - переменная. Вообще, её надо бы получить из другого запроса, но это другой вопрос...
А то, что есть пока не работает Ругается именно на этот запрос.
Неужели нельзя сравнивать с переменной? До её введения всё работало.
Ты переменную в запросе укажи как и номера изделия и проекта, т.е. (xyx>:^ugol:).
А зачем тебе список координаты х для импостных соединений. Кстати с перечислением открываний ты разобралась, потому что вопрос мне тоже интересен.
И еще. У тебя конструкция запроса больно завернутая, неужели нельзя это сделать без вложения? Ты вообще с SQL инструкциями разбиралась по книге или в сети. Я в сети нашел описания только по простым запросам без вложения как у тебя, а надо именно такое. Если есть ссылки поделись.
-
Спасибо за помощь...
Мда... Нужно вывести всего то одну строку... И так заморачиваться просто не вижу смысла.
А может профиль можно определить иначе? Ладно, попробую ещё, не получится и ладно, будут вручную забивать... Вместе с маркировкой
Если что-то получится напиши. Кстати, что такое minta - просто преременная(параметр) или какое-то поле из таблицы
-
Смотрите:
Пишу так:
<~IF:minta="LEITZ / Sosna":GOTO:kosmos~>
Ты столкнулась с той же проблемой, что и я - нвозможность использовать строковые константы. Долго бился на этой проблемой и вот после твоего вопроса пришла мысль: создать таблицу с необходимыми строковыми значениями, а потом ее использовать. Последовательность такая:
1. Создаем таблицу в программаторе
CREATE TABLE param (txt char(30), kod integer)
2. Заполняем таблицу строковыми значениями и присваиваем им уникальные коды. У меня .GDB база и я это делал в MS Access. Базы .db он только просматривает, поэтому придется использовать что-то другое - под Win98 работает WB Expert. В программаторе эта таблица не просматривается только просматривается запросом select * from param.
3. Для проверки значения делаем запрос с выборкой по значению, присваиваем код из выборки переменной, закрываем запрос, проверяем код. Либо вначале отчета делаем выборку всех значений, присваиваем переменным нужные, а потом где необходимо сравниваем значения переменных(параметров)
Пример программы с выборкой значения по коду
<~!--Задаем код --~>
<~!x=0~>
<~!--Делаем выборку по коду --~>
<~SET_SQL_PROG:SELECT txt FROM param WHERE (cod=:^x:)~>
<~LOOP_SQL_PROG~>
<~!--Присваиваем строковое значение переменной --~>
<~@st=PROG_txt~>
<~@st~>
<~!--Закрываем выборку --~>
<~END_SQL_PROG~>
Метод извращенный, но ничего проще я придумать не могу. Теперь буду думать стоит-ли та заморачиваться или просто отказаться от использования строковых значений
-
...поконкретнее можно ?
меня интересуют функции для работы со строковыми значениями типа len(), left() и т.п. , можно ли параметру присвоить строковое значение например <~@st='какая-то строка'~>, как сцепить два строковых значения.
-
А последние два вопроса. Не уж-то мне не суждено получить на них хоть какой-нибудь ответ?
-
Так Цену в отчете к ИЗДЕЛИЮ на позиции вывести не получится там какя то шняга выходит. К проекту получится.
Не понял это предложение. В твоем же отчете все выводится .
Вопрос вдогонку. Сумма которая получается по отчету не зависит от способа расчета проекта (хлыстами, отход в мм, отход в %). Получается что считать надо как-то по другому ( возможно предварительно рассчитать коеф - хотя это бред).
И еще вопрос. есть какое-либо описание полей в запросах LOOP_SPEC_SUM и других.
Еще вспомнил. А по функциям которые можно применять в отчетах ничего не знаешь? А то я уже два раза писал - а в ответ тишина
-
<~LOOP_SPEC_SUM~> чтобы суммировались в одну строчку одни артикулы
А профиль как?
-
Пытаюсь сделать отчёт в котором были бы прописаны комплектующие, сколько их пошло на изделие и сколькони стоят.
Но цыфры не сходятся. Например, стоимость единицы шпатлёвкт 221,24р. К тому же считается через раз. В чём дело? Или так всё и считается? Но тогда цена итоговая не верна...
И как сгрупировать, чтобы в отчёте выводилось только одна строчка для каждого артикула?
Думал над похожей проблемой мысли следующие:
- несколько строчек на один артикул из-зи способа расчета спецификации - если убрать галочку в настройках "Спецификация профилей и пакетов для сборки" то мерные комплектующие суммируются (не всегда). Чтобы полностью суммировать кажддый артикул - надо это делать вручную (см. отчет "Расход материалов", там также прописан расчет цены с учетом коеф. только всех или нет не вникал)
- ну а цифры несходятся из-за округления. судя по всему программа округляет до 2-х знаков и если сумма 0,004.. или меньше, то после округл 0,00 а поскольку точность у тебя стоит 4 знака выводит 0,0000.
-
Вопрос по отчетам. Как присвоить строковому параметру (переменной) значение. Типа
<~@str='текст'~>. Как сцепить одно строковое значение с другим. <~@str=@str + ' текст2'~>.
Есть ли какие-нибудь функции для работы со строками LEFT(n,@str), MID(pos,n,@str), LEN(@str) и т.п.
-
надо прописывать раскладку как ПЕРЕПЛЕТ. Тип в комплектующих создаешь, и определяешь их в допустимые артикулы в системе профилей. Потом втавляешь как импосты, но ставишь галочку "ПЕРЕПЛЕТ" он вставит, но заполнение не разделит как импост, двигаешь как надо . Так и создаешь лучевую (фальшпереплет или раскладку внутр.) но в соединениях тоже придется описывать их.
А чем переплет оличается от поперечины? У Доминатора фальшпереплет сделан поперечиной (и, кстати, типовое окно похоже на твое). И чем отличаются типы профилей поперечина, внутр.переплет, наружн.переплет?
-
Появились еще вопросы.
1.Как в арочный пакет поставить раскладку в виде 3-х расходящихся лучей.
2. Если раскладку рисовать поперечинами, можно-ли сделать чтобы в закуазе на с/п это как-то отражалось?
3. Что такое переплет?
-
Спецификация ПВХ.
Здравствуйте всем. Пишу первый раз, поэтому прошу простить если что.
Хочу перейти на ПО с бесплатной проги от КВЕ. С ПО(Профстроем) работаю давно но по алюминию (МОСМЕК, Виднал). Проблема в том, что сборщиков в цеху не устраивает спецификация на изделие. В КВЕ-шной профиль выводится группами (сначала вся рама, потом арм. к ней, потом импост, арм.импостов, створка, арм створки и т.п.) при этом указывается где заготовка данного размера ставится! Т.о. сборщику понятно какой кусок армирующего в какую заготовку ПВХ. В ПО профиль тоже группируется и выводится по типам, НО нет явной связи армирующий - пластик. Если профиль выводить без сортировки (как он записан в tSpecPau) то профиль выводися по типам, при этом армирующий вперемешку - соответственно нет четкой связи - как хошь так и догадывайся какой куда, а ведь на раму и створку один армирующий.
Если сохранять "Спецификации профилей и пакетов для сборки", то в спецификации прописываются номера элементов и их можно вытащить, но как при этом суммировать одинаковые заготовки и записывать их номера? Например "1,3,5,7 - арт.707 - углы - 4шт".
Извините за сумбурность, но если интересно постараюсь объяснить понятней.
Вопрос связанный с предыдущим.
Какие существуют в отчетах способы для преобразования чисел в
строковые значения для записи в параметры(переменные) и как
сцеплять строковые значения. Например из "деталь" и "3" получить
"деталь 3". Только не надо советовать просто вывести их
последовательно, нужно именно сцепить и присвоить значение
параметру (переменной)!
Еще вопрос.
Для чего в списке полей спецификации (в генераторе отчетов) есть
поля АРМИРОВАНИЕ
(<~СПЕЦ:АРМИРОВАНИЕ:АРТИКУЛ~>,<~СПЕЦ:АРМИРОВАНИЕ:ДЛИНА~> и т.д.)
Подъемно-раздвижная система ALT GS106. Плюсы и минусы.
в Общие профессиональные вопросы
Опубликовано:
Мы уже сделали на этой системе 8 раздвижек. Для неё делают профиль Алютех, Сиал, Реалит, фурнитура Giesse с ТБМ. Профиля почти все взаимозаменяемые. Разработка Giesse - система GOS-S. По эксплуатации пока не могу сказать, т.к. ставили весной и пока заказчики не использовали.