[rassom]

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

С уважением, rassom

[VVA]

выложи файл Access с примером

[rassom]

Сообщение от VVA выложи файл Accsess с примером

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


С уважением, rassom

[hwd]

Сообщение от rassom Привет всем. Я новичок в программировании и поэтому хотелось бы получить советы или помощь от опытных пользователей. Дело в том, что в проекте над которым я работаю, приходится нарисовать очень много линейных трасс и все это рутинно. Трассы нужно рисовать в полилайне и задать для нее слой с параметрами. Координаты всех трасс у меня находятся в таблицах Access 2003. Как и с чего надо начинать, на каком языке написать код, какую литературу нужно читать и т.д. Конечно, если можно, дать код и инструкции. Заранее благодарю за помощь. С уважением, rassom

Не изобретайте велосипед. Экспортируйте данные в MS Excel (надеюсь, что раз вы работаете в MS Access, то знаете что такое SQL и как этим пользоваться) и передайте их в эту программку (сначала видео до конца просмотрите, там второй задачей идёт как раз ваша) - она вам вычертит 3D полилинию и пронумерует вершины. При этот в виде гиперссылок сохранится связь с источником данных.

Координаты всех трасс у меня находятся в таблицах Access

а должны храниться в одной таблице.

Как написать программу... Я новичок в программировании и поэтому...

Вообще пишут, как правило ручками (если не учитывать генераторы кода). Прежде чем сесть за кодинг, неплохо было бы прежде определиться с языком программирования (C++/.Net/Lisp/VBA) и предварительно с ним познакомиться (хотя бы в общих чертах). Полагаю, вам подойдёт Lisp, ибо на более серьёзное нужно более серьёзное время для освоения материала.

[Дима_]

Сообщение от hwd Полагаю, вам подойдёт Lisp, ибо на более серьёзное ...

из этого я пологаю, что лисп это что-то не серьезное?

Сообщение от hwd Не изобретайте велосипед. Экспортируйте данные в MS Excel ...

получить полилинию по координатам из access на "несерьезном" лиспе дело 30 минут.
Автору - выложи формат бд.

[hwd]

Сообщение от Дима_ из этого я пологаю, что лисп это что-то не серьезное?

ты прекрасно понял, в каком контексте это было сказано, не стоит провацировать холивар.

Сообщение от Дима_ получить полилинию по координатам из access на "несерьезном" лиспе дело 30 минут.

и что? есть желание? пиши

[VVA]

Сообщение от rassom Что-то выложить файл не удается. Нажал на управление с вложениями и загрузил, но че-то файла не видно

Посмотри внимательно на разрешенные форматы и размеры. mdb там нет. отсюда вывод - или упаковывай в rar или zip или выкладывай на файлообменник и сюда ссылку. hwd прав, координаты всех трасс должны находится в одной таблице.
Для работы с БД из lisp сущесвует библиотека ADOLISP Database Library
Осталось правильно составить SQL запрос.
Здесь на форуме уже обсуждались похожие проблемы. Нелохо бы с этим ознакомится так же для начала.

[Дима_]

Сообщение от hwd ты прекрасно понял, в каком контексте это было сказано, не стоит провацировать холивар. и что? есть желание? пиши

автор выложит структуру бд (по сути мне нужен только sql запрос который возращает XY(Z) координаты по порядку полилиниии) все остальное стандартное решение (по барабану - хоть в экселе, хоть в acsess, хоть в mysql - odbc все поддерживают).
по первому пункту - ну пошутил

[hwd]

Сообщение от Дима_ (по сути мне нужен только sql запрос который возращает XY(Z) координаты по порядку полилиниии) все остальное стандартное решение (по барабану - хоть в экселе, хоть в acsess, хоть в mysql - odbc все поддерживают).

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

Сообщение от VVA hwd прав...

да неужели? в кои-то веки...

[ShaggyDoc]

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

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

Хранить координаты (каждая вершина это список из двых или трех точек) в таблицах БД Acces можно двумя основными способами:

1. В какой-то таблице создается MEMO-поле (можно текстовое) и в этом поле хранится список координат в каком-то формате. Другие поля - по разумению, можно и атрибутивную информацию держать. Это очень простое решение - можно вообще одной таблицей обойтись.

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

2. Создается специальная таблица с ключевым полем и полями типа X, Y, Z числового типа. В этой таблице находятся координаты всех линий, атрибутивная информация находится в другой таблице и осуществляется связь по ключевым полям.

Здесь уже надо заботиться о целостности данных, да и выборку из такой БД сложнее делать.

Интересный вопрос - как координаты будут попадать в БД? Хорошо еще если есть какие-то источники их поступления.

Извлечение данных из БД делается достаточно просто, через SQL-запрос. Изучать надо SQL, технологию ADO и собственно AutoCAD - если уж чертить в нем. Разумеется всяким мудрым советам по поводу Excel не стоит следовать - это "чтоб мужика запутать и не дать ему дохтуром стать".

И конечно же есть другие системы (не AutoCAD), где хранение координат и информации в БД реализовано изначально, в том числе и рисование.

[hwd]

Сообщение от ShaggyDoc это "чтоб мужика запутать и не дать ему дохтуром стать"

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

[Дима_]

Сообщение от ShaggyDoc Здесь уже надо заботиться о целостности данных, да и выборку из такой БД сложнее делать.

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

[ShaggyDoc]

Сообщение от Дима_ От себя хочу добавить - что если "по хорошему" - то только вторым способом, ибо в конечном итоге с первым гемора будет больше и закончится он только (гемор) при переходе ко второму.

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

И самый лучший способ - когда об этом и не надо задумываться. Такое реализовано уже в нескольких СУБД. Координаты объектов хранятся в отдельных таблицах, семантические данные - во многих других, и они только ссылаются на "пространственные" данные. Пользователю или прикладному программисту вообще ничего не надо об этом знать - он создает, например, дополнительные таблицы с семантикой, а пространственные данные где-то сохраняются "сами".

И еще один важнейший вопрос - как отобрать необходимые данные, например для рисования хоть в Автокаде. Т.е. для составления самого SQL-запроса. Здесь без визуальной части работы с БД никак не обойтись. Причем желательно чтобы просмотр семантики сопровождался и просмотром геометрии.

Как работает SQL можно прямо на примере форума увидеть. У форума есть БД. В ней десятки таблиц. В них находятся, наверное, уже несколько миллионов записей. Зайдя на форум и щелкнув "Новые сообщения" я посылаю "запрос" search.php?do=getnew (это видно в адресной строке). На этот запрос каждый посетитель получит свои данные. Выбрав конкретную тему мы посылаем "запрос" наподобие showthread.php?t=58427. Конечно, посетитель запросы не набирает, это делает программа - движок форума. Запрос из адресной строки она преобразует в настоящий SQL-запрос, посылает его к серверу БД, а тот возвращает результат в виде, например, сборника текстов сообщений по теме. Этот результат еще преобразуется в HTML-код, чтобы показать нам, бродягам в браузере.

Вот примерно такое же и надо делать с любыми БД. Только отображение по-разному надо решать.

[hwd]

Сообщение от ShaggyDoc Координаты объектов хранятся в отдельных таблицах, семантические данные - во многих других, и они только ссылаются на "пространственные" данные. Пользователю или прикладному программисту вообще ничего не надо об этом знать - он создает, например, дополнительные таблицы с семантикой, а пространственные данные где-то сохраняются "сами". И еще один важнейший вопрос - как отобрать необходимые данные, например для рисования хоть в Автокаде. Т.е. для составления самого SQL-запроса. Здесь без визуальной части работы с БД никак не обойтись. Причем желательно чтобы просмотр семантики сопровождался и просмотром геометрии. Как работает SQL можно прямо на примере форума увидеть. У форума есть БД. В ней десятки таблиц. В них находятся, наверное, уже несколько миллионов записей. Зайдя на форум и щелкнув "Новые сообщения" я посылаю "запрос" search.php?do=getnew (это видно в адресной строке). На этот запрос каждый посетитель получит свои данные. Выбрав конкретную тему мы посылаем "запрос" наподобие showthread.php?t=58427. Конечно, посетитель запросы не набирает, это делает программа - движок форума. Запрос из адресной строки она преобразует в настоящий SQL-запрос, посылает его к серверу БД, а тот возвращает результат в виде, например, сборника текстов сообщений по теме. Этот результат еще преобразуется в HTML-код, чтобы показать нам, бродягам в браузере. Вот примерно такое же и надо делать с любыми БД. Только отображение по-разному надо решать.

это "чтоб мужика запутать и не дать ему дохтуром стать"(c) - я верно цитирую?
Особенно понравилось плавное переползание на тему SQL-запросов к форумам. Это автору так нужно было, что он наверное прямо чесался без этой информации, а получив её прозрел. Если уж советовать, то книжки, ибо подобные "умные" примеры ясности ему не сильно внесут (имхо).
По теме топика - тынц.

[rassom]

Сообщение от ShaggyDoc Начинать надо с правильного проектирования базы данных - структур таблиц, сввязей между ними и прочим. Хранить координаты (каждая вершина это список из двых или трех точек) в таблицах БД Acces можно двумя основными способами: 1. В какой-то таблице создается MEMO-поле (можно текстовое) и в этом поле хранится список координат в каком-то формате. Другие поля - по разумению, можно и атрибутивную информацию держать. Это очень простое решение - можно вообще одной таблицей обойтись. Если эта база предназначена только для вычерчивания в AutoCAD, то список можно сделать прямо в виде LISP-списка, который потом можно прочитать и нарисовать линии. Если БД "общего назначения", надо сделать что-то универсальное, используя разделители чисел и точек. 2. Создается специальная таблица с ключевым полем и полями типа X, Y, Z числового типа. В этой таблице находятся координаты всех линий, атрибутивная информация находится в другой таблице и осуществляется связь по ключевым полям. Здесь уже надо заботиться о целостности данных, да и выборку из такой БД сложнее делать. Интересный вопрос - как координаты будут попадать в БД? Хорошо еще если есть какие-то источники их поступления. Извлечение данных из БД делается достаточно просто, через SQL-запрос. Изучать надо SQL, технологию ADO и собственно AutoCAD - если уж чертить в нем. Разумеется всяким мудрым советам по поводу Excel не стоит следовать - это "чтоб мужика запутать и не дать ему дохтуром стать". И конечно же есть другие системы (не AutoCAD), где хранение координат и информации в БД реализовано изначально, в том числе и рисование.

Спасибо всем за советы. Вот на счет SQL , ADO технологии и решение визуальной части задачи, какие книги нужно читать. На счет выбора языка, мне хотелось бы изучать LISP и VB.NET Да еще, у меня сейчас на компьютере есть программа Visual Studio 2010 Proffessional Вот такая исходная позиция. Хочу изучать только программирование для Автокад.
Заранее благодарю всех за новые ответы.

[hwd]

>rassom
Видео смотрел? Похоже на то, что искал (по теме топика)?

[Do$]

Сообщение от rassom у меня сейчас на компьютере есть программа Visual Studio 2010 Proffessional

Offtop: Случайно на нем оказалась?

[hwd]

Сообщение от Do$ Сообщение от hwd у меня сейчас на компьютере есть программа Visual Studio 2010 Proffessional Offtop: Случайно на нем оказалась?

ты автором цитаты не того указал

[Do$]

Offtop: Криво работает инструмент цитирования , исправил.

[Сергей Дубина]

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

[Елпанов Евгений]

Сообщение от Сергей Дубина Для акцесса проще написать ВБА и повестить на кнопку.

Я бы не рекомендовал использовать VBA в автокаде, когда совсем закончится его поддержка, что вы будете делать?

[Сергей Дубина]

Сообщение от Елпанов Евгений Я бы не рекомендовал использовать VBA в автокаде, когда совсем закончится его поддержка, что вы будете делать?

Так или иначе, объектную модель врядли отменят. Я имел ввиду VBA в Акцессе и доступ через объектную модель (библиотеку типов автокада), сам автокад предварительно не открывая.

[hwd]

Сообщение от Елпанов Евгений Я бы не рекомендовал использовать VBA в автокаде, когда совсем закончится его поддержка, что вы будете делать?

+1

Сообщение от Сергей Дубина Так или иначе, объектную модель врядли отменят.

Это факт.

Сообщение от Сергей Дубина Для акцесса проще написать ВБА и повестить на кнопку. Я имел ввиду VBA в Акцессе и доступ через объектную модель (библиотеку типов автокада), сам автокад предварительно не открывая.

А ты сам-то пробовал сделать это? Ой-ли проще, да ещё и "сам автокад предварительно не открывая"(с)?

[Сергей Дубина]

Сообщение от hwd А ты сам-то пробовал это?

В 2005 г. чертил таблицу примитивами (встроенных ещё не было).

[rassom]

Сообщение от hwd >rassom Видео смотрел? Похоже на то, что искал (по теме топика)?

Ссылка на видео не работает. (Access Denied)

[hwd]

Сообщение от Сергей Дубина В 2005 г. чертил таблицу примитивами (встроенных ещё не было).

Через объектную модель AutoCAD, не открывая его?

[Сергей Дубина]

Сообщение от hwd Через объектную модель AutoCAD, не открывая его?

Совершенно верно.

[hwd]

Сообщение от rassom Ссылка на видео не работает. (Access Denied)

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

[Сергей Дубина]

Сообщение от hwd Через объектную модель AutoCAD, не открывая его?

Вот пример база db1 в ней Форма1, надо выбрать трассу и жать кнопку с биноклем, ошибок не обрабатывал, чертит трассу в файл рядом с базой. акцес-2003, автокад 2009 (2008, 2007)

[hwd]

>Сергей Дубина
Довольно таки недурно... Правда если "придираться", то возникает ряд небольших замечаний:
1. В коде жёстко задано, чтобы mdb-файл находился в "Моих Документах" - иначе файл не находится и генерируется ошибка.
2. Не проставляется нумерация точек (причём желательно на спец. отведённом для этого дела слое).
3. Хранить все данные в одной таблице, в данном случае нецелесообразно, в виду дубляжа информации (но для примера сойдёт). Вносить данные в такую таблицу тоже довольно таки неудобно.
4. Пользователь жмет кнопку, и сидит в ожидании сообщения, что мол операция выполнена, а сообщения никакого нет...
5. По поводу VBA-кода: код довольно компактный (весомый плюс). Замечания следующие:
5.1 Открывать подключение нужно как можно позже, а закрывать, как можно раньше. Поэтому строки кода

Код:

[Выделить все]

dbRst.Close
dbConn.Close

Лучше размещать сразу после строки

Код:

[Выделить все]

Next i

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

===================

В целом предложенный вариант решения мне понравился (указанные выше замечания легко устранимы).

[Сергей Дубина]

Приведенный пример лишь демонстрация возможностей. В нем также не учитывается толщина линии о которой просил автор.

По замечаниям:

Сообщение от hwd 1. В коде жёстко задано, чтобы mdb-файл находился в "Моих Документах" - иначе файл не находится и генерируется ошибка.

В коде я жестко путь не прописывал, видимо он гдето в .mdb сидит.
п. 2 - не задавался целью.
п. 3 - Давай не будем, об этом можно спорить бесконечно.
п. 4 - Согласен
п. 5.1. Согласен, спасибо.
п. 5.2. Посоветуй статейку к.л. на эту тему.

[hwd]

Сообщение от Сергей Дубина Давай не будем, об этом можно спорить бесконечно.

А спорить и не нужно, есть такое понятие, как нормализация баз данных. Избыточности информации однозначно быть не должно (это даже не обсуждается). Поэтому указанное мною в п.3 - это указание на ошибку в проектировании структуры базы данных (если придираться).

Сообщение от Сергей Дубина п. 5.2. Посоветуй статейку к.л. на эту тему.

Ну, тут даже если логически рассуждать, можно увидеть минус:
- если по какой либо причине спустя некоторое время нужно будет подправить запрос - придётся вносить изменения в код и перекомпилировать его, а это не есть гуд.

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

Помнится в 2008 году я был на презентации MS Visual Studio 2008 в СПб, и там показывали пример, в котором программист прописал sql-запрос в коде приложения. Докладчик прокомментировал этот код так:
"Надеюсь, что программист, написавший данный фрагмент кода, более не работает в этой компании".

Вообще в идеале нужно взаимодействовать с базой данных посредством хранимых процедур, принимающих нужные параметры - это позволит избежать SQL-инъекций (ей зачастую подвержен код в котором для построения запроса используется конкатенация строк).
Поскольку хранимка находится в базе данных, модификация запроса хранимки не потребует перекомпиляции исходного кода программы + защита от SQL-инъекций.

Сообщение от Сергей Дубина В коде я жестко путь не прописывал, видимо он гдето в .mdb сидит.

Нет. Думаю, что он использует значение CurrentDirectory - каталог, который был выбран в последнем сеансе работы диалогового окна открытия файла/каталога в ОС Windows.

[Сергей Дубина]

Вот любите вы программеры из пушки по воробьям стрелять.

Сообщение от hwd А спорить и не нужно, есть такое понятие, как нормализация баз данных. Избыточности информации однозначно быть не должно (это даже не обсуждается). Поэтому указанное мною в п.3 - это указание на ошибку в проектировании структуры базы данных (если придираться).

Телефонный справочник на 20 человек ты тоже будешь нормализовывать?

Сообщение от hwd Помнится в 2008 году я был на презентации MS Visual Studio 2008 в СПб, и там показывали пример, в котором программист прописал sql-запрос в коде приложения. Докладчик прокомментировал этот код так: "Надеюсь, что программист, написавший данный фрагмент кода, более не работает в этой компании".

На подобных мероприятиях царит атмосфера "буржуазной деловитости", однако в своих хэлпах они приводят код с вставленным sql.

Сообщение от hwd Нет. Думаю, что он использует значение CurrentDirectory - каталог, который был выбран в последнем сеансе работы диалогового окна открытия файла/каталога в ОС Windows.

А это надо еще проверить!

[hwd]

Сообщение от Сергей Дубина Телефонный справочник на 20 человек ты тоже будешь нормализовывать?

Неважно на сколько человек. Это сегодня тебя потребовалось на 20, а через неделю вдруг окажется, что нужно на 200 (в жизни такое встречается часто). Разве сложно сразу создать не одну табличку, а две? Не сложно... тогда почему сразу не делать грамотно, если это не требует больших затрат?

Сообщение от Сергей Дубина Вот любите вы программеры из пушки по воробьям стрелять.

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

Сообщение от Сергей Дубина На подобных мероприятиях царит атмосфера "буржуазной деловитости", однако в своих хэлпах они приводят код с вставленным sql.

Это приводится для уменьшения объёма кода. Часто в начале хелпа делается предупреждение, что мол

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

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

Сообщение от Сергей Дубина А это надо еще проверить!

Ну так проверь
Я писал:

Думаю, что

Т.е. это было моё предположение (непроверенное).

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

[Сергей Дубина]

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