[Uladzimir 80]

Будьте осторожны! Я тут недавно выбирал что-то на сайте чип и дипа, так тоам была ошибка в значении какого-то параметра.

Да я знаю. Они бывают даже у самих производителей

Для подогрева вот скинул еще картинку с параметрическим поиском прямо в схемотехническом редакторе. На ней - поиск реизстора по парочке параметров и установка одного из подошедших кандидатов на схему (выделенный).

По своим библиотекам в алтиуие это тоже есть, немного в другом виде.

Более того есть поиск и по 4 поставщикам Дижи-кей, фарнелл, ...

 

[vitan 2]

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

Что конкретно интересует? Там ничего особенного нет, просто некий движок, позволяющий отслеживать состояния во времени. Программируемый автомат (машина состояний) с веб-интерфейсом, пользователями, связью с БД, конструктором форм, оповещением по е-мейл. В последних версиях появилаь интеграция с системами управления мастер-данными типа TalendMDM и еще куча всего. Мне просто некогда все это отслеживать, хотя я и заинтересован в создании некоей системы типа PLM для своих разработок. Кстати, приглашаю заинтересованных обсудить формат хранения данных здесь. Хотя на меня тоже иногда находит апатия и возникает желание поставить вот это, где все есть, и забыть... Там альтиум, вроде, не поддерживается.

Просто поставьте для начала, будут вопросы - готов помочь.

Ну, а связь этой системы с БД, как я понял, будет через поле "проверено"? Тогда советую ввести еще парочку полей: создатель, последний редактор и признак находждения на редактировании.

У меня все это работает так: человек открывает форму для правки и одновременно компонент "берется на редактирование" (признак выставляется в true). Когда процесс проверки отработал, он автоматически выставляет признак "проверено". Процесс невозможно запустить дважды, ибо он перед запуском проверяет поле признака нахождения на редактировании. Ну, и после проверки можно отследить последнего утвердившего юзера. А другие юзеры, которые принимали участие в проверке, вместе со своей перепиской сохраняются в базе процессмейкера (она у него своя, хотя их можно и объединить).

 

Очень помогает отключить проверку антивирусами файлов определенного типа.

Да, точно.

 

По своим библиотекам в алтиуие это тоже есть, немного в другом виде.

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

 

Более того есть поиск и по 4 поставщикам Дижи-кей, фарнелл, ...

Да, это есть во всех перечисленных мной выше системах. Но "это не наш метод". :)

[jkrieger 0]

vitan, поставить поставил. Вот эту - http://www.bonitasoft.com. Вообще системы Workflow для меня новое направление и очень интересное. Но пока я буду разбираться задам вам вопрос.

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

 

И еще одно размышление-сомнение. Если БД будет модульной, расчитанной на несколько САПР, то мне как пользователю Altium Designer не имеет значения есть ли компонент в базе или нет, пока не нарисованы его символ и футпринт именно для AD. Можно не выводить в список доступных. Но тогда получается такая ситуация, что база вроде бы одна, но внутри она будет все равно делиться на три/четыре (по количеству САПР). И общее у них будет только структура.

 

Поэтому, есть ли смысл усложнять структуру БД ради "САПРонезависимости"?

 

 

[vitan 2]

Из того что я увидел эта система лишь позволяет при помощи форм выполнять свои функции каждому участнику процесса.

Ну, как бы на второй странице сайта написано:

Connect with everything

 

Bonita Studio comes with a large number of ready-to-use connectors - for databases, messaging and more. If what you need isn't already there, it's easy to add new connectors and share them with the Bonita Open Source BPM community

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

 

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

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

Так вот, в зависимости от избранного варианта и будет по-разному происходить коннект к БД. Я так понял, после критики по поводу репликации Вы от этой идеи отказались? Тогда Вам надо что-то выбрать. Я не могу Вам советовать, это дело Ваше, я все-таки пока не планирую активного участия в проекте, могу пока лишь помогать общими фразами :) и рассказать, как это реализовано у меня. У меня есть сервер, и я там админ. САПР коннектится через HTTP (в состав САПР входит спец. комплекс софта, который обеспечивает предоставление данных по HTTP от ODBC) к ODBC; тот, в свою очередь, к БД. Имея HTTP, клиент не знает, где физически находится БД (для ODBC нужно указывать физическое расположение, как известно). Это очень важно, думаю Вы понимаете, почему.

Т.к. у меня не было цели создавать базу для широкой общественности, то я не разбирался в принципах работы HTTP, передающего данные, и ODBC. Помочь, соответственно, не могу.

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

 

Поэтому, есть ли смысл усложнять структуру БД ради "САПРонезависимости"?

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

Ответьте, Вы собираетесь всю жизнь пользоваться альтиумом? Вас не смущает, например, тот факт, что эта фирма взяла, и прекратила поддержку пикада, на котором у нас большинство работает? И при этом вывешиват рекламы с угрожающими надписями и мужиками в ушанках, намекая на Колыму? :)

[masterofnature 0]

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

Ответьте, Вы собираетесь всю жизнь пользоваться альтиумом? Вас не смущает, например, тот факт, что эта фирма взяла, и прекратила поддержку пикада, на котором у нас большинство работает? И при этом вывешиват рекламы с угрожающими надписями и мужиками в ушанках, намекая на Колыму? :)

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

 

Что касается УГО и ФутПринтов: при выборке варианта для АД можно сделать, например, фильтрацию по полю "Схемное изображение".

Если поле незаполнено, то компонент не готов к установке в АД.

Или же в запросе возвращать все компоненты, но для тех, для которых нет УГО, в предпросмотре ничего не будет изображаться.

 

Дополнительный вопрос к знатокам скриптов: возможно ли в АД запрограммировать форму, в которой можно будет вводить требуемые параметры, а в ответ получать краткий перечень компонентов для установки?

[тау 31]

Дополнительный вопрос к знатокам скриптов: возможно ли в АД запрограммировать форму, в которой можно будет вводить требуемые параметры, а в ответ получать краткий перечень компонентов для установки?

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

одной из рабочих функций является типо такая

Comp := SchServer.LoadComponentFromDatabaseLibrary('C:\EDA.DbLib',NewTable,NewPart);

 

при том что NewTable и NewPart должны быть известны "до того" как обращаться к функции.

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

 

[jkrieger 0]

vitan, начну с конца.

 

Ответьте, Вы собираетесь всю жизнь пользоваться альтиумом? Вас не смущает, например, тот факт, что эта фирма взяла, и прекратила поддержку пикада, на котором у нас большинство работает? И при этом вывешиват рекламы с угрожающими надписями и мужиками в ушанках, намекая на Колыму? :)

Поверьте, ничуть не смущает. Ну перестали поддерживать пикад и что? Мы им пользуемся и не страдаем. Я знаю людей, которые до сих пор на 2000 сидят. И продолжают выполнять свою работу. Для меня Альтиум удобен, и он удовлетворяет моим потребностям.

Если же я надумаю сменить САПР, то все равно придется переделывать бОльшую часть работы по созданию библиотеки (создание УГО и футпринтов). Благо структура БД уже будет и не нужно изобретать велосипед.

 

Поэтому, САПРонезависимость нужна только в структуре БД. Но совмещать базы для нескольких САПР - лишнее усложнение.

 

Далее. От Аццесса с репликацией я не отказывался. Схема работает. Может не так безопасно и правильно, как хотелось бы, зато значительно проще в развертывании.

 

Из предыдущего обсуждения.

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

 

Очевидно, Вы выбрали хранение данных под управлением СУБД потому, что СУБД обеспечивает нужные Вам функции. Это и многопользовательская работа, и транзакции, и SQL, и целостность данных, и т.п. Зачем же Вы от всего этого отказываетесь?

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

 

2. Как Вы видите себе работу нескольких пользователей? Допустим, я сделал все, как Вы описали, скачал базу, увидел там конденсатор, поправил в нем что-то, провел репликацию и зафиксировал изменения в SVN. Что увидит сосед, у которого прошлая версия конденсатора уже применена в десяти проектах? Что ему делать? Проводить репликацию с основной базой? Вы представляете его реакцию?

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

Предупреждая вопрос зачем вообще SVN - чтобы контролировать футпринты и УГО.

 

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

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

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

 

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

 

 

UPD: Прошу остальных высказаться по поводу выделенного жирным - согласны или нет.

Изменено 5 октября, 2010 пользователем Jack Krieger

[vitan 2]

Если же я надумаю сменить САПР, то все равно придется переделывать бОльшую часть работы по созданию библиотеки (создание УГО и футпринтов). Благо структура БД уже будет и не нужно изобретать велосипед.

Смысл был не в том, что Вы сами можете собраться поменять САПР, а в том, что альтиум откажется от дизайнера.

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

 

Но совмещать базы для нескольких САПР - лишнее усложнение.

Что такое "базы для нескольких САПР"? Мы так и не договорились о терминах...

Я просто не понимаю эту фразу, честно.

 

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

А что мешает? Вы видели в списке драйверов ODBC драйвер текстовых файлов? (Звучит! :) )

Он там есть.

 

Так что тут SVN-клиент выполняет только транспортную функцию.

Я начинал свои эксперименты именно с этого, только у меня CVS. Я от этого ушел, потому, что хочу пользоваться всеми преимуществами СУБД. Не хотите - дело Ваше. Замечу, что на осознание мне потребовалось несколько месяцев.

 

Предупреждая вопрос зачем вообще SVN - чтобы контролировать футпринты и УГО.

Вот это - по делу. Я тоже контролирую эти вещи системой контроля версий. Просто она предназначена именно для этого.

 

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

Не спорю, но, если у Вас был бы время, и желание, то Вы могли бы развернуться и по первому варианту.

 

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

Не согласен. Этот принцип приводит к увеличению беспорядка в геометрической прогрессии.

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

"Как обычно" мы знаем. Если назвать вещи своими именами, то - "через ж...". :)

 

пока это остается таким вот альтруистическим увлечением

Вы хотите поиграться и не использовать это в работе? Ну, тогда нам не по пути... :(

[jkrieger 0]

Что такое "базы для нескольких САПР"? Мы так и не договорились о терминах...

Я просто не понимаю эту фразу, честно.

Тут я имел в виду, что данные о компонентах для различных САПР не нужно хранить в одном файле. Просто я так понял ваше предложение об общей БД, что все САПР будут подключаться к единому файлу. А там как-то модульно (то есть в моем понимании в разных таблицах) будут храниться данные о футпринтах, УГО и т.п. А параметры будут браться из одной и той же таблицы для всех САПР.

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

 

Я начинал свои эксперименты именно с этого, только у меня CVS. Я от этого ушел, потому, что хочу пользоваться всеми преимуществами СУБД. Не хотите - дело Ваше. Замечу, что на осознание мне потребовалось несколько месяцев.

К сожалению я пока плохо разбираюсь в СУБД, и потому в упор не вижу что я теряю от того что пользуюсь Access а не MySQL.

 

Не спорю, но, если у Вас был бы время, и желание, то Вы могли бы развернуться и по первому варианту.

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

 

Не согласен. Этот принцип приводит к увеличению беспорядка в геометрической прогрессии.

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

...

Вы хотите поиграться и не использовать это в работе? Ну, тогда нам не по пути... :(

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

 

Так как описываете вы, правильно и применимо к одной организации. Где есть человек который создает компоненты (у нас например так), он ответственный за библиотеку. Его можно пнуть, чтоб быстрее создал или проверил, нагнуть в случае чего, и т.д. =)

 

С моей же точки зрения, этот проект как добровольное пожертвование в общую копилку. Тут каждый пользователь ничем не обязан другим. И ждать поверок не обязан.

 

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

 

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

 

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

 

Владимир, вы как модератор можете закрепить первый пост или хотя бы просто обновлять результаты наших обсуждений в нем?

[Uladzimir 80]

Владимир, вы как модератор можете закрепить первый пост или хотя бы просто обновлять результаты наших обсуждений в нем?

Вы имеете ввиду, где я перечислил параметры?

Нет так не могу.

 

 

Но мне нравится подход, предложенный vitan.

Не в том, смысле, что сейчас работать над глобальной базой.

А в том, что бы эта база могла быть подключена к глобальной, как база для Altium.

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

[Krys 2]

С моей же точки зрения, этот проект как добровольное пожертвование в общую копилку. Тут каждый пользователь ничем не обязан другим. И ждать поверок не обязан.

 

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

 

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

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

 

[Krys 2]

Применять нужно не тут же, а после прохождения проверок.

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

 

В идеале, чем их больше, тем лучше....

Да. Только не в ущерб возможности использования и без проверок - под свою личную ответственность. Проверить можно и самому. Не дожидаясь проверок "кем-то когда-то".

 

 

[vitan 2]

Тут я имел в виду, что данные о компонентах для различных САПР не нужно хранить в одном файле.

Я, кажется, понял. Вы, видимо, хотите сказать, что будут сделаны некие таблички (запросы), которые будут передаваться в САПР. И что, если САПР планируется несколько, то надо эти таблички (запросы) хранить в разных файлах Access? Если так, то я просто не понимаю, зачем.

 

Просто я так понял ваше предложение об общей БД, что все САПР будут подключаться к

единому файлу.

Да.

 

в моем понимании в разных таблицах) будут храниться данные о футпринтах, УГО и т.п

Нет.

 

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

Да. :)

 

К сожалению я пока плохо разбираюсь в СУБД, и потому в упор не вижу что я теряю от того что пользуюсь Access а не MySQL.

Желаю как можно скорее разобраться. :)

 

Так как описываете вы, правильно и применимо к одной организации. Где есть человек который создает компоненты (у нас например так), он ответственный за библиотеку. Его можно пнуть, чтоб быстрее создал или проверил, нагнуть в случае чего, и т.д. =)

Да нет же! У нас, например, не так. Нет человека-библиотекаря. Но есть ПРОЦЕСС (Workflow). Участниками могут быть разные люди, только и всего.

 

С моей же точки зрения, этот проект как добровольное пожертвование в общую копилку. Тут каждый пользователь ничем не обязан другим. И ждать поверок не обязан.

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

 

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

Согласен. Заметьте, я нигде не настаивал на обязательности проверок. Я только лишь говорил, что их надо предусмотреть. По-моему, идея с рейтингом сюда отлично подходит. Поставив на схему компонент с маленьким рейтингом, Вы сами принимаете решение о степени ответственности. При этом эта степень (рейтинг) запоминается на будущее прямо в схеме (на случай разборок).

 

что делать дальше уже будет решаться с автором.

Да, это разумно. Только, имхо, надо идти не к автору, а к последнему редактору. Я для этого и предложил это поле.

[Uladzimir 80]

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

Я тоже думал об этом.

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

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

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

[jkrieger 0]

Я, кажется, понял. Вы, видимо, хотите сказать, что будут сделаны некие таблички (запросы), которые будут передаваться в САПР. И что, если САПР планируется несколько, то надо эти таблички (запросы) хранить в разных файлах Access? Если так, то я просто не понимаю, зачем.

А зачем они в ОДНОМ файле? :unsure:

Пользоваться я компонентами, созданными для других САПР я не смогу, а место занимают.

 

А вот качество проверки, это, действительно, хороший вопрос! Можно попытаться как-то решить эту проблему путем, например, введения поля, в котором будет подсчитываться количество проверок, проведенных разными пользователями. Такой своеобразный рейтинг компонента. Как мысль?

Мысль мне кажется очень хорошая. Я и сам ее думал :)

 

Да нет же! У нас, например, не так. Нет человека-библиотекаря. Но есть ПРОЦЕСС (Workflow). Участниками могут быть разные люди, только и всего.

Мне вот не дают покоя эти "воркфловы". Чем, чем они лучше форм в том же аццесе? Ведт по сути это одно и тоже. Есть кнопки, поля, нажимая на которые человек вносит изменения в базу. Процессы все равно не решают проблему с синхронизацией локальных копий всех пользователей с одной единственной базой.

 

vitan, пожалуйста, можете подробнее объяснить как вы видите этот механизм синхронизации? Предположим, что база на выделенном сервере в инете. Что нужно чтобы можно было вносить изменения от всех сразу и при этом учитывать конфликты?