alex_71

Мы уже сделали на этой системе 8 раздвижек. Для неё делают профиль Алютех, Сиал, Реалит, фурнитура Giesse с ТБМ. Профиля почти все взаимозаменяемые. Разработка Giesse - система GOS-S. По эксплуатации пока не могу сказать, т.к. ставили весной и пока заказчики не использовали.

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

Все это можно делать, в том числе и создавать свои таблицы. Запускаешь SQL-программатор и экспериментируешь в нем.

Мне кажется, что можно только сделать обязательную вставку в стеклопакет с предупреждением или сообщением. Но в этом случае придется прописать эту вставку в каждый! стеклопакет .

Дык в описании сторон фурнитуры ставишь на 1-ю сторону "Ось поворота с петлями", на остальные "стандартное", сторона ручки 3 (хотя у меня во всех фурнитурах почему-то 2). Или ты о чем-то другом спрашиваешь?

ОБАЛДЕТЬ! Сколько же ты разрабатывала и отлаживала все это? Да и сам текст отчета тоже наверно ого-го?! Подскажи, пожалуйста, такую вещь. А ты не пробовала определять створки по заполнениям: т.е. проходим по заполнениям, смотрим какой профиль внизу, если створка - смотрим открывание. - или это тупиковый путь?

Не совсем понял. У тебя во всех проемах створки, даже глухих? Створки ты просматриваешь по какой таблице и как определяешь наличие створки-форточки (кстати, что ты под этим понимаешь). Если можно выложи картинку с окном и перечнем его створок.

Поздравляю! Поделись, если можно, алгоритмом.

1) А ты в программаторе смотрела таблицу соединений когда не получалось? там они были? 2) Значит так. Беру таблицу tSpecZlt (заполнения изделия) по полю aName привязываю к ней tArticls, по полю clNum таблицу tColors, сортирую все это по типу заполн, назв , цвету. В результате вывожу список заполнений в порядке (стекло, с/п, сэндвичи), назв по алфавиту, цвета по алф. конструкцию left join применяю для однозначности заполнение -> соотв ему название и цвет. Т.е. берется запись из табл заполн и ищутся соотв ей записи в артикулах и цветах. Причем запись будет в результирующей таблице даже если нет соотв артикула или цвета. Это перестраховка, но все таки. Как использовать другие способы соединения не знаю. Такую конструкцию использую со времен работы с Access. Я и сейчас конструирую запросы с его помощью, там все проще и наглядней.

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 (рез по биссектрисе)?

А может там и нет данных удовлетворяющих твоему условию, у меня на твоем запросе именно так. Проверить можно в 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) Насколько понимаю-нет. Чем больше одновременно открытых запросов тем больше требуется памяти, если ее не хватает система начинает работать с диском а это сильно тормозит работу. Например расчет большого заказа (много типов окон) у меня длился ~15мин. При этом прога как-бы зависает 2) По моему нет, но все должно быть в разумных пределах. Кстати, что по этому поводу говорит "SQL для профессионалов" ? 3) Не знаю. Никто об этом не упоминал и в отчетах нигде такого не было 4) Это полтергейст . Выложи текст, тогда можно будет что-то сказать. 5) по моему пишется наоборот [таблица].[поле]

Ты переменную в запросе укажи как и номера изделия и проекта, т.е. (xyx>:^ugol:). А зачем тебе список координаты х для импостных соединений. Кстати с перечислением открываний ты разобралась, потому что вопрос мне тоже интересен. И еще. У тебя конструкция запроса больно завернутая, неужели нельзя это сделать без вложения? Ты вообще с SQL инструкциями разбиралась по книге или в сети. Я в сети нашел описания только по простым запросам без вложения как у тебя, а надо именно такое. Если есть ссылки поделись.

Если что-то получится напиши. Кстати, что такое minta - просто преременная(параметр) или какое-то поле из таблицы

Ты столкнулась с той же проблемой, что и я - нвозможность использовать строковые константы. Долго бился на этой проблемой и вот после твоего вопроса пришла мысль: создать таблицу с необходимыми строковыми значениями, а потом ее использовать. Последовательность такая: 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 и других. Еще вспомнил. А по функциям которые можно применять в отчетах ничего не знаешь? А то я уже два раза писал - а в ответ тишина

А профиль как?

Думал над похожей проблемой мысли следующие: - несколько строчек на один артикул из-зи способа расчета спецификации - если убрать галочку в настройках "Спецификация профилей и пакетов для сборки" то мерные комплектующие суммируются (не всегда). Чтобы полностью суммировать кажддый артикул - надо это делать вручную (см. отчет "Расход материалов", там также прописан расчет цены с учетом коеф. только всех или нет не вникал) - ну а цифры несходятся из-за округления. судя по всему программа округляет до 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". Только не надо советовать просто вывести их последовательно, нужно именно сцепить и присвоить значение параметру (переменной)! Еще вопрос. Для чего в списке полей спецификации (в генераторе отчетов) есть поля АРМИРОВАНИЕ (<~СПЕЦ:АРМИРОВАНИЕ:АРТИКУЛ~>,<~СПЕЦ:АРМИРОВАНИЕ:ДЛИНА~> и т.д.)