Администрирование SQL.

← →
MsGuns © (2006-05-30 12:57) [0]

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

Как организовано комплексное администрирование БД и ПО в ваших конторах ? Существуют ли стандарты техдокументации на проектирование, внедрение и эксплуатацию серверных и клиентских приложений ?

Буду весьма признателен за информацию, советы, полезные ссылки.

← →
Sergey13 © (2006-05-30 13:05) [1]

ИМХО название топика мало связано с его содержанием. Ты спрашиваешь про порядок в ИТ-подразделении организации. Чем контора крупнее (и ИТ соответственно) и более разноплановая тем порядка меньше и меньше.
Если честно - не завидую я твоей новой работе. Напоминает авгиевы конюшни.

← →
MsGuns © (2006-05-30 13:07) [2]

>Sergey13 © (30.05.06 13:05) [1]
>Если честно - не завидую я твоей новой работе. Напоминает авгиевы конюшни.

А я люблю трудные задачи ;))

← →
Sergey13 © (2006-05-30 13:18) [3]

2[2] MsGuns © (30.05.06 13:07)
Удачи. Искренне.

← →
Elen © (2006-05-30 14:01) [4]

>MsGuns

У нас похожие проблемы. Конструкторское подразделние (~140 юзеров, ПО - AutoCAD+MDT6, Kompas,Spot Light 5,Word). Информация хранится на файл-серверах, пользовательские папки с ограниченным доступом, но внутри них у каждого - полный доступ. Отсюда полный хаос - каждый юзер устанавливает свои правила обозначений папок/файлов. Найти что-нибудь крайне трудно. Усугубляется проблема полным нежеланием администрации что-либо изменить в административном порядке (хотя мы убедились - только административные меры недостаточны). Сейчас прорабатывается вопрос комплексной среды проектирования с достаточно жесткими правилами создания папок/файлов, когда имена даются ТОЛЬКО после заполнения регистрационных карточек по жестким правилам/проверкам на допустимость. Я рассматриваю разные возможные варианты решения этой задачи вплоть до самых нестандартных (перехвата действия в других программах)

> Существуют ли стандарты техдокументации на проектирование?

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

← →
Sergey13 © (2006-05-30 14:15) [5]

2 [4] Elen © (30.05.06 14:01)
Если

>Сейчас прорабатывается вопрос комплексной среды проектирования

то почему бы совсем не уйти от "папок/файлов" в сторону БД?

← →
tesseract © (2006-05-30 14:26) [6]

А на novell перейти не пробовали?
Или поставить сервер индексирования документов?

← →
MsGuns © (2006-05-30 14:27) [7]

Я в принципе определился с хранением:
Сервера делятся на
1. Промышленные (для хранения текущих корпоративных данных, оперативно использующихся подразделениями предприятия)
2. Тестировочные (для проектирования и отладки)

БД регистрируются у админа БД (пока это функция сисадмина, но планирую у него забрать), им же сохраняются, журналируются и тд)
Каждая БД в своей папке, доступ которых клиентам сети воспрещен. В этой же папке сохраняются архивы с проектами и документацией. Изменения в архивах выполняются сисадмином по служ.запискам по завершению внедрения или выпуска новой версии ПО.

Хуже со стандартами. Видимо, придется разрабатывать самому ;(

← →
Sergey13 © (2006-05-30 14:38) [8]

2[7] MsGuns © (30.05.06 14:27)
>Хуже со стандартами. Видимо, придется разрабатывать самому ;(
Разарабатывать свой стандарт не так уж и плохо - сам себе хозяин. Самое сложное - постоянно и неуклонно следовать стандарту в реальной жизни, которая как правило очень многогранна. Иначе хоть со стандартом, хоть без него - результат один - хаос.

← →
Elen © (2006-05-30 15:40) [9]

> Sergey13 © то почему бы совсем не уйти от "папок/файлов" в сторону БД?

Так и надо бы, но это связано с глубокой перестройкой всей системы существующей на предприятии в данное время, но БД предполагаются как ядро проекта

> Sergey13 © Самое сложное - постоянно и неуклонно следовать стандарту в реальной жизни, которая как правило очень многогранна. Иначе хоть со стандартом, хоть без него - результат один - хаос.

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

>MsGuns © БД регистрируются у админа БД (пока это функция сисадмина, но планирую у него забрать), им же сохраняются, журналируются и тд)
Каждая БД в своей папке, доступ которых клиентам сети воспрещен. В этой же папке сохраняются архивы с проектами и документацией. Изменения в архивах выполняются сисадмином по служ.запискам по завершению внедрения или выпуска новой версии ПО.

У нас на предприятии существуют две подсистемы конструкторской документации: конструкторская спецификация (на базе БД) и конструкторская документация (файловая), которые (сейчас совершенно не связаны). То-есть пользователь клиентской программой заполняет БД спецификаций для организационно-экономических задач. Такой процесс достаточно жестко контролируется доменными админами. А конструкторская документация хранится в виде файлов на локальных серверах нашего подразделения. Поэтому и возникла идея связки БД спецификаций и файловой системы. В таком случае в спецификации УЖЕ имеется идентификакционная информация о чертеже, значит заполнив БД и привязав к ней файл (с любым именем) есть возможность его переименовать/переместить в нужную папку с ограниченным доступом. После окончания проекта БД спецификации закрывается (по доступу на изменения) и тем самым, закрывается доступ на модификацию чертежа.
Что касается хранения чертежей в memo/blob полях, то такй вариант возможен, но имеет свои недостатки (мы много работаем с 3D-графикой, а это объем для сети). Известные нам системы КД на этом принципе (Search 7, TDSM e.t.c) почти хороши, но они сделаны УНИВЕРСАЛЬНО, и не имеют (как правило) защиты от мусора, который пользователи спокойно набивают в БД (на соседнем предприятии у наши друзей та же проблема с Search 7). Поэтому наряду с тем что такие системы просто очень дороги, еще значительные суммы нужно тратить на адаптацию (на тех предприятиях, где мы были адаптация тянет до ~50% стоимости приобретения.

А в принципе, можно судить, что несмотря на то, что у нас проблемы с файл-системой, а у автора с "мусорной" БД - трудность одна: WINDOWS плохо предназначен для такой МНОГОПОЛЬЗОВАТЕЛЬСКОЙ работы. Ведь он изначально создавался как ОДНОПОЛЬЗОВАТЕЛЬСКАЯ МОНОПОЛЬНАЯ (для пользователя) OS. И из этх детских штанишек так и не вырос. Наложите на это вольности юзеров - и Вы имете то, что имеете...

← →
Sergey13 © (2006-05-30 15:55) [10]

2 [9] Elen © (30.05.06 15:40)
1. Ваша проблема НИКАК не связана с сабжевой. Проблемы есть у всех, но они не одинаковы.

2. Не надо валить все на Винду. То что Вы не в состоянии, что либо сделать не говорит о ее (винды) недостатках. Она тут вообще с боку. Поставьте Югикс наконец и наслаждайтесь. 8-)

← →
MsGuns © (2006-05-30 16:24) [11]

>Elen © (30.05.06 15:40) [9]

Мне показалось, что у нас с Вами ситауция несколько разная ;))
Вы смотрите на проблему с точки зрения модели документооборота, я же - модели данных и связанных с ними программных средств обработки. У меня не стОит задача увязки конструкторской, технологической и проч. документации в БД и, тем более, увязки ее в какую-то ИТ. Моя задача иная - систематизировать все разрозненные Базы Данных, клиентское ПО и документацию (в основном это инструкции пользователям, терминология, схемы процессов обработки данных и т.д.), создать НОВУЮ МОДЕЛЬ ДАННЫХ (по всей науке ;) ) спроектировать ее и импортировать в нее все задачи (ПО)так, чтобы их технологичность, избыточность и достоверность по крайней мере не ухудшились для конечного пользователя.

← →
MsGuns © (2006-05-30 16:25) [12]

Прошу прощения за "стОит".
Сам не знаю, как получилось :))

← →
Игорь Шевченко © (2006-05-30 16:31) [13]

> WINDOWS плохо предназначен для такой МНОГОПОЛЬЗОВАТЕЛЬСКОЙ
> работы. Ведь он изначально создавался как ОДНОПОЛЬЗОВАТЕЛЬСКАЯ
> МОНОПОЛЬНАЯ (для пользователя) OS. И из этх детских штанишек
> так и не вырос

Нечего на детали пинать, коль паяльник не тем концом держишь
(с) журнал "Радио"

← →
tesseract © (2006-05-30 16:49) [14]

> Поставьте Югикс наконец и наслаждайтесь. 8-)

проблемы с правилами хранения документации уйдут на второй план....

← →
Petr V. Abramov © (2006-05-30 17:15) [15]

> Игорь Шевченко © (30.05.06 16:31) [13]
???
имелось в виду "не за тот конец"?
:)

← →
Игорь Шевченко © (2006-05-30 17:17) [16]

Petr V. Abramov © (30.05.06 17:15) [15]

Цитата точная :)

← →
Elen © (2006-05-31 15:08) [17]

> Sergey13

Уважаемые Мастера!
Вообще-то под ником Elen Выступает колега, но здесь влез я, которого Вы можете назвать Vik. Извините , но еще до появления XT...AT машин довелось мне поработать c терминальными системами на базе СМ и ЕС (если кто помнит).Так вот, работа велась в рамках интегрированного пакета, когда пользователь работал с документацией, понятия не имея где и под каким имененм хранится файл. Его имя/расположение определялось программно. Затем появились Интеловские машины, ACAD,PCAD. Ура и в воздух чепчики... Но пока машин было мало и количество файлов невелико, можно было смириться с вольностями юзеров. Когда я выразился о Виндовс, я имел ввиду не саму Виндовс, а средства управления файлами (Проводник, Командер и т.д.). Меня злит, что есть хорошие системы ведения проектных работ, но в них нет средств нормального ведения проектов с запретами и контролем (по типу старых терминальных разработок). То-есть разработчики хорошо выполнили фцнкционал разработки, но практически не реализовали функционал систематизации (как правило все на откупе юзера). Тем, кто прошелся по мне за Виндозу приношу извинения, но я думал, что они поймут меня правильно. Виндоза, конечно, как ОС не причем.

> MsGuns

Когда я писал о схожести задач, я имел ввиду, что любая МОДЕЛЬ в некотором роде абстрактна (ИМХО). Например, можно рассматривать файлы как некие условные поля БД. Меня в моем положении интересуют любые (даже, извините, сумашедшие) идеи структуризации файловой информации. Для БД имеются много литературы (я и сам 15 лет программировал самоучкой на Фоксе и ВизуалФоксе и не так уж плохо освоил методику проектирования БД). А вот теории по структуризации файлов, способов создания таких систем не попадалось. Схожесть я усматривал достаточно абстрактно.

tesseract
>> Поставьте Югикс наконец и наслаждайтесь. 8-)
проблемы с правилами хранения документации уйдут на второй план....

Наверное имеется в виду UNIX/Linux. Но как можно в них решать надежно вопрос структуризации? Я в них профан. Я ведь имею ввиду не МНОГОПОЛЬЗОВАТЕЛЬСКИЙ режим, а именно средства структуризации файлов/папок. И хоть переход на эти ОС крайне проблематичен, если Вы считаете что там можно рыть, черкните свое мнение и я полезу...

Уважаемые мастера! Влезть сюда меня заставила необходимость, но если Вы считаете, что пишу не в тему или глупости, то обещаю лишь смотреть форум, не высказываясь (кстати форум ВЕСЬМА интересен).
Благодарю Vik

← →
isasa © (2006-05-31 15:16) [18]

Lotus Domino/Lotus Notes не поможет?

← →
isasa © (2006-05-31 15:19) [19]

Да, добавлю.
БД не реляционная, и работал с ней лет 6 назад(релиз R5), сейчас посвежее(7?), но уже там была возможность связки с SQL.
Я к чему, для документооборота, неплохая платформа.

← →
Игорь Шевченко © (2006-05-31 15:20) [20]

> Когда я выразился о Виндовс, я имел ввиду не саму Виндовс,
> а средства управления файлами (Проводник, Командер и т.
> д.). Меня злит, что есть хорошие системы ведения проектных
> работ, но в них нет средств нормального ведения проектов
> с запретами и контролем (по типу старых терминальных разработок).
> То-есть разработчики хорошо выполнили фцнкционал разработки,
> но практически не реализовали функционал систематизации
> (как правило все на откупе юзера).

Вообще-то системы документооборота в Windows не входят. В операционные системы на ЕС и СМ - тоже. Следовательно, если вы ждете готовой системы а-ля Lotus Notes, встроенной в Windows, то ждать можно еще долго с тем же результатом. А вот если не ждать милостей от природы, а написать систему систематизации (пардон за тавтологию), то задачу решить можно с гораздо большей вероятностью.

← →
tesseract © (2006-05-31 15:32) [21]

> Наверное имеется в виду UNIX/Linux. Но как можно в них решать
> надежно вопрос структуризации?

см сайт ibm :-)
А также novell GroupWise.

Решение вопроса структуризации - имхо модно решить наложением хитрых ограничений на запись/чтение папок.

← →
Sergey13 © (2006-05-31 15:34) [22]

2[17] Elen © (31.05.06 15:08)
По такой логике в нарушении ПДД виноваты автомобили. Разъездились. 8-)

← →
MsGuns © (2006-05-31 15:36) [23]

>Elen © (31.05.06 15:08) [17]

Мне кажется, Вы слегка путаетесь в понятиях "файловая система", "документооборот"

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

Злиться не нужно, можно просто поискать. Просто пример:

http://www.dps.kiev.ua/rus/solutions/docob.html#769

← →
Elen © (2006-05-31 15:48) [24]

> Игорь Шевченко

От Vik. Ждать от Windows или других ОС системы документооборота под наши задачи, конечно, не приходится. Сейчас мы как-раз и пытаемся создать пакет для такой работы. Есть некоторые наработки. Проблема-то в том, что нужно убедить руководство или потратиться на имеющиеся пакеты с их адаптацией, или что мы и сами можем это сделать (конечно не на уровне функционала Search , TDSM). Поэтому и ищем любую информацию.

> isasa

Мы понимаем, что иерархии файловой системы более соответствует иерархические БД, но я в них полный нуль, а рзбираться специально для собственных работ не хочется. Что касается Lotus Domino/Lotus Notes, то с их возможностями специально не разбирался, но попробую оценить перспективность.
Дело в том что 9 месяцев юзал SEARCH 7.0 (ИНТЕРМЕХ,пробная версия). Вот и крутятся мысли вокруг аналогичных решений. Если бы не общая цена (с адаптацией), может быть и пытались бы пробить. Но вряд ли, уже пробовали.

← →
Sergey13 © (2006-05-31 15:51) [25]

2[17] Elen © (31.05.06 15:08) или 2 Vik
>Так вот, работа велась в рамках интегрированного пакета, когда пользователь работал с документацией, понятия не имея где и под каким имененм хранится файл.

Вот то, о чем вы сожалеете как о безвозвратно утерянном "из-за Видовс".
Вам нужен такой же по функциональности пакет программ. Можно искать готовое - можно написать самим. Простейший вариант для спеца выльется в месяц работы. Однако даже такой вариант способен навести порядок в документации.
Смысл такой - создается несложная БД с возможностью хранить файлы. Допуски к этим файлам регулируются самой БД и/или программной оболочкой для работы с ней. Выбирая чертеж (или что там у вас), пользователь скачивает его из БД и по типу файла запускается связанное с ним приложение (автокад, ворд и т.п.). Поработав с документом, юзер сохраняет файл в БД.
Основное отличие от хранения просто в файловой системе - жесткая (или такая, какая ВАМ нужна) структуризация и разграничения доступа.

← →
stone © (2006-05-31 15:56) [26]

> пользователь скачивает его из БД и по типу файла запускается
> связанное с ним приложение (автокад, ворд и т.п.).

Есть довольно большие файлы, которые какчать туда-сюда довольно не быстро. Я не знаю, подробностей задачи Elen ©, может там это не актуально.

← →
Sergey13 © (2006-05-31 16:05) [27]

2[26] stone © (31.05.06 15:56)
Я описал общий принцип - конечно всякое может быть. Однако я слабо представляю, как можно не скачивая (все равно откуда) что-то исправить. Если только ками нибудь терминалами пользоваться наверное.

← →
Elen © (2006-05-31 16:27) [28]

> Sergey13

Именно в таком направлении мы и роем прежде всего. Имеется БД Спецификаций (строго контролируемая) и файлы чертежей. Беда в том, что я администрирую файлы, а БД другое подразделение, и как оно согласится изменить давно действующую БД под наши предложения по хранению чертежей в БД - пока неясно (отвечают ни да ни нет).
В прототипной программе мы смоделировали и опробовали пока только связку БД (Фокс)+ссылки на сетевые имена файлов.
Но есть чисто программные моменты, которые пока не опробаваны на прототипе. Наши пользователь много работают с 3D-чертежами, которые могут включать в себя ссылки на другие файлы (их сетевые имена). При файловой системе+БД мы видим выход в программной корректировке этих ссылочных файловых имен (пересборке документа) после переноса его в нужное место с нужным именем. А вот как это сделать, если файл хранится в БД, пока не знаем, хотя и будем пробовать. Есть и некоторые другие непонятки.

> Основное отличие от хранения просто в файловой системе - жесткая (или такая, какая ВАМ нужна) структуризация и разграничения доступа.

С положением о структуризации через БД согласны на 120%

> MsGuns

Такого рода пакеты (TDSM, OutDOCS и еще некоторые, в т.ч. по Вашей ссылке) нам известны. Но они специализированны, как правило, под канцелярский (извините) документоооборот.А конструкторский имеет свою специфику и по нашим предположениям, вряд ли она там может быть достаточно корректно решена

← →
Sergey13 © (2006-05-31 16:33) [29]

2 [28] Elen © (31.05.06 16:27)
> Имеется БД Спецификаций (строго контролируемая) и файлы чертежей.
Вот бы и добавили в спецификации одно поле с чертежом. 8-)

> БД (Фокс)
Ребята! Вы бы еще Парадокс взяли! 8-)

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

Ссылки должны быть в БД, а не в чертеже. Впрочем, тут я не шарю - что у вас там за 3D-чертежи.

← →
Elen © (2006-05-31 16:56) [30]

> Sergey13

VisualFox использовался для прототипа потому, что он спокойненько работает у меня на локальной машине и мне не нужно лезть на недоступный мне Oracle (другое подразделение - общезаводской отдел информационных систем ). И к тому же Paradox у нас есть только в BDE, а сним связываться неохота. Не разворачивать же мне Oracle локально для отработки прототипа.
3D-чертежи можно условно представить как весьма своеобразную БД. Допустим, имеетюся узлы (сборки) с именами У1 и У2, причем У1 содержит в себе детали Д1 и Д2, а узел У2 - детали Д3 и Д1. При этом в У1 внутри (!) вместо размеров, свойств и других характеристик детали Д1 имеется только ссылка на файл Д1, откуда они при прорисовке У1 и берутся. То-есть, 3D-чертежи могут включать в себя во внутреннем формате ссылки на другой файл или часть файла. Поверьте, проще не изложу, если Вы этим не занимались, иначе придется много описывать о формате файлов 3D-чертежей, которые создаются AutoCAD+MDT6
Vik.

← →
ANB © (2006-05-31 19:26) [31]

> разворачивать же мне Oracle локально для отработки прототипа.

15 минут.
С учетом того, что оракл работает на уровне с парентовыми деревьями, его использование будет оправдано.
А 10G Express вообще халявый и ставится очень быстро.

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

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

← →
Elen © (2006-06-01 14:37) [32]

> ANB

В данный момент мы делаем только прототип программы для отработки технических вопросов (чтение информации, взаимодействие компонент и программ и т.д). Поэтому для имитации вполне хватает Фокса, тем более, что я 15 лет на нем работал. Прототип лишь демонстрирует решение некоторых технических вопросов. А затем нормальную программу будет разрабатывать другой отдел - владелец озщезаводской БД на Оракле.
Что касается идеи с промежуточными клиентскими рабочими папками - такая идея пока нам в голову не приходила. Большое спасибо, будем пробовать. Но у нас возникла и другая - попробывать залезть во внутренний формат файлов AutoCAD и поковыряться прямо там. Дело в том, что мы уже извлекаем оттуда кое-какую информацию, попробуеи добраться и до ссылочной информации.
Что касается хранения информации на файл-сервере, это сделано для централизации места хранения разработок нашего отдела. Так мы работаем уже лет 6, в общем скорость работы терпима. Зато упрощается администрирование. До сих пор не отвечал как раз потому, что занимался селективной архивацией файлов рабочих документов.
Vik.

← →
Sergey13 © (2006-06-01 14:47) [33]

2[32] Elen © (01.06.06 14:37)
> В данный момент мы делаем только прототип программы для отработки технических вопросов (чтение информации, взаимодействие компонент и программ и т.д). Поэтому для имитации вполне хватает Фокса,

Как можно отлаживать технические вопросы самолета на модели жигулей? То, что вы пишете (избретаете!) на Фоксе например в части прав и разделения доступа к данным уже давным давно решено в промышленных СУБД на уровне сервера.
Врочем дело ваше.

← →
Elen © (2006-06-01 15:19) [34]

> Sergey13

В данный момент меня СОВЕРШЕННО НЕ ИНТЕРЕСУЕТ как будет спроектирована сама БД в части прав и разделения доступа и т.д.. Нас интересуют вопросы, связанные с работой с документами. В них (документах) есть информация, которую нужно вытаскивать в БД или туда загонять (разработчик, обозначение, наименование и т.д.). Вот для проверки взаимодействия БД (любой) и компонент чтения/редактирования документации мы и моделируем (проверяем). Например, если нужно найти ссылочный чертеж, указанный в одной записи, в другой записи. А что касается прав, доступов, ролей, относящихся собственно к БД, то они будут решаться при полномасштабной разработке (и не мной, см.[32]). Если Вы считаете, мои вопросы не в тему, так и напишите. Я заткнусь. Или попробую пообщаться по E-mail с людьми, которые считают возможным мне помогать хотя-бы советами.

← →
Sergey13 © (2006-06-01 15:39) [35]

2[34] Elen © (01.06.06 15:19)
Че ты так кипятишся то? Никто ничего не считает. 8-)
Я просто пишу свое мнение о том что пишешь ты.
Вот ты написал

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

А надо, ИМХО, с точность до наоборот. Все связи, обозначения, наименования и прочая и прочая должны быть в БД. Спецификация же есть? Есть. Что это такое? Состав изделия. Из чего оно состоит? Из узлов и деталей, на которые должны быть чертежи. Так? Вот я бы и сопоставил каждой детали (узлу) - свой чертеж. Т.е. выбрал деталь в спецификации - получи чертеж, а не наоборот.

← →
Elen © (2006-06-01 16:35) [36]

> Sergey13

Извини, погорячился, показалось, что вам уже неинтересны мои проблемы.
Может быть, я и ошибаюсь, но по-моему у Вас не совсем верное представление о процессе конструирования. Для сведения, у меня стаж - 15 лет конструирования, 15 лет программирования. Обьясняю.
Когда конструктор начинает проектировать изделие, он понятия не имеет, сколько и каких узлов/деталей будет в ОКОНЧАТЕЛЬНОМ варианте. Поэтому он сперва делает целый ряд проработок (по конструкторски - прорисовок). В ходе прорисовки он отрабатывает состав узла. И лишь потом, выбрав окончательный вариант, он разрабатывает (оформляет) по всем правилам чертежи и может составить спецификацию. Конечно, теоретически, он может составить спецификацию и ДО ОФОРМЛЕНИЯ (по прорисовкам), но насколько мне известно, никто и никогда так не делает. Поэтому спецификация оформляется , как правило, последней. Но информация, заносимая в спецификацию, УЖЕ сидит в документации. И чтобы не вносить ее ручками заново, и возникла идея выдернуть ее оттуда автоматически (или полуавтоматически). Когда запись в БД и чертеж сопоставлен - нет проблем, но вот заполнение БД спецификации без разработанных (оформленных) чертежей вряд ли возможно чисто по практическим соображениям. Кстати, в Search сделано как раз по твоему рецепту. Конструктор разрабатывет ВСЕ проработки и хранит их БД. Вот и представь себе сколько там мусора. А чистить его у конструкторов, как правило, руки не доходят, кстати, как и при чисто файловой системе. Ведь все мои проблемы как раз в том и сосотоят, что имеется куча файлового мусора. Например, сегодня делал общее архивирование за месяц с помощью небольшой утилиты. Так вот всех файлов на сервере ~200 тыс., а в архив было отобрано (отбор по рабочим расширениям DOC, DWG, CDW,TIF) попало только ~60-70 тыс. файлов. при этом я УВЕРЕН, что окончательно оформленных документов может только примерно половина (остальное проработки). Уж извини за длинное разъяснение, но может быть, я как бывший конструктор, зациклися и не могу глянуть на проблему свежим взглядом.

← →
MsGuns © (2006-06-01 16:44) [37]

>А чистить его у конструкторов, как правило, руки не доходят, кстати, как и при чисто файловой системе

Тогда БД ничего не даст, кроме прятания "мусора" вместе с нужным.
Все, что Сергей сказал по поводу того, "кто на ком должен стоять", есть истина и единственный путь к ПОРЯДКУ.
Пытаться автоматизировать бардак - дело абсолютно безнадежное.
Вам необходимо разработать прозрачную модель документооборота, удовлетворяющую неким исходным требованиям, и всех заставить работать только в рамках этой модели (для этого, собственно и придумали БД). Другого пути - нет.

← →
Sergey13 © (2006-06-01 16:55) [38]

2[36] Elen © (01.06.06 16:35)
Да я в общем то тоже кой чего понимаю в конструировании. Даже помню справочник Федоренко и Шошина. 8-)

>Уж извини за длинное разъяснение, но может быть, я как бывший конструктор, зациклися и не могу глянуть на проблему свежим взглядом.

Вот похоже на то. В принципе можно идти и тем путем, что ты хочешь. Но...! Если бы ты был разработчиком АвтоКада например. Т.е. Автокад был бы первичен, а тебе надо бы было приделать к нему систему хранения чертежей. Тогда да.
Но у тебя то ситуация обратная - есть "черный ящик" Автокад (или Ворд или еще чего - не важно) и надо к спецификации приделать файлы чертежей, описаний и прочего для производства и всевозможного учета (насколько я понял). Тут в принципе не важна последовательность проектирования - важно, что "первая копия" чертежа хранится в БД. Иными словами на компе конструктора может храниться что угодно, но все остальные видят только ту самую "первую копию" из БД.

Одна идея тут у меня проскочила - строка пути в файловой системе к файлу чертежа в принципе может являться ключом для поиска этого чертежа в БД. Может это как то присандырить к твоему варианту.

← →
Elen © (2006-06-01 16:59) [39]

> MsGuns

Я бы с Вами ПОЛНОСТЬЮ согласился. но есть возражение. Реально имется в данный момент 2 подсистемы. Одна на БД спецификаций очень строго проверяется на мусор. А чертежи хранятся в файлах. Задумка такая. Конструктор разрабатывает сколько угодно вариантов. Затем заполняет спецификацию. Пока сам конструктор не закрыл спецификацию (не подтвердил окончание работы), он может в спецификацию вносить любые изменения. Но как только он закрыл спецификацию, она автоматически переходит в режим только чтение (запрет внесения изменений). Можно автоматически проверить, связал ли конструктор запись в БД с каким-нибудь файлом, и если нет, запретить закрытие БД на редактирование. Затем можно файлы, соотнесенные к записям БД, переместить в соответствующую папку, недоступную рядовому юзеру, с нужными именами. Это и будет точное соответствие спецификации к набору файлов, фактически архив рабочей документации. Конечно, имеются ряд тонкостей, но пока я излагаю только общую концепцию.
Vik

← →
MsGuns © (2006-06-01 17:26) [40]

>Elen © (01.06.06 16:59) [39]

Вы описали типовую схему работы инженера (совсем не обязательно конструктора):
Задача - Проект - Решение - Эксперимент - Результаты - Проект - Решение - Эксперимент - Технология
Любая правка - это тот жу путь по второму кругу. В когце всегда должна быть технология, в Вашем случае - конструкторская документация.
Изменение технологии делается не абы как, а с помощью конструкторских (технологических) извещений, которые подписываются, утверждаются и только потом отражаются "в металле". Для "тонких", промежуточных случаев есть проекты извещений, которые могут быть оператоивно подправлены или даже отменены без изменения технологии.

Вы, как мне кажется, смешали все в одну кучу: корпоративный документооборот с конструкторской "кухней".
Корпоративная БД вмнсте с чертежами на то и корпоративная, что ни конструкторы, ни технологи, ни вообще кто-либо не мог там свободно лазать и что-то править. Любые "вмешательства" в информациооное пространство БД выполняется в строго определенном порядке, приоритете, правах и объемах, заданных МОДЕЛЬЮ БД. Т.е. для замены чертежа с одного на другой конструктор долеж выпустить извещение, гл.инженер проекта его утвердить, бюро стандартизации проверить и зафиксировать, соотв. служба БД поставить его в очередь изменений.. и т.д., вплоть до изменения цеховых планов, комплектационных карт, планов закупок ПКИ и материалов службой снабжения и т.д.
То же, что творится со старыми чертежами, проблема самого конструктора и гл.инженера проекта. Если вы хотите как-то упорядочить свою "кухню", вам и карты в руки. Мне кажется, что для этого вполне хватает простого архиватора плюс файловой системы (любой - роли не играет) и продуманной схемы документирования (достаточно простой кстати).

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

← →
Elen © (2006-06-02 08:13) [41]

> MsGuns

Все-таки я наверное не смог обьяснить суть моей проблемы. Я согласен с Вашими мыслями насчет корпоративной БД и остального. Но речь идет прежде всего о наполнении БД, когда в ней нет еще ничего по данному новому проекту.
Типичный пример. Конструктор выполнил проработку, принял окончательный вариант, оформил, сохранил в файле. Но также сохранил и все промежуточные результаты в виде файла. Поскольку он работает в пакетах, допускающих сохранение под ЛЮБЫМ именем, появляются файлы, имя которых понятно как правило, только разработчику.
Теперь ко мне приходит главный и говорит примерно так "Есть ДОКУМЕНТ с обозначением 123456СБ в проекте АБВ, а разработчика в данный момент НЕТ (командировка, отпуск и т.д.). Найдите.". Но ведь я имею дело ТОЛЬКО с ИМЕНАМИ файлов. Для того, чтобы найти, необходимо хоть как-то селектировать ФАЙЛЫ (напр. по расширению) и затем смотреть СОДЕРЖИМОЕ каждого файла. Были случаи, когда мы с коллегой искали чертеж 2 дня и не смогли его найти. А начальник не хочет ждать более, например, 1 часа, и считает, что мы полные бездельники.
В отделе уже 4 года есть приказ о правилах именования файлов и порядке сохранения проекта. В нем указан пример обозначения и то, что после завершения файлы проекта (окончательные) ДОЛЖНЫ быть требуемым образом переименованы и сохранены без мусора. Гл. инженер предложил мне составить список нарушителей для показательного наказания, вплоть до увольнения. В этот список из 130 чел. пришлось включить порядка 100 чел. Мне было заявлено, что ради наведения порядка никто не будет увольнять такое количество людей. Поэтому у меня нет никакой надежды решить проблемы ТОЛЬКО административным путем.
Вы говорите

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

Но на стадии разработки без этого не обойтись. Поэтому разработчики имет доступ к неким промежуточным таблица БД, с которыми они иработают, имея полный доступ. Только после закрытия проекта и передачи его в производство можно эти таблицы включить в корпоративную БД и закрыть доступ или его ограничить. Вот мы и пытаемся решить задачу комплексно: Интегрированная среда разработки+Строго контролируемая БД+Административные методы. Если при закрытии проекта в БД нет связок Запись-Чертеж (установленных разработчиком), проект не закрывается, сроки срываются с административными последствиями.
А что касаетс моего хаянья Делфи, то я думаю, что это просто Ваша ошибка. Я "хаял" на то, что после появления ВИНДОВС, разработчики подобных систем конструкторского документооборота перестали использовать идею терминального проектирования, когда пользователь просто не может сохранить все, что только он желает.

← →
Sergey13 © (2006-06-02 09:29) [42]

2 [41] Elen © (02.06.06 08:13)
>Только после закрытия проекта и передачи его в производство можно эти таблицы включить в корпоративную БД и закрыть доступ или его ограничить

Почему? Почему нельзя создать в БД новый проект и присвоить ему статус "В разработке"? Делайте с ним что хотите. Завершили - присвоили статус "Закончен" и далее все как вы думаете.

>Я "хаял" на то, что после появления ВИНДОВС, разработчики подобных систем конструкторского документооборота перестали использовать идею терминального проектирования, когда пользователь просто не может сохранить все, что только он желает.

С моей точки зрения - это набор слов из статьи в женском журнале. Не надо подобных обобщений - не придется потом обижаться. 8-)

← →
Elen © (2006-06-02 10:29) [43]

>Sergey13

Спасибо, Sergey13. Вы в сообщении [38] сформулировали мою задачу/проблему более внятно чем это сделал я. Действительно я имел ввиду, пусть у конструктора будет сколько угодно файлов/проработок, но привязав ОДИН к БД можно считать его ОФИЦИАЛЬНЫМ документом и при любых посках не обращать внимания на все другие. А что касается сообщения [42], почти так оно и есть. Когда открывется новый заказ автоматически создается в БД новая таблица спецификации (главная), открытая на полный доступ конструктору, кроме ее уничтожения, и недоступная всем другим подразделениям. После завершения работы конструктор указывает на закрытие работ над проектом и тогда все таблицы (как главная, так и входящие) автоматически закрываются и им устанавливается доступ "только чтение". Вот как раз и хотелось воспользваться этим обстоятельством. То-есть при подаче сигнала "Закрыть проект" можно выполнить автоматическую проверку на привязку Запись-Чертеж, и если есть записи, не привязанные к файлу, процесс закрытия запрещать, то-есть таблица спецификации остается в режиме полного доступа только к конструктора. Последующие подразделения в технологической цепочке подготовки производства могут использовать информацию ТОЛЬКО после завершения проекта и его закрытия.

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

Самое для меня главное, что в процессе общения Мастера в целом подтвердили (пусть не во всем), что двигамся в нужном направлении.

И еще одно Sergey13. На этом-же форуме поднимался вопрос о том, как заработать деньги при разработке какого-нибудь софта. Не думаете ли Вы что разработка примерно такого специализированного софта, как мы обсуждаем, может быть полезна многим предприятиям?

2[43] Elen © (02.06.06 10:29)
>Когда открывется новый заказ автоматически создается в БД новая таблица спецификации (главная),
Упаси вас боже от такого топорного решения. Никаких новых таблиц!!! Пользователи должны создавать только записи в таблицах. Если это у вас не так - вы создали непродуманное решение (это мякго сказано) в 99% случаев (и не думайте что вы в оставшемся проценте 8-).

>Последующие подразделения в технологической цепочке подготовки производства могут использовать информацию ТОЛЬКО после завершения проекта и его закрытия.

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

>Не думаете ли Вы что разработка примерно такого специализированного софта, как мы обсуждаем, может быть полезна многим предприятиям?

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

>Sergey13

>Никаких новых таблиц!!! Пользователи должны создавать только записи в таблицах

Дело в том, что я плохо знаю Оракл (просто не работал сним). БД расположена на общезаводском сервере, на ходящегося по контолеи другого подразделения ОИС (отдел информационных систем). Может быть я и не прав, но я их понял так, что когда открывается новый заказ, они создают таблицу/таблицы, в которых содержится первоначальная информация (заказ, заказчик, путь прохождения по подразделениям, сроки и т.д.). После обработки этой информации плановым отделом ОИС (по-моему) и создает либо отдельную таблицу, либо новую запись в БД спецификаций. То-есть к моменту работы уже можно считать, что есть некая пустая спецификация с кодом 0. Но возможно это и не так (нет новой таблицы, а есть только новая запись, к которой привязываются подчиненные). Во всяком случае, новую спецификацию проекта (даже пустую) заполняет (а не создает) конструктор. А вот подчиненные спецификации создаются автоматически уже на базе исходной (наверное,по разделу Сборочные единицы).

>Никто не пострадает от чтения предварительной дакументации например технологами

Согласен с вами, но в данной конкретной ситуации доступ к предварительно прорабатывемой конструкторской документации просто бессмыслен, т.к. ее просто нет (сейчас в БД нет вообще НИКАКОЙ информации по конструкторскому документу). Это тоже один из моментов, который мы хотели бы решить. Связка Запись-ФайлЧертежа мог бы боле оперативно решать вопросы согласования со смежными подразделениями. То-есть в данном случае Вы правы и мы с Вами согласны.

Что касается вопроса продажи софта, то мы лишь подумали, что Мастера обсуждают вопрос о том, с каким софтом (игры, интернет и т.д.) можно выходить на рынок и не взяться ли виртуальному коолективу за такую работу. Звучало мнение, что это может быть специализированный софт. Вот и подумалось, может быть такой вид софта мог бы занять некоторую нишу.
Ссылка на ветку http://delphimaster.net/view/15-1148747923/. Но участвовать в нем мы вряд ли сможем (разве что советами практиков конструирования). Даже если такой софт будет сделан на предприятии, продавать его мы ,конечно, не сможем. А вот Мастера...

← →
Percent (2006-06-02 11:40) [46]

А отчего бы не перехватывать запись/чтение на диск?
В случае записи - проверять имечко на соответствие стандартам наименований, и выдавать сообщение, мол "переименовать надо бы, согласно стандарта". По факту записи - делать копию в БД, по факту попытки прочитать файл с диска - читать его из БД и подсовывать считывающему. Первичный ключ - имя файла с полным путем. Перехватывать запись/чтение всех файлов со стандартными расширениями (dwg и пр.).
Запретить работу со всеми сетевыми дисками стандартными методами.
Сделать эдакий свой собственный виртуальный диск, через который документы сохраняются/извлекаются в/из БД. И версионный контроль реализовать. Вплоть до дополнительного диалога, всплывающего при записи/чтении, в котором заставить пользователя вводить требуемые данных (коды, шифры и пр.).

>Percent

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

2[45] Elen © (02.06.06 11:25)
>Дело в том, что я плохо знаю Оракл

Это непринципиально. Метаданные БД плохо менять в любом случае.

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

Не согласен. Специалист уже по названию детали на 90% скажет какой у нее будет техпроцесс, расцеховка оборудование и т.п. "Крышка редуктора" или "фланец" говорят сам за себя.

>Elen © (02.06.06 11:53) [41], [43], [45], [47]

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

И еще по поводу "продажи".
Мой добрый совет: забудьте об этом и никогда никому не говорите. Занимайтесь тем, что Вы умеете хорошо делать - конструированием. Где у Вас есть реальный шанс заработать.

> Percent А отчего бы не перехватывать запись/чтение на диск?

А какими способами Вы предлагаете это делать? Скажите пожалуйста

>Sergey13
Метаданные БД плохо менять в любом случае

С этим высказыванием в сообщени [48] согласен. Меня, как посредника между службой конструкторов и службой ведения БД, не очень интересуют работа с метаданными (хорошо/плохо). Пусть ломают головы в ОИС, им это реализовывать.

>Специалист уже по названию детали на 90% скажет какой у нее будет техпроцесс, расцеховка оборудование и т.п.

Вообще-то, Вы правы. На начале моей работы предполагалось, что конструкторы, прорабатывая варианты, будут в электронном виде согласовывать с технологами даже варианты. Для этого были предназначенны даже папки обмена информацией и средства внесения замечаний со стороны технологов (Volo View), которые позволяли технологу прямо на DWG-файл наносить замечания, не изменяя исходного файла. К сожалению, ОГТ весьма консервативен, и не желает этим пользоваться. Поэтому мы и не ставим на данной стадии вопрос о, скажем так, параллельной работы нескольких служб над проектом. Дай бог хоть навести нормальный порядок с рабочей документацией
Vik.

>Меня, как посредника между службой конструкторов и службой ведения БД, не очень интересуют работа с метаданными (хорошо/плохо). Пусть ломают головы в ОИС, им это реализовывать.

Это ошибка. Достаточно серьезная.

2[51] Elen © (02.06.06 12:58)
> Поэтому мы и не ставим на данной стадии вопрос о, скажем так, параллельной работы нескольких служб над проектом.
Чем раньше вы поставите этот вопрос - тем меньше придется переделывать. 8-)))))))))))))))
Кострукторы ведь не боги, как и технологи, впрочем. Иногда технолог только взглянет на чертеж и скажет "фигня дело, мы такого не сможем". И фсе, весь ваш "законченный и сданный" проект летит вверх тормашками. 8-)

>Sergey13

Вы абсолютно правы, но мне приходится соблюдать определенную дипломатию. Прототипную программу мы создаем как раз для того, чтобы продемонстрировать возможность создания хотя бы удобного средства систематизации конструкторской документации. Напоминаю, полномасштабная разработка будет вестись не нами, а нашим ОИС, а их тоже нужно заставить. Если поднять еще и этот вопрос, можно вообще похерить задумку. Другое дело, в полномасштабной программе заложить возможность развития в этом направлении c минимальными доработками (но это тоже требует усилий - возражения типа "А зачем это сегодня надо..."). Я понимаю, что для Вас это может звучать дико, как и для меня, но такова реальность.
Vik

2[54] Elen © (02.06.06 14:02)
> но мне приходится соблюдать определенную дипломатию.
Вот он - краеугольный камень построения любой ИС! Автоматизирующие хотят революции, а автоматизирумые не хотят ничего менять. Причем это может меняться на 180 градусов (как у вас, как я понял 8-). Пока проект (!) не будет одобрен и поставлен на контроль кем то из первых лиц конторы любые действия по автоматизации буду мучительной попыткой родить мертвого ребенка. И это уже не ИМХО практически.

>Sergey13

Да, Вы правы - это краеугольный камень. Пока 4 года назад лично директор завода проталкивал автоматизацию к нам в ОГК, мы могли ногой открывать к нему двери, он как мог поставлял техниу и требовал расширения, внедрения, улучшения... Не могу сказать, что мы имели все что хотели, но ОГК на сегодняшний день самый крупный держатель машин (40 шт., хотя нам этого мало). Предполагалось довести парк машин до 100-110 шт на 130-140 сотрудников. Даже то, что в ОГК (отделе главного конструктора) имеются программисты (я и Elen), чего больше нет ни в одном подразделении - его заслуга. Только 3 года назад хозяева его выкинули, ну началось... В руководстве зачастую даже не понимают, а что на компах можно делать (хотя-бы в принципе). Извините за плач в жилетку... Думаю, что и Вы это прошли, поймете, почему ограничения и т.д.
Vik.

2[56] Elen © (02.06.06 14:34)
>он как мог поставлял технику
>В руководстве зачастую даже не понимают, а что на компах можно делать (хотя-бы в принципе).

Это они (начальство) любят - "мы же вам столько компьютеров понаставили!" 8-)
Это говорит о том, что у прежнего директора не было конвретного плана действий по автоматизации, а были разрозненные мысли после посещения заграницы и чтения популярных журналов. Покупка компьютеров вагонами - тоже ведь не всегда оправдана.

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

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

Да, было и такое... Но его тоже можно понять. За 5 лет поднять уникальный завод (в СССР таких, кроме нас, еще один) с нуля до пусть и не 100% загрузки в бытность лучших времен. Ему просто не хватало времени (масса других забот+не лучшие первые помощники). Он поручил все работы по автоматизации ОГК молодому энергичному парню, дал ему карт-бланш и как мог помогал. Этот парень и привлек нас сюда. Но получилось так, что конструирование делали мы, а все остальное ОИС (экономика, планирование, бухгалерия и тд.). Вот и получились как-бы две независимо функцонирующие подсистемы. Отсюда и результат. А теперь нет ни этого парня, ни поддержки на хоть сколько-нибудь существенном уровне. Недавно появился перспективный зам. главного инженера. Первое, что он сделал, пришел к нам и плотно поговорил о нашем видении перспективы. Мы показали ему два варианта прототипных программ (был уже и первый без использования БД). Он обещал всяческую поддержку. Окончилось тем, что сейчас его так загрузили расхлебыванием узких мест в производстве, что он и в кабинете не бывает. Более того, в разговоре проскользнуло желание похерить все это и уйти. Вот так и бывает, наверное, когда к руководству машиностроительным предприятием приходят люди, умеющие только торговать Сникерсами.

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

← →
Percent (2006-06-02 19:31) [60]

А какими способами Вы предлагаете это делать? Скажите пожалуйста

http://delphimaster.net/view/15-1148747923/

[1], [2], [3], [4]

← →
Percent (2006-06-02 19:46) [61]

Бумажная книга "Недокументированные возможности Windows 2000" Свен Шрайбер:
http://oz.by/books/more103360.html

В интернете есть в неофициальном электронном виде (все время задаюсь вопросом, что значит "электронный вид"?). Найти легко самому. (Правила форума, однако, не позволяют разместить здесь ссылку на электронный вариант; авторские права там всякие, то да се).

Исходники и откомпилированные примеры к книге (официальная версия):
http://www.unix.kg/cache/examples/SchreiberSRC.zip

> k2

Да, мы 9 мес. юзали пробную версию Search 7.0. Хороша, ничего не скажешь. Ездили по предприятим, где она эксплуатировалась. Но тогда же и поняли один недостаток. Все такие системы делаются достаточно универсально (то-есть завод покупает, ставит и эксплуатирует, а за организацию порядка отвечает завод/пользователь . Но ведь и при использовании файловой системы можно иметь порядок - но не тут то было (см.[54...58]). Когда мы разобрались, поговорили с ИНТЕРМЕХом, оказалось, что они МОГУТ доработать для нас этот момент, но цена... На этом все и застопорилось.

Администрирование SQL. Найти похожие ветки