[vl74]

Давно уже занимаюсь проектной деятельностью и заметил одну вещь - нет нормального способа оформлять расчеты. Понятно - NormCad, "ом снип железобетон", модули SCAD, в LIRA есть расчеты узлов стыков и баз металлических конструкций (с подробным протоколом расчета по пунктам нормативов).
Сам я изобретал велосипед - расчеты в EXCEL, но там сложности с вставкой формул и последующей постановкой значений переменных.
Но когда надо быстро сделать отчет с рисунками и формулами - иногда проще вручную, чем в WORDе.

И я решил попробовать WORD+VBA. Не самый простой вариант, но документ получает сразу конечный вид.
За основу взял пример 22 пособия к СП 52-101-2003, скопировал текст и в VBA набрал программу.
Пример выложил, голубым цветом отмечены вводимые данные, коричневым - результаты расчета. После ввода данных нажмите CTRL+Q
Он не совсем идентичен тексту примера, но тут уж издержки расчета.

И по-моему в примере ошибка с определением коэффициента nu_v (он не равен 1 , его нужно считать по формуле 3.86). Но в файле оставил как в примере.


ПОПРАВКА - в примере нет ошибки.

[sp1ash]

Пытаюсь изменить значение h, жму Ctrl+Q, выдает "Type mismatch". ЧЯДНТ?

[vl74]

Точно число вводите? А то не пойму ЧЯДНТ!

[v.psk]

Сообщение от vl74 Сам я изобретал велосипед

и я...
последнее что пробовал - libreoffice calc+math
- связка позволяет заполнять сложные формулы /я вставлял циклами полученные расчетом str/.

отличная работа - http://webcad.pro/
- чем сделано не знаю.

[sp1ash]

ЧЯДНТ = что я делаю не так. Числа ввожу разные, и 400, и 600. Не проверил сразу только самое явное - даже ничего не изменяя, по связке Ctrl+Q вылезает этот "Type mismatch".

[Бахил]

Сообщение от sp1ash ЧЯДНТ?

Похоже у тебя десятичный разделитель в системе - запятая.

----- добавлено через ~7 мин. -----
vl74, не понял вопроса. Или просто выложил для всеобщего использования?

[vl74]

Да это не вопрос - просто как готовый расчет выложил. Интересно опытом поделиться.
А насчет проблемы - у меня MS OFFICE 2010 х64, может версии отличаются?
А вообще новый редактор формул довольно глючная вещь.

----- добавлено через ~3 мин. -----

Сообщение от v.psk отличная работа - http://webcad.pro/ - чем сделано не знаю.

JAVA SCRIPT - гляньте исходный код страницы.

[Бахил]

Сообщение от vl74 А вообще новый редактор формул довольно глючная вещь.

Это так. Почему то высота формулы всегда одинаковая. В результате в дробях шрифт уменьшается. Можно ли как то увеличить высоту формулы?
Что касается "ЧТЯНД" sp1ash, то причина именно в десятичном разделителе.
У меня 10-32, заработал после замены точки на запятую.

----- добавлено через 58 сек. -----
Вообще то VBA не меняется с момента возникновения.

[vl74]

Сообщение от Бахил Вообще то VBA не меняется с момента возникновения.

И это хорошо
Чтобы высота формулы не уменьшалась - поменяйте ее тип на "отображаемый", но тогда нельзя печатать текст в той же строке.
Насчет точки или запятой - у меня работает в обоих случаях.

[Бахил]

Спасибо. Но это не дело. Я просто пишу формулы в экейшен.

[vl74]

Сообщение от sp1ash ЧЯДНТ = что я делаю не так. Числа ввожу разные, и 400, и 600. Не проверил сразу только самое явное - даже ничего не изменяя, по связке Ctrl+Q вылезает этот "Type mismatch".

Точно, разделитель - запятая, тогда глючит.
Надо сделать точку и все работает.
Надо допиливать.

Поправил, и скорректировал расчет в сторону увеличения nu_v.

[AY]

Непревзойденное (как утверждают с 1978г. т.е. уже 36 лет) средство для верстки математики это TeX (LaTeX). И что удивительно, вещь очень мало известная в нашем инженерном сообществе. Физики и математики еще более или менее пользуются, а с нашим братом совсем туго. Вещь сильная, но порог вхождения относительно высок — для использования нужно прочитать книгу, а лучше две :) и постоянно пользоваться при работе справочником.

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

Для интересующихся выкладываю кое-какие примеры расчетов в Ворд >= 2007.

[vl74]

Не спорю - онлайн расчеты тоже можно использовать, но ситуация - сайт закрылся и все, приехали.
А расчеты в Ворде - это, конечно, слишком муторно.

[ShaggyDoc]

А расчеты в Ворде - это, конечно, слишком муторно.

По этому поводу ещё древние греки говорили: "У каждого жулика свой расчет". А французы расширили: "Месье знает толк в извращениях".

Ну зачем нужны именно расчеты в Ворде? Чтобы оформить "красиво"? Чтобы были многоэтажные формулы с греческими символами и математическими знаками? А потом расшифровка "по цифиркам"?

Да, всё это часто необходимо. Желательно, чтобы всегда расчеты были достойно оформлены. И не только с формулами, но и на форматке, со "штампами", подписями, названиями объекта, здания. Чтобы хоть в архив, хоть в экспертизу. Но для этого совсем не надо использовать именно Word, а для написания формул совсем не надо именно TeX (LaTeX), который долго изучать надо.

Каждый постоянно сталкивается с множеством небольших расчетов, наподобие приведенных в webcad.pro_Примеры_расчетов.docx. Явно видна кустарная ручная работа, которая хорошо выполнена, но и к ней претензии могут быть - для какого объекта, кто сделал, откуда взялись данные, что все эти закорючки означают. Это ведь тоже важно в плане оформления, мало ли что "все знают", что Mmax - это момент. Расчет-то оформляется для "прокурора", а он не знает.

Да и в Ворде уже понадобился VBA со всеми его "приколами" и "фичами". Но, если уж дошло до программирования, то надо серьезно делать. Вот примерная технология:

1. Разрабатываете отдельную программу - сборник таких не очень сложных расчетов. Написать "арихметику" любого такого расчета каждый сможет.
2. Данные для расчетов хранятся в базе данных. Можно в локальной, для простоты, например в MDB.
3. Для каждого вида расчета своя таблица в базе данных со своей структурой и формами ввода. В таблице могут быть и вычисляемые поля.

Для примера прилагаю фрагмент отчета с расчетами, скриншот программы с вводом данных для знакомого всем расчета сопротивлений теплопередаче, и фрагмент скриншота генератора формул - освоить его можно за 10 минут.
4. Должен быть генератор Отчета, который выводит результаты в требуемой форме и форматах - хоть на печать, хоть для вставки куда-то, например в тот же Ворд. Форму отчета надо сделать по-хитрому. Лучше все расчеты выводить в табличном виде с графами наподобие Параметр, Ед.изм, Формула, Расчет, Результат, Примечание.

При вводе или изменении любого значения данные пересчитываются. В этом же событии может генерироваться текст для поля Расчет в виде строки с "цифирками". Именно строки. Незачем извращаться, чтобы сделать сам расчет в иде "простой дроби", вполне пригодна и строка, в том числе с заменой "корней" на функции. А вот Формула должна быть в "математическом" и "сниповском" виде. Но её надо сделать один раз в виде растра

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

Кстати, для любителей VBA - всё, что перечислено в пунктах 1-4 можно сделать и в MS Office, только не в Word, а в MS Access, она специально для этого и разработана. Всё ваше приложение и данные будут в одном файле.

[Boxa]

и чего в одной теме то не сиделось... http://forum.dwg.ru/showthread.php?t=92154

[ShaggyDoc]

и чего в одной теме то не сиделось...

В той теме ровна два года обсужают "а вот бы...", но без каких-либо результатов. Это обычное "колхозное собрание". А здесь человек для себя поставил конкретную задачу. Я подсказываю, как можно её решить - быстро и эффективно.

[vl74]

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

[CRISTOFF]

Есть несколько таких простеньких расчётов, оформленных в Mathcad. Ни разу экспертиза не высказалась против.

[vl74]

Ковыряю mathcad. Вопрос такой: часто в нормах есть условие типа

если a>1 то b=f1(a)
иначе b=f2(a)

Как скрыть промежуточные вычисления, чтобы в итоге было:

так как a=5 > 1, принимаем b= f1(a)=....

[AY]

Сообщение от ShaggyDoc Явно видна кустарная ручная работа, которая хорошо выполнена, но и к ней претензии могут быть - для какого объекта, кто сделал, откуда взялись данные, что все эти закорючки означают. Это ведь тоже важно в плане оформления, мало ли что "все знают", что Mmax - это момент. Расчет-то оформляется для "прокурора", а он не знает.

Предполагается, что показанные расчеты существуют не сами по себе, а в составе пояснительной записки, где и указан объект, исполнитель и откуда взялись данные и сро и "чего вам там еще надо". На счет того, что бы расписать каждую букву в расчете - каких-либо сложностей нет, но с моей точки зрения излишество которое затрудняет чтение расчета (исключая тот сулчай, когда у нашего "жулика" зарплата зависит от толщины пачки макулатуры). Отсылка к прокурору сомнительна, едва ли он будет проверять расчеты - позовет эксперта Иванова-Петрова-Зуева, они и разберутся, а скорее всего и разбираться не станут, а сделают свои ("У каждого жулика свой расчет") и сверят результат.

Сообщение от ShaggyDoc Лучше все расчеты выводить в табличном виде с графами наподобие Параметр, Ед.изм, Формула, Расчет, Результат, Примечание.

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

p.s. Сергей Александрович, а не знаете ли где взять данные по зонам влажности (карта зон влажности из приложения «В» СНиП 23-02-2003) соотнесенные с населенными пунктами из списка СНиП 23-01-99 «Строительная климатология»?

[ShaggyDoc]

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

Это часть расчетов с широкими таблицами. Большинство книжная А4. Но тут суть в том, что такой отчет можно как угодно скомпоновать. Можно и в виде текста. Здесь важен принцип - данные в БД, ввод только нужных параметр, расчет и формирование оформления - автоматически.

p.s. Сергей Александрович, а не знаете ли где взять данные по зонам влажности (карта зон влажности из приложения «В» СНиП 23-02-2003) соотнесенные с населенными пунктами из списка СНиП 23-01-99 «Строительная климатология»?

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

Вот чем всякие расчеты в Word, Excel и прочих "инженерных" системах привлекают? Тем, что обычный инженер может относительно легко, без привлечения всяких программистов, выполнять всё, что ему надо. И это очень хорошо. Но до определенного уровня. Рано или поздно приходится уже привлкать дополнительные средства - VBA или какие-то другие "языки программы". Да и там особо много не сделаешь, а потом еще и об оформлении думать. Т.е. инженер уже сталкивается с программированием, которое ему вполне по силам.

Но тогда уж лучше изучить какую-то универсальную среду и в ней делать свои программы. Программирование и придумали ленивые люди, чтобы облегчить рутинные операции. И средства разработки теперь достигли совершенства. Сами расчеты в программах занимают от силы 10%, остальное - интерфейс. Но и его сейчас легко разрабатывать, несравнимо легче, чем во времена DOS. А жизнь-то долгая, проще месяц потратить на освоение какой-нибудь среды, чем всю жизнь мучиться с MatchCAD-ами.

[AY]

Сообщение от ShaggyDoc Но тут суть в том, что такой отчет можно как угодно скомпоновать. Можно и в виде текста. Здесь важен принцип - данные в БД, ввод только нужных параметр, расчет и формирование оформления - автоматически.

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

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

Сообщение от ShaggyDoc Но тогда уж лучше изучить какую-то универсальную среду и в ней делать свои программы.

Изучение среды, автоматически не позволяет делать отчеты, нужно еще и с этой стороной вопроса разбираться, ну и работа с БД отдельная тема и еще кое-какие технологии. Многие ли способны (и имеют время) освоить сказанное? Надо думать, сущие единицы, поэтому Excel, поэтому "мучения" с MathCad. Впрочем, мы опять начинаем обсуждать "какой язык для расчетов лучше".

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

Понятно. Надо бы как-то пользователей сорганизовать на подобное - допустим каждый пользователь из какой-то области заполняет зоны влажности не только для своего населенного пункта, но и для прочих из своей области :) Что конечно мало реально... Загвоздка в том, что на карте, разумеется, показаны далеко не все населенные пункты (из табл. СНиП) поэтому нужны "местные жители", которые смогут определить где на карте находится тот или иной нас. пункт.

[perpetule]

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

[ShaggyDoc]

а что до БД - у нас (конструкторов) не так уж много данных, что бы для них использовать БД... на ум приходит только несколько таблиц с характеристиками бетона да сортаменты проката. Но ради таких мелочей связываться с базами не резон.

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

Любые данные, хранящиеся в одном из "DataSet" сраз сами "умеют" очень многое. И визуальное отображение, и поддержка типов данных (невозможна ситуация, как в начале этой ветки: "Точно число вводите? А то не пойму ЧЯДНТ!"). В БД хранятся любые данные, включая и чертежи, и формулы. БД "умеет" сама производить вычисления и множество всяких операций, невидимых пользователю). И те же отчёты в любой мыслимой форме с помощью специальных "Конструкторов". Всё это может храниться в одном файле, с которым могут и одновременно несколько человек работать.

У любого инженера всегда есть куча справочной информации, которая может лежать в БД. Всё это может быть в справочных БД, используемых в разных программах. Вот у меня в программе Лидер-Энергопроект каждый "проект" - это один файл БД. В нем 51 взаимосвязанная таблица. Используется еще один файл Справочников. В нем 43 таблицы (включая климатологию). Этот справочник используется ещё в 4-х других программах. И, даже если надо выбрать одну из трех зон, то также используется таблица всего из трех строк. Пользователь выбирает, например зону "Сухая", а программа получает её номер и по нему сама пересчитвывает связанные пераметры.

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

Да что убеждаю, просто приложу несколько картинок - программа, выбор из справочников, конструирование отчета, просмотр отчета.

[Бахил]

Сообщение от perpetule свои расчеты оформляю в автокаде с использованием таблиц автокада

Offtop: Ну некоторые товарищи и в екселе чертежи делают
Вообще то офис+VBA предоставляют широкие возможности. Данные в аксессе, вычисления в екселе, отчёты в ворде.
Можно конечно любой из пакетов использовать как угодно. Но лучше по назначению.

----- добавлено через ~2 мин. -----
Тем более передача данных между ними не представляет каких то сложностей.

[AY]

Сообщение от ShaggyDoc Это типичное заблуждение - подсознательный страх перед базами данных

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

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

Но главное препятствие, пожалуй в том, что я не вижу где это применять. Ваш пример интересен и отличная демонстрация того как это может работать, но я не вижу как это можно применить у себя. Вот тут-то, собственно, "собака зарыта" - я и, надо думать, многие другие не видим. Вы видите, а мы нет! Мы мыслим иными категориями и преодолеть - это крайне затруднительно - нужна иная культура мышления.

И здесь я даже не говорю о том, что свести воедино программу с 51 таблицей вечерком после работы дано далеко не каждому. Вот вы пишите, что: "У любого инженера всегда есть куча справочной информации, которая может лежать в БД.", а я не знаю какую бы информацию положил в базу данных, в голову приходят сортаменты проката, да и то пользуюсь ими довольно редко, что делать с чертежами в базе данных тоже не знаю...

[ShaggyDoc]

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

Конечно, если почитать серьезную литературу, где втолько "Введение" составляет 1060 страниц, то можно испугаться. Но можно и проще.

Лучший пример - тот же Офис с MS Access. Почему-то инженеры только до Excel доходят и часто её используют, как БД, со всеми последующими проблемами. В Access есть хороший пример - "Борей.mdb". Это и база данных, и программа, и отчеты, и формы в одном флаконе. И сама справочная система Accsess великолепно объясняет работу с БД такого уровня. А "расчетная" БД гораздо проще, чем практически реальный учет в торговой компании.

а я не знаю какую бы информацию положил в базу данных, в голову приходят сортаменты проката, да и то пользуюсь ими довольно редко

Ну так какую-то работу всё равно делаете? Вот у меня только для теплотехнических расчетов набралось более 40 справочников. Конечно, чтобы рассчитать M=q*l^2/8 справочников не надо. А вот сечения под момент подобрать уже понадобится. Причем ведь можно и разом весь сотамент проверить или по каким-то условиям.

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

Office - превосходный набор инструментов, но их надо использовать по назначению. Не делать "расчеты в Ворде" (разве что сумму колонки с данными). Расчеты надо в Excel делать, там же и оформлять. Но и с Excel надо с умом. Встречаются очень интересные таблицы, которые годами совершенствуют. Но для них нужны данные, которые тут же и хранят. Со всеми неудобствами. И все равно VBA начинают использовать. Так переходите на Access - написать формулу на Basic проще, чем ссылками на ячейки, а главное надежнее. Поставил в Excel разделитель неправильный (а неправильным может оказаться и точка, и запятая) - получил ошибку, иногда незаметную.

[Бахил]

Сообщение от ShaggyDoc Поставил в Excel разделитель неправильный

Excel тем и хорош, что ему без разницы какой разделитель заявлен в ОСе. Если формат ячейки числовой, то при смене системного разделителя автоматически происходит и его смена в Excel. В отличии от Worda.

[ShaggyDoc]

Excel тем и хорош, что ему без разницы какой разделитель заявлен в ОСе. Если формат ячейки числовой, то при смене системного разделителя автоматически происходит и его смена в Excel.

Excel тем и плох, что если в ячейку, которой присвоен формат числовой, ввести "букву", то формат будет символьный. Только если ячейка участвует в вычислениях, там обнаружится ошибка. А в БД в числовое поле физически нельзя внести недопустимый символ.

Но Excel ещё хоть реагирует на ошибки. А вот в электронной таблице OpenOffice такие ошибки пропускались. Неправильное число считалось нулем, вычисления продолжались без предупреждений. Представляете, какие ошибки бывали, например в денежных документах. Причем разработчики ОО об этом знали. Но там же "колхоз". Исправит кто-то в одной версии, а другой разработчик затрет своим кодом и ошибка вновь появляется. И ведь как отбрехивались - "зато мы не зависим от Windows. А зато у нас вообще для каждой ячейки можно индивидуальный формат разделителя задать".

[realdoc]

Сообщение от AY на ум приходит только несколько таблиц с характеристиками бетона да сортаменты проката.

Это если думать только о расчетах. На самом деле для базы данных в проектной фирме очень большое применение. По сути вся область деятельности фирмы может быть охвачена такой базой данных.
Но и конструкторам широкое поле деятельности. Во первых спецификация - самая что ни на есть база данных элементов в комплекте. Учет этих элементов - чем не аналог складского учета где базы данных живут прекрасно.
Зато можно получить раскладку по материалам в любой момент как во вложении.
Таблицы нагрузок. Тоже хорошо считаются из БД и хорошо экспортируются куда угодно. Конечно можно посчитать и руками. Но автоматически гораздо приятнее.

Сообщение от AY что делать с чертежами в базе данных тоже не знаю...

Как что. А применение типовых элементов. Выбрал чертеж закладной из базы в виде картинки и вставил ее сразу в отчет общих данных со штампам КЖИ.
А учет самих чертежей. В общем поле непаханое для применения БД в проектной организации.

[trir]

Если поменять разделитель в Excel'е то можно обнаружить кучу неожидоностей, например в таблице могут оказатся числа с разными разделителями - потому что тип данных разный текст/число, VBA может это игнарировать...
А SQL гораздо удобней формул в Excel'е, особенно если надо ссылатся на кучу таблиц. ИМХО формулы удобны в рамках одного листа, если нужно >2 листов - однозначно БД

[AY]

Сообщение от ShaggyDoc Конечно, если почитать серьезную литературу, где втолько "Введение" составляет 1060 страниц, то можно испугаться. Но можно и проще.

В общем, будем считать, что вы меня уговорили, по меньшей мере, на чуть более системный подход к предмету :) Стало быть, мне в таком случае нужен совет с какой базой работать. На виду: PosgreSQL, MySQL, SQLite... MS Access мне по всей видимости не подходит т.к. работать база должна на сервере под Linux.

Сообщение от realdoc Это если думать только о расчетах. На самом деле для базы данных в проектной фирме очень большое применение. По сути вся область деятельности фирмы может быть охвачена такой базой данных.

Если уж на то пошло, то много чего можно охватить базой данных, но надо ли? Сэкономлю ли я время и силы охватывая КЖИ базой данных или суммарные трудозатраты окажутся меньше, если файлы попросту положить в некоторой папке (может в нескольких структурированных)? Думается, что последнее более вероятно.

Кстати, с ведомостью расхода стали удачно напомнили, уж и призабыл этот опыт. Некогда решил я (в очередной раз как нынче) стать более прогрессивным и загнал кое-какой КЖ в MS Access с марками и закладными, болтами и тому подобным. Таблицы там всякие сделал для арматуры, проката, классов стали, бетона разного ну как положено. И стал пробовать штатными средствами из этого дела калькуляцию тянуть. И так и сяк тянул - не выходит... без дополнительного программирования. Ну, думаю, может это я совсем тупой - кнопки не правильные нажимаю и пошел к одному нашему специалисту по базам - он на SQL как на родном изъясняется, хоть и при слове "аксес" слегка морщит рот (работал я тогда в сравнительно большой организации там даже PDMS был - так-то вот, нынче расскажи - не поверят). В общем то ли гражданин не проникся моими заботами, то ли я был не достаточно красноречив, но обычным SQL калькуляцию вытянуть не удалось, а ковырять Бейсик тамошний я то ли не захотел то ли времени не нашел. Так бесславно закончилось мое очередное весенне-осеннее обострение. Это собственно критика про всемогущество БД и возможность чего-то посчитать оной :)

[ETCartman]

Базы данных это когда одновременно обращаются к источнику много пользователей и нужно производить обработку быстро. Просто инженерные расчеты - прекрасное средство электронные таблицы + VBA или еще лучше - Open-Office Basic (который помощней VBA будет - поддержка функций массива например).
Конечно нужно основы освоить - вставлять обязательно обработчик ошибок. Плюс - можно сразу считать много много (например проверить сразу 100 элементов по СНиП) Для каждого при этом не обязательно расписывать одни и те же формулы - достаточно в приложении поместить выдранную из стройконсультанта методику и закоментированный текст программы. Так по крайней мере по американским правилам - считайте хоть в чем, но все должно быть ясно и понятно - что откуда.
вот статьи на эту тему
http://myooo.ru/content/view/172/95/
http://myooo.ru/content/view/173/95/
Программы типо маткада-нормкада я вообще никогда не понимал - в качестве профессиональной математической она сильно слабая (по сравнению с той же Техасской и свободной wxmaxima)
для инженерных целей - избыточная
для оформительских целей - слишком убогая.
Такие вещи как правило рекламируются через агрессивный маркетинг и эксплуатируют какую то уязвимость пользователя - например безграмотность, неумение перевести единицы (прогулянные уроки арифметики) и так далее.

[ShaggyDoc]

Стало быть, мне в таком случае нужен совет с какой базой работать. На виду: PosgreSQL, MySQL, SQLite... MS Access мне по всей видимости не подходит т.к. работать база должна на сервере под Linux.

Сначала надо подумать, а должна ли БД быть именно на сервере. Если говорить о расчетах, да еще таких, которые выполняет один человек или несколько попеременно, то лучше имель локальную БД, которую можно положить куда угодно и перенести куда угодно в виде одного файла. На сервере под Linux лучше всего использовать MySQL - он просто есть "везде". PosgreSQL менее распространена и нужна для очень больших объемов данных. Хотя принципиальных отличий между ними нет, здесь не пользователь выбирает, а администратор сервера.

На сервере удобно иметь постоянную БД с фиксированным набором таблиц. Например этот форум работает или с MySQL или с Posgre - это не определишь со стороны. У него есть одна БД, в которой сотни таблиц с миллионами уже записей в некоторых, например site_content. И каждая таблица из нескольких файлов состоит. Другой сайт на этом же сервере имеет другую БД. В таких СУБД база данных - это каталог с таблицами. Их нельзя создавать неограниченно.

Для расчетов удобнее локальная работа. Один проект - один файл, в котором исполнитель сам хозяин. Тут уж MySQL неудобен, хотя он может работать и на локальной машине, но с постоянно запущенным сервером MySQL. Хотя весь сервер - это одна DLL.

SQLite для расчетов удобнее - это однофайловая БД, которую можно поместить где угодно, хоть локально, хоть на сервере. Для работы тоже нужна одна sqlite3.dll (для Windows, на Linux другой движок). Вот тут и засада обнаруживается. Как всякую "свободную" систему SQLite "рихтуют" под себя все, кому не лень. Имеется множество одноименных вариантов, которые часто несовместимы между собой. Поэтому каждая программа тащит с собой свою версию и количество их на компьютерах растет. И хорошо еще если DLL кладут в папку своей программы, а не в System. У меня на машине нашлось 18 штук этих DLL в разных вариантах.

Кроме того SQLite не имеет визуальных компонентов. А именно они нужны прикладному программисту (инженеру). Это просто сервер, который очень хорошо выполняет SQL-запросы. А чтобы применить его в конкретной программе, нужны дополнительные компоненты - как минимум для Connection, DataSource, Table и Query. И здесь уже дело за средой программирования. В каких-то штатных средств вообще нет - нужны сторонние. А они обычно очень "разные" - как правило корявые. И, даже если такие найдутся, то необходимо и другое - например генератор отчетов, который тоже должен уметь работать с SQLite.

Если заниматься программированием БД, то сначала надо выбрать среду программирования, а потом уже выбирать из того, что доступно в ней. Т.е. сначала какую-то "веру" принять.

Я, например, работаю в Delphi. Там есть всё для БД - и локальных и серверных. Например, Firebird, который и локально с однофайловой БД работает (embedded), и с той же БД на сервере будет работать, без каких-то изменений в программе. И набор превосходных компонентов есть. Можно и через ADO работать, т.е. вообще с любой БД, для которой есть OleDbProvider (а их не так уж много хороших). Как минимум с БД формата Access (mdb) вполне возможно. Но тут уже обнаруживаются козни Майкрософта. Они взялись плодить новые версии и в них, по их "доброй" традиции, стали появляться недопустимые глюки. Поэтому я для расчетных программ теперь уже навсегда перешел на AbsoluteDatabase - в ней есть всё, что надо и не нужны вообще никакие посторонние "движки".

Если же "продал душу" Майкрософту, то уже ни Firebird, ни Interbase, ни AbsoluteDatabase, ни десяток других СУБД не будут доступны - там "вера не позволяет". Должен хавать то, то позволили Билл - он самый богатый, значит и самый умный.

пошел к одному нашему специалисту по базам - он на SQL как на родном изъясняется, хоть и при слове "аксес" слегка морщит рот

Ну и правильно делает. Программу MS Access программисты не используют, разве что для конструирования самой БД. Она же для "чайников", всё кнопками делается, нет даже окна для ввода SQL-запроса. А вот базу в формате Access использовать можно, но с учетом её возможных глюков и распухания.

[trir]

Я бы посоветовал MySQL - книжек и доков больше (на руском), хотя SQLite и Firebird - логичней
И да, без програмирования - никуда

[DMSbrick]

Сообщение от perpetule Не в укор, а в продолжение темы - свои расчеты оформляю в автокаде с использованием таблиц автокада (формулы полями в ячейках, пояснения текстом и блоками).

а картиночки (бмп жпег) как вставляете?

[swell{d}]

Чего-то сложно. Проще в экселе

[perpetule]

Картиночки (png) - как правило относительным путем на папку с фиксированным именем "image", или без пути, но упаси вас использовать OLE.

[Boxa]

Сообщение от swell{d} Чего-то сложно. Проще в экселе

Что сложного то? Для того что бы въехать можно посмотреть вот эту статью: http://www.sergechel.info/ru/content...reparing-tools

[swell{d}]

Boxa, я лично вообще не понимаю, зачем это нужно

[Boxa]

swell{d}, Тут надо подход менять, не надо бояться БД.
Для примера, у меня есть программки обсчета спецификаций, так вот сортировку, группировку позиций проще, быстрее и нагляднее выполнить в БД. Программно создал, обработал и стер... и плевать что там пяток позиций.

[swell{d}]

Boxa, проведёшь семинарчик на эту тему? =)

[Boxa]

swell{d}, тут не нужен никакой семинар.
Просто нужно понимание, что для выполнения различных операций, нужны различные инструменты.
Это как с пакетом Офиса, для таблиц - ексел/калк, для текста - ворд. Нет, никто не запрещает делать таблицы в ворде, но нормально ли это?
Так и в программирование, можно обрабатывать данные массивами и списками, более того, для одно (двух) мерного массива это нормально, но если работать со списками содержащими более двух колонок, то в плане простоты программирования и быстродействия работы - добро пожаловать в БД.

ЗЫ.
Я в курсе о возможностях ООП и использования LINQ , и прекрасно понимаю, как сортировать и группировать данные с любым количеством столбцов и данных, но не смотря на это, считаю, что удобнее и правильнее использовать БД.

[ETCartman]

Примеры использования баз данных по месту и назначению:
Учебное заведение и студенты: ФИО, год рождения, поступил - окончил и тд
Больница и пациенты
Склад и товары.
Основной смысл базы данных - единый источник какой то информации, с которым могут работать разные люди (или много людей - одновременно)
Например кадры, приемная комиссия и бухгалтерия. Не очень удобно если у каждого свой список, и приходится Дарье Петровне бегать к Марье Ивановне и смотреть - чего там поменялось. Для таких случаев и был создан access и его открытый аналог в опен-офис
Сейчас все тоже самое все чаще организуют на сервере через веб интерфейс. А с модой на облачные технологии - несомненно, что и там наверняка уже есть нечто такое для пользователей облаков.
Для более сложных случаев, например банки-клиенты есть уже вещи вроде оракл.
Конечно даже простой текстовый файл со структурированной информацией можно рассматривать как базу. Написать поиск и парсинг и так далее. И для несложных программ иногда так и делают (в том числе там где инженерные расчеты). Но чаще даже такой подход избыточен.
Но для того чтобы сложить 1+1=2 - базы данных точно не нужны. Оно собственно и access всегда занимал такую тонкую нишу, что не часто приходилось видеть, чтобы его активно пользовали. Для обычных пользователей он слишком сложен а для программистов - не нужен из за ограниченности.
Потому что баз много и самые ходовые из них - вообще открытое ПО, известное и привычное любому программисту.
В инженерных расчетах программирование вообще как правило элементарное. И в экселе "базу" можно вынести на отдельный лист и обращаться к ней через VLOOKUP (что все и делают). А во избежание ошибок - просто принудительно форматировать соотвествующие ячейки. Электронные таблицы все таки были и останутся основным средством для таких расчетов, тем более что basic расширяет возможности почти неограниченно.

[trir]

Всё таки главное преимущество Access - скорость, быстро набросать БД, формы, чуть кода, отчёты в том числе с графикой в АкАд. Умеючи - скорость просто феерическая, особенно если есть заготовки (а через пол года использования - они будут)

[ETCartman]

так про что угодно можно сказать. в lazarus вон zatmin почти целый автокад написал сам для прикола.
Access все таки самый странный выбор по моему.

[ShaggyDoc]

Можно, конечно, расчеты и "умеренно кустарно" делать, например совмешая Word и Excel. Иногда такое приходится делать, если надо много текста, иллюстрированного поясняющими таблицами. Тут такая схема:

1. Расчеты выполняются в Excel, как угодно. Можно и с графиками, диаграммами.
2. На каком-то листе надо сформировать таблицы, которые надо вставлять текст. Можно и "формулы картинками" туда вставлять.
3. В Word тотвятся результаты, например в виде пояснительной записки.
4. В нужные места вставляются выбранные диапазоны из Excel. Тут имеются свои тонкости - надо сделать правильное оформление, вписывать колонки в страницу, применять к таблице стили оформления из Word.
5. Придется столкнуться со сложностями. Надо, чтобы связь Excel и Word не терялась, т.е. файлы были на своих местах. Чтобы при изменении расчета в таблице изменялся и текст в Word.

В принципе в MS Office всё это возможно, но есть неприятные нюансы, связанные с глюками. Вдруг не появляется контекстное мнею вставки с вариантами оформления. Вдруг сообщается о нехватке памяти, которой море. Вдруг....Вдруг...
Чтобы преодолеть всё это приходится придумывать всякие макросы, как в Excel, так и в Word. Приходится заботиться о загрузке этих макросов, о внедрении их в шаблон, о появлении кнопок и дополнительных меню. В общем работа для "месье, которые знают толк в извращениях". Потраченного времени может быть больше, чем освоить "настоящее" программирование.

Но иногда приходится и это делать. Например, раза два в год делать техническое обоснование тарифов для ТСО. Делать для этого "настоящую" программу нет смысла - время на её создание не окупится, продавать некому, себе - очень редко надо. Приходится всопминать про извращения.

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

Access все таки самый странный выбор по моему.

Ну, это уж кому как. Кто любит попа, кто попадью, а кто-то попову дочку. А кто-то свободолюбивых негров.
Научился человек работать в Access - пусть работает. Но это быдет уже только "для себя".

[AY]

Сообщение от ShaggyDoc Сначала надо подумать, а должна ли БД быть именно на сервере

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

Сообщение от ShaggyDoc Для расчетов удобнее локальная работа. Один проект - один файл, в котором исполнитель сам хозяин. Тут уж MySQL неудобен

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

Сообщение от ShaggyDoc Если заниматься программированием БД, то сначала надо выбрать среду программирования, а потом уже выбирать из того, что доступно в ней. Т.е. сначала какую-то "веру" принять.

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

[ShaggyDoc]

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

Ну это вообще не вопрос. Развертывайте на своем сервере какю-нибудь Систему управления контентом (CMS) - готовую и бесплатную, и работайте через ВЕБ-интерфейс, в браузере. Полчаса настроек и готово. Свои "расчетв в Ворде" (или хоть в чем) складываете туда в виде файловой попойки (но "по полочкам") и организуете доступ пользователей по аккаунтам.

Можно даже готовый бесплатный сайт арендовать, где-нибудь ну ukoz (только будет реклама "шпингалеты из Нижнего Тагила самовывозом"). Можно и более солидно - привязаться к аккаунту в Google - там и сайты дают.

[Бахил]

Сообщение от ETCartman Электронные таблицы все таки были и останутся основным средством для таких расчетов, тем более что basic расширяет возможности почти неограниченно.

Присоединяюсь. Offtop: Хотя и аксес со счетов не сбрасываю

Сообщение от ShaggyDoc Надо, чтобы связь Excel и Word не терялась, т.е. файлы были на своих местах. Чтобы при изменении расчета в таблице изменялся и текст в Word.

А для этого есть "подшивка".
Да, и надо различать потребности "фрилансера" и "бооольшой конторы".

[AY]

Сообщение от ShaggyDoc Можно даже готовый бесплатный сайт арендовать, где-нибудь ну ukoz (только будет реклама "шпингалеты из Нижнего Тагила самовывозом"). Можно и более солидно - привязаться к аккаунту в Google - там и сайты дают.

Меня терзают смутные сомнения, что возникло недопонимание... у меня же есть сайт http://webcad.pro/ и расчеты у меня не в Ворде, в нем отчеты, хотя это не доделано, сейчас отчеты большей частью в pdf.

[vl74]

AY, у меня вопрос к вашему расчету прогибов по СП 63.13330

Правильно ли считается Ib, по моему Ib=b*xm^3/12 ?

[AY]

Сообщение от vl74 Правильно ли считается Ib, по моему Ib=b*xm^3/12 ?

Там вроде бы момент инерции считается относительно нейтральной оси.

[dabunbek]

А если так?
Напомню, для того чтобы обновить поля, необходимо выделить весь текст и нажать F9

[vl74]

dabunbek, весьма интересно. Подозревал, что поля в ворде что-то наподобие полей в автокаде.
Проблема в том, что очень сложно выполнить ветвление расчета по условию.
Непонятно, как присваивать значения переменным, например l=9000мм.


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

[AY]

Сообщение от vl74 Подозревал, что поля в ворде что-то наподобие полей в автокаде.

Справедливости ради — это не в Ворде поля наподобие Автокада, а наоборот т.к. в первом поля появились гораздо раньше и в Автокаде их делали скорее всего по мотивам Ворда.

[DEM]

ХЗ....
По мне так в Scilab прекрасно все делается....
Все ни как не могу сделать реальный пример расчета, т.к. занимаюсь пока программированием под СКАД.
У меня уже есть реальные функции которые делают отчеты в html.
Причем можно сделать и отчеты сразу в pdf. Но с этим пока не разбирался....
В Scilab есть модуль MathML который позволяет формировать формулы, и вообще создавать документы в виде картинок....
Времени к сожалению катастрофически не хватает....

[Нефтепроводчик]

Предлагаю все же вернуться к теме как она звучит "Выполнение расчетов в WORD с одновременным оформлением отчета".
Расчеты можно делать в самом ворде, т.е. вычисления с использованием вводимых исходных данных. С одновременным оформлением. В ворде есть так называемые поля - очень мощный инструмент, если им уметь пользоваться. В этих полях можно записывать буквенные формулы, производить математические вычисления, запрашивать у пользователя данные для вода, производить логические операции. В качестве примера привожу расчет толщины стенки магистрального нефтепровода. Просто выделите текст и нажмите F9 (обновить поля). Ворд запросит заполнить поля (около 15...20) исходных данных, по завершению обновит формулы в расчете. Самое главное, что ворд скрывает целые абзацы расчетов, если, например, какие-либо условия расчета не выполняются. Индексы в формулах, правда, нельзя уменьшить по сравнению с основными символами, но это мелочи по сравнению со всем остальным. Главное - расчетная программа и оформленный расчет - "в одном флаконе". Конечно для сложных математических и логических вычислений это не пойдет, но для относительно простых (на 1...5 страниц) практических расчетов с линейным или нециклическим алгоритмом расчета - вполне годится.
Хотите увидеть сам алгоритм расчета - нажмите Alt+F9.

[KEHT]

Нефтепроводчик, Интересный файл, а можешь порекомендовать по этому вопросу книжку или ресурс какой? Как ты это изучал?

[v.psk]

..делюсь с вами макросом /в файле/ для подсвечивания закладок и полей в ворд, и обновления ссылок.

[Владимир_М]

Сообщение от KEHT Нефтепроводчик, Интересный файл, а можешь порекомендовать по этому вопросу книжку или ресурс какой? Как ты это изучал?

Подписываюсь...
Однако, год уже прошел, никто никакого интереса не проявил. Жаль если Нефтепроводчик обиделся, и в тему не заглядывает...

[Нефтепроводчик]

Сообщение от KEHT Интересный файл, а можешь порекомендовать по этому вопросу книжку или ресурс какой? Как ты это изучал?

К сожалению, не могу порекомендовать. Дело было давно, разбирался сам.

[KEHT]

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

[Нефтепроводчик]

Нажимаешь Alt+F9, становятся видны все формулы. В них используются команды-поля. Применение каждой команды можно найти в справке Word или интернете.